Why public-key signatures are not just 'encryption in reverse'

They look symmetric — encrypt with one key, decrypt with the other — but signatures and encryption answer different questions, and conflating them is how real cryptosystems get broken.

Why it exists

A lot of engineers carry around a tidy mental model of public-key crypto: you have two keys, one public and one private, and they “undo” each other. Encrypt with the public key, decrypt with the private key. Flip it around — encrypt with the private key, decrypt with the public key — and you get a signature. Same operation, different direction.

This story is appealing, easy to teach, and — for any modern system you should actually use — wrong. It happens to roughly match how textbook RSA worked, and that’s where the confusion comes from. RSA’s particular math does let you reuse the same primitive in both directions, which is exactly why early RSA implementations had cross-protocol attacks where a signing oracle could be tricked into decrypting messages.

Modern signature schemes (Ed25519, ECDSA, RSA-PSS) and modern encryption schemes (RSA-OAEP, ECIES, hybrid AEAD constructions) are not the same operation reversed. They’re built from different primitives, with different security goals. Treating them as interchangeable is one of the classic ways to introduce a real vulnerability into otherwise sane code.

Why it matters now

If you ship software in 2026 you are, transitively, relying on signatures constantly:

• Every JWT your auth provider hands you.
• Every TLS certificate your browser checks against a CA.
• Every signed container image, signed model weight bundle, every apt / dnf package, every Sigstore-attested build.
• Every Git tag or commit verified against a maintainer’s key.

For AI-era infrastructure specifically: the supply chain for models is now just as much of a target as the supply chain for code. “Did this 70 GB checkpoint actually come from the lab whose name is on it, unmodified” is a signature question, not an encryption question. Knowing which one you need — and not asking the wrong primitive to do the other one’s job — is the difference between provenance you can trust and a vibes-based promise.

The short answer

signature ≈ "I, holder of the private key, vouch for this exact message" — anyone with the public key can verify

encryption ≈ "only the holder of the private key can read this message" — anyone with the public key can produce it

They share the same key pair shape but answer opposite questions. A signature is about authenticity and integrity — proving who said it and that it hasn’t changed. Encryption is about confidentiality — keeping the contents secret from everyone but the intended recipient.

How it works

It’s easiest to see by lining up who has what.

Encryption (public-key):

• Alice wants to send Bob a secret. She has Bob’s public key.
• She encrypts using Bob’s public key.
• Only Bob — the holder of the matching private key — can decrypt.
• Anyone who has Bob’s public key (i.e. everyone) can encrypt to Bob. Confidentiality flows toward the private-key holder.

Signatures:

• Alice wants to prove she wrote a message. She has her own private key.
• She signs using her private key.
• Anyone — Bob, Carol, an auditor — can verify the signature using Alice’s public key.
• Only Alice can produce a valid signature, because only she has the private key. Authenticity flows from the private-key holder.

Notice the asymmetry of who-knows-what:

• Encryption: the private key is the reader’s secret.
• Signatures: the private key is the author’s secret.

That alone is enough to see they aren’t really the same operation. The actor holding the private key plays opposite roles in the two protocols.

What modern signatures actually do

A real signature scheme is not “encrypt the message with the private key.” It’s something more like:

1. Hash the message with a cryptographic hash (SHA-256, SHA-512, etc.) to get a fixed-size digest. You sign the digest, not the message — partly for efficiency, partly because signing arbitrary structured data directly opens up algebraic attacks.
2. Apply a signing primitive that’s specifically designed to be a signature: Ed25519 uses elliptic-curve scalar multiplication with a carefully chosen nonce derivation; ECDSA does something similar but with a randomized nonce that has to be unique (reusing a nonce across two signatures is how Sony’s PS3 keys got extracted, famously); RSA-PSS adds randomized padding around the hash before exponentiation.
3. Verify by re-hashing the message and running the verification half of the primitive against the signature and the public key.

The primitive is chosen so that:

• A valid signature is computationally hard to forge without the private key.
• Verifying tells you the exact bytes you have are the ones that were signed — flip one bit and verification fails.

What modern encryption actually does

Public-key encryption almost always uses a hybrid construction. You don’t encrypt your 4 MB JSON payload directly with RSA — that’s both slow and dangerous. Instead:

1. Generate a fresh random symmetric key (e.g. for AES-GCM).
2. Encrypt the payload with that symmetric key, using an AEAD so tampering is detected.
3. Encrypt the symmetric key with the recipient’s public key (RSA-OAEP, or an ECDH key-agreement step).
4. Send both pieces.

Padding, key derivation, nonces, and AEAD tags are doing real security work in this construction. None of that machinery exists in a signature scheme, because it’s solving a different problem.

Show the seams

• The “RSA in reverse” intuition isn’t entirely a lie historically — but it’s a trap operationally. PKCS#1 v1.5 signing really did look like “encrypt the hash with the private key.” It’s also the version that spawned a long list of padding-oracle and Bleichenbacher-style attacks. Modern advice is to use RSA-PSS for signing and RSA-OAEP for encryption, which are different paddings precisely so you can’t smuggle one into the other.
• You cannot derive privacy from a signature. A signed message is, by default, in the clear. Anyone can read it. If you also need confidentiality, you need encryption as well.
• You cannot derive authenticity from encryption alone. If Bob’s public key is, well, public, anyone can encrypt a message to Bob. Receiving an encrypted message tells Bob nothing about who sent it. This is why TLS combines a key-exchange step (encryption) with a certificate signature (authenticity) — neither half is sufficient on its own.
• Some schemes blur the line on purpose. Signcryption combines both in one primitive; KEM/DEM constructions split key encapsulation from data encryption cleanly. If you find yourself building either from scratch, stop and reach for a vetted library.
• Honest gap: I’m describing the conceptual shape, not a survey of which scheme dominates which deployment. Concrete share of Ed25519 vs ECDSA vs RSA-PSS in production today varies by ecosystem and I don’t have a current confident number — the relevant point for this post is that they are all signature schemes, not encryption-in-reverse.

If a curious engineer takes one thing away: ask which question you’re answering. “Who said this, and is it intact?” is signatures. “Can only the intended reader see this?” is encryption. The keys look the same on the outside; the protocols underneath are not.

Famous related terms

• JWT — JWT = header + claims + signature, all base64url — a signed token, almost never an encrypted one (JWE is the encrypted variant, and far less common).
• TLS certificate — cert ≈ public key + identity + CA's signature over both — uses signatures to bootstrap trust before any encryption happens.
• Sigstore / cosign — sigstore ≈ short-lived signing keys + transparency log — modern supply-chain signing for container images and artifacts.
• HMAC — HMAC ≈ "signature" with a shared secret instead of a key pair — gives integrity + authenticity but only between parties who already share a key; not a public-key signature.
• AEAD (AES-GCM, ChaCha20-Poly1305) — AEAD = symmetric encryption + built-in integrity tag — the workhorse inside hybrid encryption; gives integrity to the holder of the key, not to the world.

Going deeper

• Dan Boneh’s A Graduate Course in Applied Cryptography (free PDF) — the chapters on signatures and on public-key encryption are a clean treatment of why they’re separate primitives.
• Cryptography Engineering (Ferguson, Schneier, Kohno) — practitioner-angle on why “don’t roll your own” applies extra hard at the boundary between these two operations.
• The Bleichenbacher 1998 attack on PKCS#1 v1.5 — historical evidence for why padding and protocol separation matter.