Digital Signatures
How RSA, ECDSA, and the new ML-DSA (FIPS 204) signatures work — and why migrating away from classical signatures before quantum computers arrive is critical.
What is a digital signature?
A digital signature is a cryptographic proof that a specific private key holder signed a specific message. Anyone with the corresponding public key can verify the signature without ever seeing the private key.
Three properties define a secure signature scheme:
- Authenticity: Only the holder of the private key could have produced the signature.
- Integrity: If the message was changed after signing, the signature verification fails.
- Non-repudiation: The signer cannot later deny having signed the message.
This is different from HMAC, which provides authenticity and integrity but requires both parties to share the same secret key. Signatures use asymmetric keys: the signer has a private key, and verifiers only need the public key.
RSA signatures
RSA signing works by applying a mathematical operation (modular exponentiation) to a hash of the message using the private key. Verification applies the inverse operation using the public key and checks that the result matches the hash.
RSA Signing (PKCS#1 v1.5 or PSS): 1. Hash the message: H = SHA-256(message) 2. Sign the hash: sig = H^d mod n (d = private exponent, n = modulus) RSA Verification: 1. Hash the message: H = SHA-256(message) 2. Recover hash from sig: H' = sig^e mod n (e = public exponent) 3. Compare: valid = (H == H')
RSA-2048 is the minimum safe key size for classical use. RSA-4096 is preferred for long-lived keys such as root CA certificates. In BFSI systems, RSA signatures appear in:
- TLS certificates (server identity)
- JWT tokens (RS256, RS384, RS512, PS256)
- Code signing certificates
- Document signing in banking and insurance workflows
RSA PKCS#1 v1.5 padding is weak
RSA-PKCS#1 v1.5 padding (used in RS256/RS384/RS512 JWTs) is vulnerable to Bleichenbacher padding oracle attacks in certain configurations. Use RSA-PSS padding (PS256/PS384/PS512) in new systems. For new key pairs, prefer ECDSA or move directly to ML-DSA.ECDSA: elliptic curve signatures
ECDSA (Elliptic Curve Digital Signature Algorithm) provides the same security as RSA but with much smaller keys. A 256-bit ECDSA key (P-256) provides roughly the same security as RSA-3072.
ECDSA signing (P-256, SHA-256): private key: 256-bit scalar d public key: point Q = d × G (G = curve generator point) Signing produces: (r, s) pair — two 256-bit integers Verifier needs: public key Q, message, and (r, s) ECDSA in common systems: ES256 = ECDSA with P-256 and SHA-256 (common in JWTs, TLS) ES384 = ECDSA with P-384 and SHA-384 (higher-security use cases) ES512 = ECDSA with P-521 and SHA-512 (uncommon but strong) EdDSA = Edwards-curve variant (Ed25519, Ed448) — faster, no random nonce
EdDSA (specifically Ed25519) is preferred over classical ECDSA for new systems because it does not require a per-signature random nonce. ECDSA has historically had catastrophic failures when the same nonce was reused for two signatures — the PlayStation 3 private key was extracted this way in 2010.
ECDSA nonce reuse is catastrophic
If the same random nonce k is used for two ECDSA signatures (even from different messages), the private key can be fully recovered. This is a real-world attack. Always use a cryptographically secure RNG and prefer EdDSA (deterministic) for new systems.Why both RSA and ECDSA are quantum-vulnerable
Both RSA and ECDSA rely on mathematical problems believed to be hard for classical computers:
- RSA relies on integer factorization — given n = p × q, find p and q.
- ECDSA relies on the elliptic curve discrete logarithm problem — given Q = d × G, find d.
Shor's algorithm, designed for quantum computers, solves both problems in polynomial time. A quantum computer with enough stable qubits could recover any RSA or ECDSA private key from its public key.
The threat is not theoretical. NIST has been running a post-quantum cryptography standardization process since 2016. In August 2024, NIST published the first three post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).
Harvest Now, Decrypt Later applies to signatures too
An adversary recording signed documents or JWT tokens today can wait for a quantum computer and then recover the signing key. Once they have the key, they can forge signatures retroactively — or prove past signatures were produced by a specific key. Long-lived signed records (insurance contracts, land registry documents, legal instruments) need quantum-safe signatures now.ML-DSA: FIPS 204 (formerly CRYSTALS-Dilithium)
ML-DSA (Module Lattice-based Digital Signature Algorithm) is the primary post-quantum signature standard from NIST. It is based on the hardness of lattice problems (specifically Module Learning With Errors — MLWE), which have no known efficient quantum algorithm.
ML-DSA parameter sets (FIPS 204): ML-DSA-44: ~128-bit classical, ~128-bit quantum security (smallest) ML-DSA-65: ~192-bit classical, ~192-bit quantum security (recommended) ML-DSA-87: ~256-bit classical, ~256-bit quantum security (highest) Key sizes (ML-DSA-65 vs ECDSA P-256): ECDSA P-256 public key: 64 bytes ML-DSA-65 public key: 1,952 bytes ECDSA P-256 signature: 64 bytes ML-DSA-65 signature: 3,309 bytes
The main tradeoff with ML-DSA is size. Signatures and public keys are significantly larger than classical counterparts. For most use cases (API authentication, TLS certificates, code signing) this is manageable. For constrained environments (IoT, embedded), SLH-DSA or hash-based signatures may be more appropriate.
ML-DSA signing is fast — comparable to ECDSA. Verification is also fast. The size increase is the primary operational concern.
SLH-DSA: FIPS 205 (hash-based signatures)
SLH-DSA (Stateless Hash-based Digital Signature Algorithm, formerly SPHINCS+) provides quantum-safe signatures based only on the security of hash functions (SHA-256 or SHAKE). It is considered the most conservative post-quantum signature scheme because it relies on a well-understood primitive.
The tradeoff: SLH-DSA signatures are large (8-50 KB depending on parameter set) and signing is slow. It is best suited for use cases where signing is infrequent and verification is fast — such as software release signing or root CA certificates.
Migration priority for BFSI systems
Not every signature system needs to migrate at the same speed. Prioritize based on two dimensions:
- Data longevity: How long must the signed data remain trusted? Long-lived contracts, audit logs, and regulatory records should migrate first.
- Key exposure: Is the public key widely distributed? TLS certificates and code-signing certificates expose public keys broadly, giving adversaries more material to work with.
Hybrid signatures bridge the transition
During the migration period, use hybrid signatures: sign with both ECDSA and ML-DSA. Verifiers that support PQC validate ML-DSA; legacy verifiers use ECDSA. This is the same hybrid approach used in TLS key exchange migration (X25519 + ML-KEM). Once the ecosystem catches up, drop the classical component.Quick reference
| Algorithm | Type | Status | Sig size |
|---|---|---|---|
| RSA-PSS | Asymmetric | Quantum-vulnerable | 256-512 bytes |
| ECDSA P-256 | Asymmetric | Quantum-vulnerable | 64 bytes |
| Ed25519 | Asymmetric | Quantum-vulnerable | 64 bytes |
| ML-DSA-65 | Lattice (PQC) | Quantum-safe | 3,309 bytes |
| SLH-DSA-128s | Hash-based (PQC) | Quantum-safe | 7,856 bytes |