If you have ever pasted a PEM key into a verify box and got back a green VALID, you have used asymmetric cryptography at its most honest: a few hundred bytes that prove a private key holder produced this exact message. Three algorithms cover almost every real-world signature you will ever touch — RSA-PSS, ECDSA P-256, and Ed25519 — and the Digital Signature Generator lets you exercise all three against the same Node crypto primitives production systems use. This article walks through what each algorithm actually produces, where the wire format diverges, and how to keep your private key from ever leaving your laptop.
What a digital signature actually is
A digital signature is not encryption. It is the output of a private-key operation that anyone with the matching public key can verify. The verifier never sees the private key. The signer never sees the verifier. The two only share the public key, the message, and the signature bytes themselves.
That asymmetry is the whole point. It is what gives a signature the property cryptographers call non-repudiation: only the holder of the private key could have produced a signature that the public key verifies, so the signer cannot later deny having signed the message.
The Digital Signature Generator runs the same crypto.createSign and crypto.createVerify calls your Node service would run, but entirely in the browser. Paste a private key, paste a message, and you get a base64 string back. Flip to Verify, paste a public key, paste the message, paste the signature, and you get VALID or INVALID with no network round trip and no upload.
Three algorithms, three wire formats
RSA-PSS, ECDSA P-256, and Ed25519 all reach the same answer (VALID or INVALID), but the bytes they put on the wire look nothing alike. The default in the tool is Ed25519, and there is a reason for that: it is the simplest, the most modern, and the least likely to be misused.
Ed25519 is pure EdDSA over Curve25519. The signature is exactly 64 bytes, always. There is no parameter selection, no separate hash, no padding scheme. You sign with crypto.sign(null, data, privateKey) — no hash argument, because SHA-512 is internal to the algorithm. Ed25519 signatures are deterministic: the same private key and message always produce the same signature.
ECDSA P-256 uses an elliptic curve at the 128-bit security level. Its signatures are also 64 bytes, but the wire format is the IEEE P1363 r || s concatenation — fixed width, deterministic, no DER ambiguity. The tool sets dsaEncoding: 'ieee-p1363' explicitly so the output is the same length every time. ECDSA needs an explicit hash step (SHA-256 here), which is why the source calls crypto.createSign('SHA256') instead of crypto.sign(null, ...).
RSA-PSS (SHA-256) is the modern RSA signature scheme, preferred over the legacy PKCS#1 v1.5. RSA-PSS is probabilistic: every signature over the same message is different because the padding includes a fresh random salt. The source calls crypto.createSign('RSA-SHA256') with padding: RSA_PKCS1_PSS_PADDING and saltLength: RSA_PSS_SALTLEN_DIGEST. RSA-2048 signatures are 256 bytes; RSA-4096 signatures are 512 bytes. RSA-PSS is slow to sign, fast to verify — exactly the wrong shape for an API gateway and exactly the right shape for a one-shot code-signing key.
The sign-then-verify handshake
The verifier only needs three things: the message, the signature, and the public key. The signer needs two: the message and the private key. That is the entire handshake — but the order matters, and the algorithm must match the key type.
Try the tool in Sign mode with an Ed25519 private key and a message like "approve transfer 4471". The output is 64 bytes of base64 — copy it. Flip to Verify, paste the same message, paste the public key, paste the signature, and you get VALID. Change one byte of the message and the same verifier returns INVALID. That is not a bug; that is the entire cryptographic guarantee.
The algorithm dropdown enforces the key-type match. An RSA key only works with RSA-PSS. An EC P-256 key only works with ECDSA. An Ed25519 key only works with Ed25519. Mismatched algorithms yield a verification error, not a silent fail. This is why you cannot paste a long RSA public key into the Ed25519 slot and hope for the best.
Size and cost tradeoffs
For 128-bit security — the level most APIs target in 2026 — the three algorithms split cleanly:
RSA-PSS with a 2048-bit key signs 256-byte signatures and is the slowest of the three. RSA-4096 doubles the signature length and roughly quadruples the sign time. ECDSA P-256 signs 64-byte signatures with smaller keys than RSA — usually a 65-byte public key versus the kilobytes an RSA public key takes. Ed25519 also signs 64-byte signatures with the smallest keys of all (32 bytes for the public key), and it is deterministic, so a flaky PRNG on the signer cannot accidentally leak your private key the way it could with ECDSA back in the Sony PS3 era.
If you control both ends and are not constrained by a legacy verifier, default to Ed25519. If you are signing for a partner that runs Java 7 or older, default to RSA-PSS with a 2048-bit key. If you are signing for a TLS stack that already has ECDSA configured, ECDSA P-256 is the middle path.
Where the private key lives
The whole reason the tool exists in the browser is the private key never has to leave your laptop. Signatures are produced by Node crypto.createSign running locally, and verification runs locally as well. There is no server-side component that sees your PEM.
That matters because the standard failure mode for asymmetric crypto is not a math failure — it is a key-management failure. A private key on a server that gets compromised is a signature compromise for the entire lifetime of that key. A private key on a laptop that gets compromised is the same — but at least the attack surface is smaller and you can rotate the keypair on demand. The Digital Signature Generator is meant for the dev workflow: test a sign-then-verify round trip before you wire it into a service, debug a CI step that is rejecting a payload, or sanity-check that a keypair you just generated with the RSA Key Generator or SSH Key Generator behaves the way you expect.
What it does not do
The tool intentionally does not generate keys. You cannot paste a passphrase and get back a PEM. The reason is a security posture decision: a tool that generates keys and a tool that signs messages have different threat models, and conflating them invites bugs where a key is silently persisted or a signature is silently generated with the wrong key. Use the RSA Key Generator for RSA keypairs, the SSH Key Generator for Ed25519 / ECDSA keypairs, and paste the output here.
It also does not do certificate handling. A signature is not a certificate. A signed message is just three strings — the message, the signature, and the public key. Trust is established by trusting that public key, which is what certificate chains and Sigstore-style transparency logs solve in production.
Practical uses
Three concrete jobs the tool handles in seconds:
- Debugging CI failures when a downstream service rejects a webhook signature. Paste the message and the supposed signature, run verify, and you know in two seconds whether the failure is a payload corruption or a key rotation.
- Sanity-checking a keypair you just generated. Sign a known message, verify with the public key, confirm VALID. If it does not verify, you have a typo in the PEM or a mismatched algorithm — both common when keys are passed between teams in chat threads.
- Learning the wire format before you write a single line of production signing code. Ed25519 signatures are deterministic, RSA-PSS signatures are probabilistic, ECDSA P-256 signatures with ieee-p1363 are fixed-width — running all three on the same message makes the differences visible in a way the spec text never does.
The bottom line
A digital signature is a few hundred bytes that prove a private key holder produced this exact message. The algorithm matters less than the key management: pick Ed25519 by default for new systems, RSA-PSS for legacy verifiers, ECDSA P-256 for the middle path. The Digital Signature Generator runs all three in your browser using the same Node crypto primitives production systems rely on, so you can sign, verify, and debug without ever uploading a private key. Paste a PEM, get a base64 signature, hand the recipient the message plus signature plus your public key, and let the math do the rest.
Explore more security tools at elysiatools.com.
