Asymmetric Cryptography & PKI

Textbook RSA is broken

Textbook RSA encrypts a message m by computing c = m^e mod n. It is deterministic (same plaintext always produces the same ciphertext), malleable (multiplying two ciphertexts gives a ciphertext of the products of the plaintexts), and reveals partial information through chosen-ciphertext attacks. Nobody ships textbook RSA on purpose.

Two padding schemes fix the problems:

• OAEP (encryption): adds randomness so identical plaintexts encrypt differently and adds an integrity check inside the padding to detect tampering. Required for any RSA encryption today.
• PSS (signatures): probabilistic, with a tight security proof. Replaces the older PKCS#1 v1.5 signature scheme, which is still common and survives in practice but has had a long string of side-channel issues (Bleichenbacher attacks).

Modern advice: do not use RSA at all for new systems unless you have a specific compatibility reason. When you must, use a vetted library with OAEP or PSS, and pick a key size of at least 3072 bits for long-term keys.

The elliptic-curve switch

Elliptic-curve cryptography (ECC) gives you the same operations as RSA at much smaller key sizes. A 256-bit ECC key is comparable in strength to a 3072-bit RSA key. Smaller keys mean faster operations, smaller signatures, and lighter handshakes.

Two signature families dominate:

• ECDSA: the elliptic-curve form of DSA. Used in TLS certificates, blockchain wallets, code signing. Requires a high-quality random nonce per signature. Reusing or biasing the nonce leaks the private key (the 2010 PlayStation 3 incident).
• EdDSA (Ed25519, Ed448): newer, deterministic, fast, designed to resist common implementation pitfalls. Default choice for new SSH keys, signed package managers, and many software signing systems.

For pure key exchange, the elliptic-curve cousin is X25519 (or its TLS variant ECDHE with various curves). TLS 1.3 uses ECDHE by default.

Forward secrecy and ephemeral keys

A key exchange has forward secrecy if compromising long-term private keys does not let an attacker decrypt past sessions. TLS 1.3 enforces this by always using ephemeral ECDH: the server's long-term key only signs the ephemeral key, never participates in deriving the session key.

Practical consequence: an attacker who steals your TLS server key can intercept future traffic only if they can do so live, in real time. Recordings of past traffic are not decryptable retroactively, because the ephemeral keys were thrown away.

Signature verification, in the order you must do it

A correct signature verification is:

1. Validate the certificate chain back to a trusted root.
2. Check that the certificate has not expired and is not revoked (OCSP staple or CRL).
3. Confirm the certificate's subject matches the identity you expect (DNS name, code-signing identity, etc.).
4. Check the certificate's key usage extension permits what you are using it for.
5. Verify the signature itself.

Skipping any of these has produced real CVEs. The trick is that most crypto libraries make step 5 effortless and require you to do 1 through 4 explicitly.

Post-quantum, in short

A sufficiently large quantum computer would break RSA and ECC via Shor's algorithm. That machine does not exist today, but recordings of today's TLS traffic could be decrypted if it is ever built (the "harvest now, decrypt later" risk).

Where the industry is in 2026:

• NIST has standardized ML-KEM (formerly Kyber) for key exchange and ML-DSA (Dilithium) for signatures.
• Hybrid TLS handshakes that combine X25519 with ML-KEM are shipping in major browsers and reverse proxies.
• Code-signing, SSH, and long-lived certificates are starting to adopt PQ-hybrid schemes for high-value use cases.

Realistic timeline for production replacement of all classical asymmetric crypto: years to a decade, gated mostly on hardware support and ecosystem inertia.