RSA-PSS Signature Tool

In 1976 Whitfield Diffie and Martin Hellman named two things cryptography could not yet do. One was to let strangers agree on a key without a secure channel. The other was to supply, in their words, the equivalent of a written signature. Within a year three researchers at MIT had an answer to both, and the abstract of their paper made a promise that has been repeated ever since: signatures cannot be forged, and a signer cannot later deny the validity of his signature.

That promise is true in a narrow sense and misleading in a broad one. The narrow sense is worth stating exactly, because everything a signature is good for follows from it. So does everything it is not.

What the mathematics promises

An RSA key pair is two numbers that undo each other. What the private one transforms, the public one restores, and the security of the pair rests in part on how hard it is to factor the large modulus they share. To sign, the holder of the private key applies it to a short encoding of the message. To verify, anyone applies the public key to the signature and checks that the same encoding comes back.

So a valid signature establishes two facts. These exact bytes were presented to that private key. Not one bit has changed since.

It is not encryption. The message travels in the clear beside its signature, and anyone may read it. The 1977 paper spoke of signing with a privately held decryption key, and the habit of calling a signature a kind of encryption has lingered. It gets the direction of secrecy backwards: nothing is hidden, and the whole point is that everybody can check.

Nor does a signature say who signed. A public key is only a number until someone you trust tells you whose it is, which is the job of certificates: data structures that bind a public key to a subject, vouched for by an authority. A signature does not say when it was made, or whether the signer read the document, or meant it. And if the private key is copied, the copy signs exactly as well as the original. The mathematics cannot tell them apart.

The padding is the scheme

The step that is easy to skip past is the short encoding. RSA cannot sign a long file directly, so the file is hashed. The hash is far shorter than the modulus, so it is padded out to full size before the private key touches it. How that padding is built matters more than it looks.

The older method, PKCS #1 version 1.5, is deterministic. It writes a fixed run of filler bytes, then a small structure that names the hash function and carries the hash. The same message under the same key always gives the same signature. No attack on the encoding itself is known, and the standard that defines it says so, while still recommending a gradual move to the newer method as a precaution.

What has failed, more than once, is the checking. In September 2006 OpenSSL published an advisory after Daniel Bleichenbacher described a forgery against keys with a public exponent of 3: a verifier that did not check for excess data in the decoded signature could be made to accept one that the key holder never made. Eight years later Mozilla reported that its NSS library was open to a variant of the same attack, this time through lenient parsing of the values inside a signature, and that it could have led to forged certificates. A format with a structure inside invites a parser, and parsers invite leniency.

The Probabilistic Signature Scheme, published by Mihir Bellare and Phillip Rogaway in 1996, takes another route. Before each signature the signer draws fresh random bytes, the salt. The hash of the message is hashed again together with the salt, the salt is hidden under a mask generated from that second hash, and the block ends in one fixed trailer byte, 0xbc. The verifier removes the mask, reads the salt and recomputes. No hash identifier sits inside, and there is no nested structure to read generously.

Two things follow. Sign the same file twice and the signatures differ, because the salts differ, yet both verify. And the scheme comes with a proof: if the hash functions behave ideally, forging a signature takes about as much effort as inverting RSA itself. The authors called that relation tight. The standard adds that the randomness is not critical, and that a fixed salt still leaves a sound scheme. The random salt is what earns the tighter bound.

Newer rules lean the same way. TLS 1.3 requires RSA signatures in its handshake to use PSS, with a salt exactly as long as the hash output. The United States signature standard, FIPS 186-5, approves both paddings and caps the PSS salt at the hash length.

A signature you can check yourself

Numbers make this concrete. In the tool above, generate a 2048-bit key with SHA-256 and sign the sample text, “Meet at noon.” The message is 13 bytes. The signature is 256 bytes, the length of the modulus: 344 characters in Base64, or 512 hex digits. A one-line note and a feature film get a signature of the same size.

Press Sign again. The output changes from end to end, and both signatures verify. Now set the salt length to 0 and sign twice. The two results are identical, because with no salt the scheme is deterministic. Set it to 222 and it still works; 223 is refused. The encoded block for a 2048-bit key is 256 bytes long, and it must hold the 32-byte hash, the salt and two bytes of framing, so 222 bytes is the ceiling.

Then switch on “Change one byte of the message” and verify. The first letter, M, is the byte 4d. Flipping its lowest bit makes it 4c, an L, and “Leet at noon.” fails outright. There is no partial credit, and a single changed bit in a file of any size has the same effect.

One practical point hides here. A PSS signature does not name its hash function, so the verifier has to be told which one the signer used. The browser’s interface must be told the salt length as well. OpenSSL can work the salt length out from the padding when asked to, but the simplest rule is to state both numbers wherever the signature goes.

How long a key size lasts

The three hashes on offer differ in output length: 256, 384 and 512 bits. The three key sizes differ in how much work the best known factoring method needs. NIST’s estimate is 112 bits of strength for a 2048-bit modulus, 128 for 3072 and 152 for 4096. Doubling the key does not double the strength, though it does double the length of every signature.

On paper the dates are these. NIST’s key management guidance projects 112-bit strength as acceptable through 2030 and disallows it after that for making new signatures, while 128 bits and above carry no end date in the same table. That favors 3072 bits for anything meant to outlive the decade.

A larger shadow falls across the whole table. A draft transition plan that NIST published in November 2024 would deprecate 112-bit RSA after 2030 and disallow RSA signatures of every size after 2035, because a large enough quantum computer would break the underlying problem and not merely the smaller keys. The same draft makes one point in a signature’s favor. Encrypted traffic can be recorded today and decrypted later. An authentication only has to hold at the moment it is performed.

Files that travel, keys that should not

A key is a handful of large integers, and most of the vocabulary around keys describes containers for them. DER is a compact binary encoding. PEM is DER written in Base64 between a BEGIN line and an END line, wrapped at 64 characters. Inside, a public key is normally a SubjectPublicKeyInfo, the structure certificates use, and a private key is a PKCS #8 PrivateKeyInfo. Older OpenSSL files, the ones labeled RSA PRIVATE KEY, hold the bare PKCS #1 structure without that wrapper. A JWK carries the same integers as named fields of a JSON object. Each converts into the others without loss.

A fingerprint is how people compare keys. It is a hash of the encoded public key, short enough to read aloud, and it is the bridge between the number and the person who claims it.

None of these formats protects anything. A private key in PEM is as readable as any text file unless it was encrypted with a password, and the files this page exports are not. Whoever obtains one can sign as you until everyone who trusts the key has been told to stop.

Doing this in a browser adds limits of its own, and the Web Cryptography specification is candid about them. A key can be marked non-extractable, so that scripts may use it but never read it. That is all the specification requires. It does not guarantee that the key material stays off the disk, that it is stored encrypted, or that other software running as the same user cannot reach it. A hostile script injected into a page may exfiltrate keys, and a user who clears a site’s storage destroys them.

So the method cannot give you what a hardware token or a certificate authority gives you. It cannot say who stands behind a key. It cannot make a careless verifier careful. It cannot outlast the theft of its secret. What it can do is make one small claim unforgeable: these bytes, that key. The rest is bookkeeping, and the bookkeeping is where signatures succeed or fail.