Signature (cryptographic)

A cryptographic signature is a short string of bytes that proves a specific message was produced by someone in possession of a private key, without revealing the private key. Verifying the signature requires only the corresponding public key (for asymmetric algorithms) or the shared secret (for symmetric).

The basic asymmetric flow (using RSA, ECDSA, or Ed25519):

1. The signer hashes the message (typically SHA-256).
2. The signer encrypts the hash with their private key. Output: the signature.
3. The verifier hashes the received message with the same hash function.
4. The verifier decrypts the signature with the public key. Output: a hash.
5. If the two hashes match, the signature is valid and the message wasn’t tampered with.

Symmetric signatures (HMAC) use a shared secret instead of a key pair. The signer and verifier both have the secret; both compute HMAC(secret, message) and compare. Faster than asymmetric; only useful when the parties already trust each other (you don’t want HMAC for third-party verification because anyone with the secret can forge signatures).

Where signatures appear in the working stack: JWT tokens (the third segment), TLS certificate chains, code signing (Apple notarisation, Windows Authenticode), Git commits and tags (GPG-signed), Bitcoin transactions, software package distribution (Linux package managers, Homebrew formulas). Each context bundles the signature with a specific algorithm and key-management story; the underlying primitive is the same.

Post-quantum signatures and the migration ahead: RSA, ECDSA, and Ed25519 are all vulnerable to Shor’s algorithm on a sufficiently large quantum computer. NIST’s post-quantum cryptography programme selected three signature schemes in 2024 — ML-DSA (Dilithium), SLH-DSA (SPHINCS+), and FN-DSA (Falcon) — as the standards-track replacements. Real-world quantum machines big enough to break 2048-bit RSA don’t exist yet, but cryptographic systems with long lifetimes (root certificates, code-signing keys for archived software, encrypted backups intended to remain confidential for decades) are migrating preemptively. Hybrid signatures (classical + post-quantum) are the typical transition strategy. Reference: NIST — Post-Quantum Cryptography Standardization.

Worked example

Sign the message "transfer $100 to alice" with an Ed25519 key. Step one: hash the message with SHA-512 producing a 64-byte digest. Step two: the Ed25519 algorithm combines that digest with the 32-byte private key’s scalar via deterministic nonce generation (RFC 8032), producing a 64-byte signature (R, s). Step three: anyone with the 32-byte public key can verify by recomputing the curve point and checking that the equation sB = R + H(R, A, M) · A holds. The signature is short (64 bytes) and verification is fast (~50 µs on a modern CPU). Crucially, Ed25519 is deterministic — signing the same message with the same key twice produces identical bytes. RSA-2048 signing the same message would produce a 256-byte signature; ECDSA over P-256 would produce ~71 DER-encoded bytes. The choice of algorithm trades signature size, verification speed, and key compactness.

When and why it matters

Misuse of signatures is the most common cryptographic vulnerability after password hashing. The classic mistakes: signing a JSON blob whose canonical form is ambiguous (rearranging keys changes the bytes and breaks the signature, or worse, lets an attacker craft two semantically different messages with the same bytes), using a deterministic ECDSA nonce repeated across two messages (which leaks the private key — this is how the PlayStation 3 master key was extracted in 2010), and accepting signatures without verifying the algorithm field matches the expected one (the “alg: none” vulnerability class in early JWT libraries). The defensive rules: pin the algorithm at the verifier, canonicalise the message before hashing (use COSE/JOSE not ad-hoc JSON), prefer Ed25519 over ECDSA for new code, and store private keys in HSMs or hardware-backed enclaves when the threat model justifies it. Reference: RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA).