Compendium

Cryptography Fundamentals — Compute Reference

36 min read

Cryptography Fundamentals — Compute Reference

A working reference for engineers who deploy cryptography but do not design primitives. The goal is to recognize the right tool, name it correctly, choose sane parameters, and avoid the cluster of failure modes that have produced most real-world cryptographic breaches in the last twenty-five years. Where a primitive is a recent standard, the FIPS or RFC number is given. Where a practice is current consensus (mid-2020s), it is flagged as such; cryptography moves and the post-quantum transition in particular is mid-flight.

1. At a glance

Cryptography in production systems stands on three pillars, plus three supporting services. The pillars cover what an adversary should not be able to do. The services make the pillars usable.

Pillars:

  • Confidentiality — the adversary cannot read the message. Provided by encryption (symmetric: AES, ChaCha20; asymmetric: RSA-OAEP, ECIES; modern practice is to use AEAD constructions, not raw encryption).
  • Integrity — the adversary cannot modify the message undetected. Provided by MACs (HMAC, Poly1305) and by cryptographic hashes when both ends share a secret context. AEAD covers integrity and confidentiality in one primitive.
  • Authenticity — the adversary cannot impersonate a party. Provided by digital signatures (RSA-PSS, ECDSA, Ed25519) and, transitively, by certificate chains (X.509 + a PKI).

Supporting services:

  • Key exchange — two parties derive a shared secret over a public channel. Diffie-Hellman (1976), modernized as ECDH over Curve25519 (X25519) or NIST P-256.
  • Key derivation (KDF) — turn a master secret into a family of subkeys bound to context (HKDF), or stretch a low-entropy password into a key that resists offline brute force (Argon2id).
  • Random number generation (RNG) — provide cryptographically secure unpredictable bits. The OS CSPRNG is the right answer; user-space PRNGs are almost always wrong for crypto.

A correct deployment usually composes all six: a TLS handshake performs key exchange (ECDH or hybrid ECDH+ML-KEM), derives traffic keys (HKDF), authenticates the server (signature over a certificate chain), and protects records with AEAD (AES-GCM or ChaCha20-Poly1305) seeded from the CSPRNG. Skipping any one of these is the failure mode behind a large fraction of historical breaks.

2. Hash functions

A cryptographic hash maps an arbitrary-length input to a fixed-length output (the digest). Three properties matter:

  • Preimage resistance — given a digest h, infeasible to find any m with H(m) = h. (One-wayness.)
  • Second-preimage resistance — given m1, infeasible to find m2 != m1 with H(m1) = H(m2).
  • Collision resistance — infeasible to find any pair (m1, m2) with the same digest. Strictly stronger than second-preimage; bounded by the birthday paradox at 2^(n/2) work for an n-bit output.

Standard hashes

  • SHA-2 family (NIST FIPS 180-4, 2001 onward) — SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/256. Merkle-Damgard construction over the Davies-Meyer compression function. SHA-256 is the workhorse: Bitcoin, TLS certificate signatures, package checksums, content-addressable storage, Merkle trees. SHA-512 is faster than SHA-256 on 64-bit CPUs (its internal state is 64-bit words) and is preferred when output length is not a constraint.
  • SHA-3 / Keccak (NIST FIPS 202, 2015) — sponge construction, structurally unrelated to SHA-2, selected by the NIST competition (2007-2012) as insurance against future SHA-2 cryptanalysis. Adoption is modest because SHA-2 has held up; SHA-3 is the right choice when domain separation primitives (KMAC, cSHAKE) are useful.
  • BLAKE2 / BLAKE3 — BLAKE2 (Aumasson et al, 2012) was a SHA-3 finalist redesigned for speed. BLAKE3 (2020) is the current fastest mainstream hash: tree-structured, parallelizable across cores, AVX-512 friendly, secure at 256-bit output. Used by content-addressable systems where SHA-256 is a throughput bottleneck (Bao, IPFS forks, build caches).

Broken hashes — do not use for security

  • MD5 (Rivest, 1992) — collisions found by Wang et al (2004), chosen-prefix collisions practical in seconds on a laptop (2009). Still acceptable as a non-cryptographic checksum (verifying that an unintentional bit-flip has not happened) but never for authentication, signatures, or content addressing with adversarial inputs. The Flame malware (2012) used an MD5 chosen-prefix collision to forge a Microsoft code-signing certificate.
  • SHA-1 (NIST FIPS 180-1, 1995) — theoretical collision attack from Wang (2005); first practical full collision by Stevens et al (Google, 2017, “SHAttered”); chosen-prefix collision by Leurent and Peyrin (2020). Removed from TLS, code signing, Git internals (SHA-256 transition ongoing).

Use cases

  • Integrity check — publish digest alongside content; recipient re-computes. Vulnerable to substitution if the digest channel is not authenticated.
  • Commitment — publish H(secret || nonce) now, reveal (secret, nonce) later; binds the publisher without revealing the secret.
  • Password hashing — hashes are too fast for this. Use a KDF (Argon2id, scrypt, bcrypt) instead. See section 7.
  • Merkle trees — tree of hashes; root commits to the entire leaf set; any leaf can be verified with a logarithmic-size proof. Underpins Git, Bitcoin, Certificate Transparency, ZK rollups.
  • Content-addressable storage — H(blob) is the storage key. IPFS, BitTorrent v2, Nix, Bazel, OCI image layers.

3. MAC and authenticated encryption

A Message Authentication Code (MAC) binds a message to a shared secret key. Anyone with the key can produce or verify the tag; without the key it is infeasible to forge.

HMAC

HMAC (Krawczyk, Bellare, Canetti, 1996; RFC 2104) is a generic construction that turns any cryptographic hash into a MAC:

HMAC(K, m) = H((K' xor opad) || H((K' xor ipad) || m))

where K' is the key padded or hashed to block size. HMAC-SHA256 is the default for IETF protocols. Provably secure under modest assumptions on the underlying hash; survives even when the bare hash function turns out to be weak against collision attacks (MD5-HMAC remained secure long after MD5 collisions were practical, though it has since been replaced).

Poly1305

Poly1305 (Bernstein, 2005) is a one-time MAC: each key authenticates one message, then is discarded. Evaluated as a polynomial over the prime field 2^130 - 5. In practice it is paired with a stream cipher (ChaCha20) that generates a fresh Poly1305 key per nonce; this composition is the ChaCha20-Poly1305 AEAD of RFC 8439.

AEAD — Authenticated Encryption with Associated Data

A modern symmetric primitive: encrypt and authenticate a plaintext, while also authenticating (but not encrypting) some associated data (e.g. a packet header). The interface:

seal(K, N, AD, plaintext) -> ciphertext || tag
open(K, N, AD, ciphertext || tag) -> plaintext or AUTH_FAIL

Standard AEADs:

  • AES-GCM (NIST SP 800-38D, 2007) — AES-CTR + GHASH (a polynomial MAC over GF(2^128)). Hardware-accelerated on every modern x86 (AES-NI, PCLMULQDQ) and ARMv8 CPU. Tag is 128 bits. Catastrophically fragile if a nonce is reused with the same key: attacker can recover the authentication key and forge arbitrary messages.
  • ChaCha20-Poly1305 (RFC 8439, 2018) — fast on CPUs without AES acceleration (mobile ARM, embedded); constant-time by construction; preferred by many modern stacks (WireGuard, Signal, OpenSSH, TLS 1.3 on mobile).
  • AES-OCB3 (RFC 7253, 2014) — one-pass AEAD, was patent-encumbered until Krovetz released the patents (2021). Faster than GCM in software but rarely deployed due to the patent history.
  • AES-SIV (RFC 5297, 2008) — synthetic IV; deterministic AEAD that is nonce-misuse-resistant: reusing a nonce only leaks whether two plaintexts are equal, not the keystream. Used for key wrapping and deduplication.
  • AES-GCM-SIV (RFC 8452, 2019) — modern misuse-resistant GCM variant, used by Google internally.

Rule: always prefer AEAD to “encrypt then MAC” or “MAC then encrypt” compositions. Hand-rolled compositions have produced a steady stream of CVEs; AEAD bundles the primitive correctly.

4. Symmetric encryption

AES (Rijndael)

AES (Daemen and Rijmen, 1998; standardized as NIST FIPS 197, 2001). Substitution-permutation network on 128-bit blocks. Three key sizes: 128, 192, 256 bits, mapped to 10, 12, 14 rounds. AES-128 has no known practical attack better than brute force; AES-256 is the same construction with more rounds and a larger key schedule. The 2009 related-key attacks on AES-256 reduced its effective security against a related-key adversary but are not a concern in standard usage (where keys are independent).

AES is everywhere because Intel AES-NI (2010), ARM Cryptography Extensions (ARMv8, 2011), and AMD shipped hardware instructions; AES throughput on modern CPUs is 1-5 GB/s per core. AES-128 is typically faster than AES-256 by ~40% and equally secure for non-quantum threats.

Modes:

  • ECB (Electronic Codebook) — encrypt each block independently. Leaks equality of blocks (the canonical “ECB penguin” image). Never use except inside a higher-level construction.
  • CBC (Cipher Block Chaining) — XOR each plaintext block with the previous ciphertext block. Requires a random IV; needs PKCS#7 padding; vulnerable to padding-oracle attacks (Vaudenay, 2002; BEAST 2011; Lucky13 2013). Use only with explicit MAC and constant-time padding check; in modern code, prefer AEAD.
  • CTR (Counter mode) — turn AES into a stream cipher by encrypting a counter; XOR keystream with plaintext. Parallelizable, no padding. Reusing a (key, counter) pair is catastrophic (XORing two ciphertexts cancels the keystream, revealing m1 xor m2).
  • GCM (Galois/Counter Mode) — CTR + GHASH; the standard AEAD. See section 3. Nonce must be unique per key; 96-bit nonces give ~2^32 messages safely.
  • XTS (NIST SP 800-38E, 2010) — disk-block encryption; pair of keys, tweak per sector. Used by BitLocker, FileVault, LUKS (default since 2014).

ChaCha20

ChaCha20 (Bernstein, 2008) — stream cipher, 256-bit key, 96-bit nonce, 20 rounds over a 512-bit state of 32-bit words (ARX: add, rotate, XOR). Faster than AES on CPUs without AES-NI; constant-time by design; no S-box (so immune to cache-timing). Standardized in RFC 7539 / RFC 8439 as the IETF variant.

Deployed in TLS 1.3 (mobile), QUIC, WireGuard, OpenSSH, Signal Protocol, Linux /dev/urandom (internal mixer since 4.8). XChaCha20 extends the nonce to 192 bits to make randomly chosen nonces safe.

Deprecated symmetric ciphers

  • DES (1977) — 56-bit key; brute-forceable since the late 1990s (EFF Deep Crack, 1998). Dead.
  • 3DES / TDEA — three-key DES, 112-bit effective security. NIST SP 800-67 Rev 2 (2017) restricted to legacy use; NIST formally deprecated 3DES in 2024 (SP 800-131A Rev 3). Vulnerable to Sweet32 (Bhargavan-Leurent 2016) birthday attack on the 64-bit block.
  • RC4 (Rivest, 1987) — prohibited in TLS by RFC 7465 (2015) after a decade of plaintext-recovery attacks on the keystream bias.
  • Blowfish (Schneier, 1993) — 64-bit block, same Sweet32 problem.

5. Asymmetric / public-key cryptography

Public-key cryptography has two keys per party: a private key the owner guards, and a public key anyone can use. Operations come in two families:

  • Encryption / key encapsulation — anyone with the public key can encrypt a message that only the private-key holder can decrypt.
  • Signature — only the private-key holder can produce a signature; anyone with the public key can verify it.

Most modern asymmetric primitives have asymmetric performance: public operations (encrypt, verify) are cheap; private operations (decrypt, sign) are expensive. This shapes protocol design — TLS uses asymmetric for the handshake, then switches to symmetric for bulk traffic.

RSA

RSA (Rivest, Shamir, Adleman, 1977). Security rests on the hardness of factoring n = p*q where p, q are large primes. Key size doubles every few years as factoring algorithms (general number field sieve) improve and hardware scales:

  • 1024-bit RSA — deprecated; NIST forbade after 2013 for federal use; factored in the lab (the closest published academic factoring is the 829-bit RSA-250 in 2020, ~2700 core-years).
  • 2048-bit RSA — minimum acceptable today (2026); NIST allows through 2030 for legacy.
  • 3072-bit RSA — current recommendation for new systems (matches AES-128 in estimated symmetric-equivalent strength).
  • 4096-bit RSA — common in TLS roots; slow.

Padding schemes matter as much as the modulus:

  • PKCS#1 v1.5 — original encryption padding; vulnerable to Bleichenbacher’s adaptive chosen-ciphertext attack (1998) when an oracle reveals padding validity. Re-broken repeatedly: ROBOT (2017), DROWN (2016), CAT (2023). Still ubiquitous in TLS 1.2 implementations; TLS 1.3 removed RSA key transport entirely.
  • RSA-OAEP (RFC 8017, originally Bellare-Rogaway 1994) — the right encryption padding. Provably IND-CCA2 under the RSA assumption.
  • PKCS#1 v1.5 signatures — acceptable for signatures (the attack does not carry over) but PSS is preferred.
  • RSA-PSS (RFC 8017) — probabilistic signature scheme; tight security proof; mandatory in TLS 1.3 for RSA certificates.

Elliptic-curve cryptography (ECC)

Discrete logarithm in an elliptic curve group. ~10x smaller keys than RSA for equivalent security, ~10x faster signing. Curve choice matters:

  • secp256r1 / NIST P-256 (1999) — most widely deployed; required by FIPS 186-4; underpins most TLS certificates and US government use.
  • secp384r1 / P-384 — higher-security tier; common in TLS roots.
  • secp256k1 — Bitcoin’s curve (and most blockchain ecosystems). Chosen for cheap endomorphism-based speedups; not in FIPS.
  • Curve25519 (Bernstein, 2005) — Montgomery curve at the 128-bit security level; designed to be fast, side-channel friendly, and resistant to implementation mistakes. Used as X25519 for key exchange. Standardized in RFC 7748 (2016).
  • Curve448 / Goldilocks (Hamburg, 2015) — 224-bit-security companion to Curve25519. RFC 7748.

ECDH — Elliptic Curve Diffie-Hellman key exchange. Each party generates a private scalar and shares the corresponding public point. Shared secret is the scalar multiplication of one party’s private by the other’s public.

ECDSA (NIST FIPS 186-4, 2013) — elliptic-curve DSA signatures. Notoriously brittle: a single nonce reuse leaks the private key (Sony PS3 incident, 2010); biased nonces leak the key gradually (Bitcoin wallets, 2013).

EdDSA / Ed25519 (Bernstein, Duif, Lange, Schwabe, Yang, 2011; RFC 8032) — deterministic signatures on Curve25519. Nonces derived from message and key, eliminating the nonce-reuse class of bugs. The modern default for new systems: WireGuard, OpenSSH (since 6.5), GitHub SSH keys, JWT (EdDSA alg), TLS 1.3 (RFC 8422). Ed448 is the higher-security variant.

Diffie-Hellman

Diffie-Hellman key exchange (Diffie and Hellman, 1976). The foundational public-key idea. In its original finite-field form (FFDHE), it uses a large prime p and a generator g; security rests on the discrete log problem in (Z/pZ)*. Largely superseded by ECDH in modern protocols because elliptic curves give equivalent security with smaller parameters. FFDHE survives in TLS 1.3 (RFC 7919 named groups) for jurisdictions that require it; Logjam (Adrian et al, 2015) showed that 512-bit and even 768-bit DH groups were breakable, and that many servers shared a small set of 1024-bit groups.

6. Post-quantum cryptography (PQC)

A scalable quantum computer running Shor’s algorithm (1994) breaks RSA, ECDH, ECDSA, EdDSA, and finite-field DH in polynomial time. Symmetric crypto is mostly fine: Grover’s algorithm gives a quadratic speedup against brute force, so AES-256 retains 128-bit post-quantum security. Hashes need to roughly double their output size for collision resistance against quantum attackers (BHT algorithm).

No quantum computer that can break RSA-2048 exists in 2026; serious estimates range from “ten years” to “thirty years” to “never,” but the harvest-now-decrypt-later threat is real: traffic recorded today against a long-lived public key (TLS, IPsec, encrypted email) can be decrypted later if the key is broken. Critical-confidentiality traffic should already be migrating.

NIST ran a Post-Quantum Cryptography standardization process from 2016 to 2024. Finalists were published as FIPS standards in August 2024:

  • ML-KEM (FIPS 203) — Module-Lattice Key Encapsulation Mechanism, formerly CRYSTALS-Kyber. Lattice-based KEM (key encapsulation, not raw encryption); replaces ECDH for key exchange. Three parameter sets: ML-KEM-512 (AES-128 equiv), ML-KEM-768 (AES-192 equiv, the recommended default), ML-KEM-1024 (AES-256 equiv).
  • ML-DSA (FIPS 204) — Module-Lattice Digital Signature Algorithm, formerly CRYSTALS-Dilithium. Lattice-based signatures; replaces ECDSA / Ed25519. Parameter sets ML-DSA-44 / 65 / 87.
  • SLH-DSA (FIPS 205) — Stateless Hash-based Digital Signature Algorithm, formerly SPHINCS+. Hash-based signatures using only the security of the underlying hash function — the most conservative choice, but signatures are large (8-50 KB) and signing is slow. Held as a fallback if lattice cryptanalysis advances.
  • FN-DSA (FIPS 206 draft, expected 2025) — formerly FALCON. Compact lattice signatures using NTRU lattices and discrete Gaussian sampling. Signature size 600-1300 bytes; signing requires careful constant-time floating-point implementation.

Migration strategy: hybrid schemes. Combine a classical primitive with a PQC primitive so that an attacker must break both. TLS 1.3 deployed `X25519

  • ML-KEM-768hybrid key exchange (X25519MLKEM768, IANA codepoint 0x11EC) in Chrome 124 (April 2024) and Cloudflare; Apple iMessage rolled out PQ3 (a ratchet using ML-KEM) in 2024. SSH supportssntrup761x25519-sha512` (NTRU Prime hybrid) and is adding ML-KEM. Signal added PQXDH (X3DH + PQC) in

Open implementation notes: liboqs (Open Quantum Safe project) is the reference C library; AWS-LC, BoringSSL, and OpenSSL 3.4+ are integrating the FIPS-203/204/205 algorithms; Rust crates pqcrypto and ml-kem track the standards.

7. Key derivation

A key derivation function (KDF) deterministically turns one secret into others, with explicit context separation.

HKDF — extract-and-expand

HKDF (Krawczyk, 2010; RFC 5869) is the standard generic KDF. Two stages:

  • Extract — PRK = HMAC(salt, IKM). Concentrates the entropy of input keying material into a pseudorandom key.
  • Expand — OKM = HMAC(PRK, info || counter) repeated to fill the output length. The info parameter binds the derived key to a context (e.g. “TLS 1.3 handshake traffic key, client”).

HKDF-SHA256 underpins TLS 1.3 key schedule, the Signal Double Ratchet, Noise Protocol, WireGuard. Use it any time you need to turn one secret into multiple application keys.

Password-based KDFs

Passwords have low entropy (50-80 bits at best). A KDF for passwords must be slow and resource-intensive to make offline brute force expensive even with GPUs and ASICs. The progression:

  • PBKDF2 (RFC 2898 / RFC 8018, 2017) — HMAC-based, parameterized by an iteration count. CPU-bound only; GPUs accelerate it cheaply. Minimum acceptable today: PBKDF2-HMAC-SHA256 with 600 000 iterations (OWASP 2023 recommendation). NIST minimum (SP 800-132) is 10 000 — too low for modern threats.
  • bcrypt (Provos and Mazieres, 1999) — Blowfish-based, intrinsically cache-unfriendly. Tunable cost factor. Maximum password length 72 bytes (a real foot-gun: passwords are silently truncated). Aging but still acceptable; bcrypt cost 12 is the floor.
  • scrypt (Percival, 2009; RFC 7914, 2016) — memory-hard: each evaluation requires N*r bytes of memory. Defeats cheap ASICs by forcing them to ship SRAM. Recommended parameters (N=2^17, r=8, p=1) require 128 MB and ~1 second.
  • Argon2 (Biryukov, Dinu, Khovratovich, 2015) — winner of the Password Hashing Competition. Three variants: Argon2d (data-dependent, GPU-resistant but side-channel risky), Argon2i (data-independent, side-channel safe), Argon2id (hybrid; current best practice). RFC 9106 (2021). Recommended parameters per OWASP (2023): m=19 MiB, t=2, p=1 (or m=46 MiB, t=1, p=1).

Rule: never store passwords with a raw hash (even SHA-256). A single modern GPU computes 10+ billion SHA-256 hashes per second; a leaked database of SHA-256 password hashes is effectively plaintext.

8. TLS 1.3

TLS 1.3 (RFC 8446, August 2018) is the current Transport Layer Security standard and the largest cleanup of the protocol since SSL 3.0. The design goals: cut handshake latency, remove every primitive with a history of attacks, and make forward secrecy mandatory.

Handshake structure:

  • 1-RTT — client sends ClientHello with key shares (ECDHE / hybrid) for one or more groups; server responds with ServerHello selecting a group plus its key share, then EncryptedExtensions, Certificate, CertificateVerify, Finished — all encrypted under handshake traffic keys. Client sends Finished and may immediately send application data. Compared to TLS 1.2 (2-RTT before app data), TLS 1.3 saves one round trip — meaningful on mobile networks with 100+ ms RTT.
  • 0-RTT resumption — on a returning session the client can send application data in the first flight using a pre-shared key (PSK). Replay is not prevented at the TLS layer; applications must make 0-RTT data idempotent or detect replay (e.g. via single-use tokens).

Mandatory perfect forward secrecy. Every handshake uses ECDHE (or DHE); session keys are not recoverable from long-term private keys. A compromise of the server’s certificate key tomorrow does not let an attacker decrypt traffic recorded today.

AEAD only. The only allowed ciphersuites are AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, plus AES-128-CCM variants for IoT. Every other mode is gone.

Removed entirely (each was the root of repeated attacks):

  • RSA key transport (Bleichenbacher).
  • CBC modes (BEAST, Lucky13, POODLE).
  • RC4 (keystream bias).
  • SHA-1 (collisions).
  • MD5 (collisions).
  • Compression (CRIME).
  • Renegotiation (rebinding attacks).
  • Custom DH groups (Logjam) — only the curated RFC 7919 FFDHE groups remain.
  • Static DH (no forward secrecy).

Mutual TLS (mTLS) — server requests a client certificate during the handshake. Standard for service-to-service authentication inside zero-trust service meshes (Istio, Linkerd, SPIFFE/SPIRE) and for API security in regulated environments (banking, healthcare).

QUIC + HTTP/3 (RFC 9000, RFC 9114, 2021-2022) carries TLS 1.3 over UDP. TLS handshake messages travel inside QUIC frames; record layer is replaced by QUIC’s packet protection (AES-GCM or ChaCha20-Poly1305 keyed from the TLS key schedule). Connection migration across IP changes; 0-RTT and 1-RTT handshakes; head-of-line-blocking eliminated.

Earlier versions (TLS 1.2, RFC 5246, 2008) remain in wide use but every new system should require 1.3. TLS 1.0 and 1.1 were deprecated by RFC 8996 (2021); browsers removed support in 2020. SSL 2.0 and 3.0 (POODLE, 2014) have been dead for a decade.

9. PKI and certificates

A certificate binds a public key to an identity (a domain name, a person, a device). The binding is asserted by a Certification Authority (CA) signing the certificate with its own key. The verifier trusts the CA’s root certificate out of band (via a root store shipped with the OS or browser).

X.509 v3

X.509 v3 (ITU-T, 1996; profiled by RFC 5280, 2008). DER-encoded ASN.1 structure with fields:

  • Version, serial number, signature algorithm.
  • Issuer — the CA that signed.
  • Validity — notBefore, notAfter.
  • Subject — the identity being certified.
  • SubjectPublicKeyInfo — the public key.
  • Extensions — SubjectAltName (the actual list of DNS names / IP addresses for TLS — the CN field is deprecated and ignored by Chrome since 2017), BasicConstraints (is this a CA?), KeyUsage, ExtendedKeyUsage, AuthorityInformationAccess (OCSP URL), CRLDistributionPoints, CertificatePolicies, SignedCertificateTimestamp (for CT, see below).

CA hierarchy

A trust chain has a self-signed root CA (in the OS/browser root store), one or more intermediate CAs (issued by the root, used for day-to-day signing so the root’s key can stay offline in an HSM), and the end-entity (leaf) certificate issued to the actual server. Cross-signing lets a new CA bootstrap trust by being signed by an established one.

Roots are governed by the Mozilla Root Program (a de facto industry standard followed by Apple and Microsoft) and Chromium’s Chrome Root Program. CAs that misissue (e.g. Symantec, distrusted 2018) lose their inclusion.

Let’s Encrypt and ACME

Let’s Encrypt (ISRG, launched 2015) — free, automated, public CA. By 2026 it issues roughly 60% of public web certificates. Certificates valid for 90 days; renewal expected to be automated via the ACME protocol (RFC 8555, 2019). Domain validation by HTTP-01 (file at /.well-known/acme-challenge/), DNS-01 (TXT record under _acme-challenge), or TLS-ALPN-01.

Clients: certbot (EFF), acme.sh (shell), lego (Go), Caddy server (built-in), Traefik (built-in), AWS Certificate Manager (internal). cert-manager is the standard Kubernetes operator (issues from ACME, an internal CA, or HashiCorp Vault).

The ACME ecosystem is shifting toward short-lived certs: Let’s Encrypt announced 6-day certificates in 2024, in line with the long-running industry push to lower max lifetimes (398 days as of 2020; Apple has proposed 47 days by 2027).

Revocation

A certificate may need to be invalidated before it expires (key compromise, CA mistake, ownership change). Two mechanisms:

  • CRL (Certificate Revocation List) — periodic signed list. Large and slow; rarely used by browsers in real time.
  • OCSP (Online Certificate Status Protocol, RFC 6960) — client queries CA for status. Privacy concern (CA sees every site visit) and reliability concern (CA outage breaks TLS). OCSP stapling (RFC 6066) has the server fetch and cache the OCSP response, then deliver it in the TLS handshake. OCSP must-staple (RFC 7633) enforces the presence.

Browser practice has shifted away from runtime OCSP toward CRLite (Mozilla, 2020+) and Chrome’s CRLSets — compact compressed revocation bundles pushed via auto-update.

Certificate Transparency

CT (RFC 6962, then RFC 9162 v2, 2021). Every publicly trusted certificate is logged in append-only Merkle trees operated by independent log operators. Browsers refuse certificates that do not carry a Signed Certificate Timestamp (SCT) from a sufficient set of qualifying logs. Misissuance becomes detectable: Facebook found a misissued cert against itself in hours (2017); the system has caught CA failures repeatedly. Search via crt.sh, Google’s Trillian log.

Local development

  • mkcert (Filippo Valsorda, 2018) — installs a local root in the system trust store, issues leaf certs for localhost and *.test.
  • step-ca (Smallstep) — full ACME-capable internal CA; runs in a container.
  • CFSSL (Cloudflare’s CA toolkit).

10. Authentication tokens

JWT

JSON Web Token (RFC 7519, 2015). Three Base64URL-encoded pieces: header.payload.signature. Header declares the signing algorithm and key ID; payload is JSON claims (iss, sub, aud, exp, iat, nbf, plus app-defined claims); signature is over base64(header) || "." || base64(payload).

Algorithms:

  • HS256 / HS384 / HS512 — HMAC-SHA. Symmetric: signer and verifier share the key. Suitable for first-party use (same service signs and verifies).
  • RS256 / RS384 / RS512 — RSA-PKCS#1v1.5.
  • PS256 / PS384 / PS512 — RSA-PSS.
  • ES256 / ES384 / ES512 — ECDSA (P-256, P-384, P-521).
  • EdDSA — Ed25519 (or Ed448). RFC 8037.

JWT pitfalls — a notorious foot-gun pile:

  • alg: none — RFC 7519 includes an unauthenticated alg. Libraries that honor it accept any payload as valid. Disable at the library level; never accept none from input.
  • Algorithm confusion / key confusion — server expects RS256 (asymmetric) but a buggy library validates an HS256 token using the public key as the HMAC key. Attacker who knows the public key can forge tokens. Pin the expected algorithm on verify.
  • Weak HMAC keys — HS256 with a short secret is offline-brute-forceable. Use 256+ bits of random key material.
  • Missing exp check / clock skew — verify exp and nbf strictly, with a small allowed skew.
  • kid injection — kid field used as a path or SQL parameter is a classic injection vector.

Use a library that enforces sane defaults (jose for Node/JS, PyJWT configured strictly, golang-jwt/jwt/v5, jjwt for Java).

Alternatives

  • PASETO (Platform-Agnostic Security Tokens) — designed by Scott Arciszewski as a JWT replacement. Versioned protocol (v3, v4) that pins algorithm by version: no algorithm negotiation, no alg: none, no key confusion. Two purposes: local (symmetric AEAD) and public (Ed25519 signature).
  • Macaroons (Google, 2014) — bearer credentials with attenuable caveats. Holder can derive a more restricted token without contacting the issuer (e.g. “valid for path /photos/me, IP 1.2.3.0/24, expires in 5 minutes”). Used by Tarsnap, HyperDex, Storj.
  • Biscuit — modern macaroon-inspired token with a Datalog policy layer.

11. Key management

A cryptosystem is only as strong as its weakest key. Real systems separate data keys (used to encrypt application data, often short-lived) from key-encryption keys (KEK) or master keys (long-lived, stored in hardware).

HSMs

A Hardware Security Module stores keys in tamper-resistant hardware and performs cryptographic operations without ever exposing the private key. Standardized via PKCS#11 (Cryptoki) and KMIP. FIPS 140-3 levels 2-4 cover HSM physical security.

Vendors and clouds:

  • Thales Luna, Entrust nShield, Utimaco — on-prem network HSMs.
  • AWS CloudHSM — Cavium-based; single-tenant.
  • Google Cloud HSM — Marvell LiquidSec; integrated into Cloud KMS.
  • Azure Dedicated HSM — Thales Luna in Azure.
  • YubiHSM 2 — small USB HSM for offline or edge use.

Cloud KMS

Multi-tenant managed key services. Higher-level than raw HSMs; expose Encrypt, Decrypt, Sign, Verify, GenerateDataKey, with the master key never leaving the service.

  • AWS KMS — Customer Master Keys (CMKs); per-key IAM; integrated with S3, EBS, RDS, Secrets Manager. KMS keys cost $1/month per CMK.
  • Google Cloud KMS — symmetric and asymmetric keys, software or HSM backing.
  • Azure Key Vault — keys, secrets, certificates.
  • HashiCorp Vault — open-source, self-hosted; richer secret engines (PKI, database creds, SSH CA, AWS dynamic creds). Transit engine offers KMS-equivalent operations.

Envelope encryption

Pattern: generate a fresh per-object data encryption key (DEK), encrypt the data with the DEK locally, then encrypt the DEK with a KMS-held master key. Store the encrypted DEK alongside the data. Decryption: ask KMS to unwrap the DEK, decrypt locally. The KMS is in the small-data critical path (per-object unwrap) but not the bulk-data path. Used by S3 SSE-KMS, GCS CMEK, Azure Storage CMK.

Trusted Platform Modules

TPM 2.0 (TCG spec, ISO/IEC 11889) — a small crypto coprocessor on most modern PCs and servers, present on every Windows 11 device. Provides hardware-bound keys (a key sealed to a TPM is unusable on a different machine), platform attestation (the TPM signs the boot measurements so a remote verifier can confirm the device is in a known state), and Random Number Generation. Used for BitLocker key sealing, Windows Hello, fTPM on AMD/Intel SoCs.

Confidential computing

Trusted Execution Environments protect data in use, not just at rest and in transit:

  • Intel SGX (2015) — enclaves at the page level; attack surface includes many side channels (Foreshadow, MDS, AEPIC Leak); SGX server scaling removed in 12th-gen Core but retained in Xeon.
  • Intel TDX (Trust Domain Extensions, 2023) — VM-level confidential computing; replaces SGX on server.
  • AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging, Zen 3+) — encrypted VMs with memory integrity. Used by Azure Confidential VMs, Google Cloud confidential VMs.
  • ARM CCA (Confidential Compute Architecture, Realm Management Extension, ARMv9.2) — emerging.
  • Apple Secure Enclave — separate co-processor on every Apple device since the A7 (2013); stores fingerprint/Face ID templates, signs Apple Pay transactions, holds the Keychain master key.
  • Project Oak / Confidential Federated Learning — research stacks built on these primitives.

12. Random number generation

A cryptographic system collapses to nothing if its randomness is predictable. The 2008 Debian OpenSSL bug (a maintainer commented out the entropy source, producing only 32768 distinct keys across all Debian SSL keys for two years) is the canonical disaster.

Use the OS CSPRNG. Every modern OS exposes a kernel-mixed, fast-key-erasure pseudorandom generator seeded from hardware entropy:

  • Linux — getrandom(2) syscall (since 3.17, 2014). Blocks at boot until the pool is initialized, then returns immediately. /dev/urandom has the same backing pool. ChaCha20-based fast-key-erasure RNG since 5.18.
  • Windows — BCryptGenRandom (CNG); the higher-level CryptGenRandom is a wrapper.
  • macOS / iOS / BSD — arc4random_buf (ChaCha20-based despite the name); getentropy(2) is the POSIX-style call.
  • WASI / WebCrypto — crypto.getRandomValues and crypto.subtle.

Hardware RNGs:

  • Intel RDRAND / RDSEED (Ivy Bridge, 2012+). RDSEED gives raw hardware entropy; RDRAND mixes it through a CTR-DRBG (NIST SP 800-90A).
  • ARM RNDR / RNDRRS (ARMv8.5-A).
  • TPM 2.0’s RNG.

Never use language-level “random” for crypto:

  • C rand(), POSIX random(), drand48 — all are LCGs or similar; output is predictable from a few samples.
  • Java java.util.Random — same issue. Use SecureRandom.
  • Python random — Mersenne Twister; predictable. Use secrets module (since 3.6) or os.urandom.
  • JavaScript Math.random() — implementation-defined; not secure. Use crypto.getRandomValues (browser) or crypto.randomBytes (Node).
  • Go math/rand — explicitly not secure. Use crypto/rand.
  • Ruby rand — not secure. Use SecureRandom.

13. Side-channel attacks

An adversary who cannot see the secret directly may still recover it from a side channel — timing, power consumption, electromagnetic emanation, acoustic noise, cache state, branch predictor state.

Timing

If a cryptographic operation’s running time depends on secret data, an attacker who can measure timing (often remotely) recovers the secret. Classic cases: comparing a MAC tag byte-by-byte returning on first mismatch (Coda, 2009); RSA-CRT timing leaks during modular reduction (Brumley-Boneh remote timing attack on OpenSSL, 2003); Lucky13 (TLS CBC, 2013); MAC verification via strcmp.

Mitigation: constant-time code. Compare with CRYPTO_memcmp / subtle.ConstantTimeCompare / hmac.compare_digest / crypto_verify_16. Avoid secret-dependent branches and array indices. Compiler flags do not guarantee this; in modern stacks, the compiler may even reintroduce a branch into hand-written constant-time code, so library authors use inline asm or volatile tricks.

Power and EM analysis

Differential Power Analysis (DPA) (Kocher, Jaffe, Jun, 1999). The power trace of a smartcard processing an AES key reveals the key after thousands of traces and a statistical analysis of the Hamming-weight leakage. Mitigation: masking (split secret into shares whose joint distribution matches the secret but each share is uniform), shuffling, randomized execution order.

TEMPEST / EM — same idea via electromagnetic emissions. Smartcard and HSM evaluations (Common Criteria EAL4+) include DPA and EM-leakage resistance.

Cache and microarchitectural side channels

  • Flush+Reload (Yarom, Falkner, 2014) — measure shared cache state to infer victim’s table accesses. Devastating against AES T-table implementations.
  • Prime+Probe — pre-fill a cache set, wait, measure which lines were evicted.
  • Spectre (Kocher et al, 2018) — speculative execution leaks across privilege boundaries via cache timing. Meltdown — similar, specific to kernel page tables. MDS / RIDL / Fallout / ZombieLoad (2019) — line-fill buffer and store buffer leaks. Downfall (Intel AVX gather, 2023). Mitigations are partial and costly.

Defensive practice

  • Use libraries whose authors have done constant-time analysis (libsodium, BoringSSL, RustCrypto, BearSSL). Do not hand-roll modular arithmetic.
  • For AES on hardware without AES-NI, prefer ChaCha20 (no S-box).
  • For ECC, use formulas designed for constant-time (Montgomery ladder, complete addition formulas), and curves with order close to a power of two (Curve25519, P-384) so scalar blinding is straightforward.
  • Multi-tenant cloud environments require microarchitectural mitigation: disable SMT for crypto workloads, dedicated tenancy for the highest threat models.

14. Common pitfalls

A long but non-exhaustive list of failures observed in real systems.

  • Nonce reuse in AES-GCM. A single key+nonce reuse with AES-GCM reveals the GHASH authentication subkey and the keystream for both messages. Forgery becomes trivial. Storing the nonce counter in volatile memory across process restarts has caused this in shipping VPN products. Use a deterministic counter persisted with the key, or AES-GCM-SIV / AES-SIV if nonces might collide.
  • RSA-PKCS#1v1.5 encryption padding. Bleichenbacher (1998) gave a chosen- ciphertext attack against any oracle that distinguishes “padding valid” from “padding invalid.” Re-emerges every few years: ROBOT, DROWN, CAT. Use OAEP for encryption.
  • Rolling your own crypto. Schneier’s law: “Any person can invent a security system so clever that they themselves can’t think of a way of breaking it.” Real crypto needs years of analysis. Use libsodium or an equivalent.
  • Storing passwords with SHA-256 (or any unsalted hash). A leaked database with SHA-256 hashes is broken on a single GPU within hours for any password humans pick. Use Argon2id (or bcrypt at cost >= 12). Salt per-user.
  • Hardcoded keys in source. GitHub scans for AWS keys; attackers scan for everything else. Use a secret manager (Vault, AWS Secrets Manager, doppler, 1Password) and rotate any key that ever touched a Git history, even if “the commit was reverted.”
  • Missing rate limiting on auth endpoints. Without a rate limit, a password endpoint is a free oracle for credential stuffing. Best practice: bcrypt-style slow verification plus exponential-backoff rate limiting per account and per IP.
  • JWT alg: none and algorithm confusion. See section 10.
  • TLS misconfiguration. Mozilla’s “Server Side TLS” guide (intermediate profile) is the right default for public services; use testssl.sh or Mozilla’s Observatory to check. Common errors: leaving SSL 3 / TLS 1.0 enabled “for compatibility,” missing intermediate cert in the chain (the cert validates in your browser but not in mobile apps with a smaller trust store), no HSTS preload.
  • Reusing keys across purposes. A signing key used to authenticate JWTs must not be used for TLS, encryption, or anything else. Domain-separate with HKDF.
  • Failing to verify hostname. TLS verifies the cert chain; the application must also verify the cert’s SubjectAltName matches the expected hostname. Many client libraries default to verifying both; some (older Python urllib, naive Go http.Transport) need explicit config.
  • Ignoring TLS errors / pinning to verify=False. A constant in production incidents.
  • Long-lived signing certs without revocation. A leaked code-signing cert is forever if revocation is not honored. Use short-lived certs (Sigstore Fulcio: 10 minutes) or hardware-bound keys.
  • Insufficient log scrubbing. Tokens, keys, cookies, signed URLs end up in access logs, request traces, error reports. Define a redaction list and enforce at log ingest.

15. Libraries

When choosing a cryptographic library, the safest defaults usually come from high-level, opinionated APIs. Lower-level libraries are more flexible but more dangerous.

High-level, safe defaults:

  • libsodium (Frank Denis, 2013-present) — modernized fork of NaCl (Bernstein, Lange, Schwabe). High-level boxes (crypto_secretbox, crypto_box, crypto_sign), small API surface, hard to misuse. C with bindings for every language. The default recommendation for application code.
  • Google Tink (Java, C++, Go, Obj-C, Python) — typed key abstractions, envelope encryption, KMS integration. Built by Google’s security team.
  • NaCl (Networking and Cryptography Library) — the original Bernstein/Lange library. libsodium is the production descendant.

General-purpose:

  • OpenSSL 3 (2021+; LTS branches 3.0 and 3.2). The de facto standard for TLS and PKI. Provider-based architecture; FIPS provider available. Large API; many pitfalls in low-level use.
  • BoringSSL (Google) — fork of OpenSSL maintained for Chromium, Android, Google services. No stable API; not for third-party use, but its code is widely audited.
  • AWS-LC — fork of BoringSSL by AWS, FIPS 140-3 validated.
  • BearSSL (Pornin) — small, constant-time, no dynamic allocation; for embedded and audited environments.

Language-native:

  • RustCrypto organization — aes-gcm, chacha20poly1305, ed25519-dalek, x25519-dalek, rsa, sha2, argon2. Pure-Rust, audited.
  • ring (Rust, by Brian Smith) — opinionated, BoringSSL-derived primitives.
  • Go crypto/* (standard library) — crypto/tls, crypto/ecdsa, crypto/aes, crypto/cipher, crypto/rand. Well-maintained by the Go security team. The golang.org/x/crypto extension adds Curve25519, Argon2, ChaCha20-Poly1305 (now mainline), SSH, age.
  • Python — cryptography (PyCA, Rust-backed for primitives), pynacl (libsodium binding), cryptography.hazmat for low-level when needed. Avoid pycrypto (unmaintained since 2014) and pycryptodome for new code.
  • Java — JCE/JCA with Bouncy Castle as the standard third-party provider; Tink for high-level. Conscrypt (Google) for TLS.
  • Node.js — built-in crypto (OpenSSL-backed); jose for JWT/JWS/JWE.

Specialty:

  • age (Filippo Valsorda) — modern file encryption tool replacing PGP for most use cases. X25519 + ChaCha20-Poly1305 + scrypt.
  • Sigstore Cosign — keyless signing for software artifacts; built on Fulcio (CA), Rekor (transparency log), and short-lived OIDC-bound keys.
  • noise-protocol implementations (Noise Framework) — building block for handshake protocols; underpins WireGuard, WhatsApp, Lightning Network.

16. Compliance and regulatory framing

Cryptography is one of the few engineering disciplines where regulatory expectations heavily shape implementation choices.

  • FIPS 140-3 (NIST, since 2019; supersedes 140-2). Specifies security requirements for cryptographic modules used in US federal systems. Validation levels 1-4 (physical security increases with level). FIPS-only algorithm and parameter restrictions are listed in NIST SP 800-131A. FIPS validation is expensive (often $100k+ and 12+ months) but mandatory for federal sales and many state/regulated industries.
  • Common Criteria (ISO/IEC 15408) — international evaluation framework; Evaluation Assurance Levels EAL1-EAL7. Smartcards and HSMs commonly EAL4+ or EAL5+; OS kernels EAL4+ (Windows, RHEL).
  • NIST SP 800-53 — federal control catalog (US). The crypto-relevant family is SC (System and Communications Protection); SC-13 mandates FIPS-validated modules.
  • HIPAA (US, healthcare) — does not name specific algorithms but requires “appropriate encryption” for ePHI at rest and in transit. De facto baseline: AES-128+, TLS 1.2+, FIPS-validated modules in covered enterprise systems.
  • PCI-DSS (Payment Card Industry, v4.0 2022) — Requirement 4 covers encryption in transit (TLS 1.2+); Requirement 3 covers stored cardholder data (strong cryptography, key management). Restrictions on “strong cryptography” updated annually; SHA-1 and TLS 1.0 are out.
  • GDPR + eIDAS (EU) — GDPR requires “appropriate technical measures”; eIDAS (Regulation 910/2014, with eIDAS 2.0 in 2024) defines qualified electronic signatures and the EU Digital Identity Wallet, anchored in qualified certificate authorities.
  • CCPA / CPRA (California) — encryption is a safe harbor for breach notification.
  • Export control (US) — historically severe; EAR Category 5 Part 2 covers “information security” items. Substantially loosened since 2010: most mass-market software with standard cryptography (TLS, AES) is now in License Exception ENC. Strong-crypto export to embargoed jurisdictions (Cuba, Iran, North Korea, Syria, Russia/Crimea since 2014/2022) remains restricted. Open-source publication is generally allowed under Section 742.15(b) of the EAR (with a notification email).
  • China cryptography law (2020) — mandates use of domestic algorithms (SM2 elliptic-curve, SM3 hash, SM4 block cipher) in certain commercial and government contexts; affects vendors selling into China.
  • PQC migration mandates — US National Security Memorandum NSM-10 (2022) directs federal agencies to inventory cryptographic systems and prepare migration plans; CNSA 2.0 (NSA, 2022) requires PQC algorithms in NSS by 2035, with software/firmware signing migrating first by 2030. Expect similar mandates in EU and UK.

17. Cross-references

  • distributed-systems-fundamentals — consensus uses signatures for authenticated rounds; storage layers depend on hashing for content-addressing and Merkle commitments.
  • auth-authz (TBD) — identity providers, OIDC, OAuth 2.1, WebAuthn / passkeys, the authorization layer that sits above the primitives in this note.
  • kubernetes-deep — Secrets (often unencrypted at rest by default until KMS is configured), cert-manager for ACME, SPIFFE/SPIRE for workload identity, sealed-secrets for GitOps.
  • _index — number theory (factoring, discrete log), finite-field and elliptic-curve arithmetic, lattices.

18. Citations

Textbooks:

  • Schneier, B. Applied Cryptography, 2nd ed. Wiley, 1996. Historically foundational; many primitives discussed are now deprecated, but the framing remains valuable.
  • Katz, J. and Lindell, Y. Introduction to Modern Cryptography, 3rd ed. CRC Press, 2020. Standard graduate text.
  • Boneh, D. and Shoup, V. A Graduate Course in Applied Cryptography. Online draft, version 0.6, 2023. Free at toc.cryptobook.us.
  • Aumasson, J.-P. Serious Cryptography, 2nd ed. No Starch Press, 2024. Practitioner-oriented.

Standards (NIST FIPS):

  • FIPS 180-4 — Secure Hash Standard (SHA-1, SHA-2 family), 2015.
  • FIPS 197 — Advanced Encryption Standard (AES), 2001.
  • FIPS 198-1 — HMAC, 2008.
  • FIPS 202 — SHA-3 Standard, 2015.
  • FIPS 186-5 — Digital Signature Standard (DSA, ECDSA, EdDSA), 2023.
  • FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), 2024.
  • FIPS 204 — Module-Lattice-Based Digital Signature Algorithm (ML-DSA), 2024.
  • FIPS 205 — Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), 2024.
  • FIPS 206 (draft) — FN-DSA, expected 2025.

Standards (NIST SP):

  • SP 800-38A — Block Cipher Modes of Operation.
  • SP 800-38D — Galois/Counter Mode.
  • SP 800-56A — Diffie-Hellman key agreement.
  • SP 800-90A Rev 1 — DRBG mechanisms.
  • SP 800-108 — KDF in counter mode.
  • SP 800-131A Rev 3 — Transitioning to stronger cryptographic algorithms.
  • SP 800-132 — PBKDF2 (under revision).
  • SP 800-208 — Stateful hash-based signatures (LMS, XMSS).

RFCs:

  • RFC 2104 — HMAC (1997).
  • RFC 5246 — TLS 1.2 (2008).
  • RFC 5280 — X.509v3 / CRL profile (2008).
  • RFC 5869 — HKDF (2010).
  • RFC 6066 — TLS Extensions, including OCSP stapling (2011).
  • RFC 6962 — Certificate Transparency v1 (2013); RFC 9162 v2 (2021).
  • RFC 7519 — JSON Web Token (2015).
  • RFC 7748 — Curves Curve25519 and Curve448 (2016).
  • RFC 7914 — scrypt (2016).
  • RFC 8017 — PKCS#1 v2.2 (RSA, OAEP, PSS) (2016).
  • RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA, Ed25519) (2017).
  • RFC 8439 — ChaCha20 and Poly1305 (2018).
  • RFC 8446 — TLS 1.3 (2018).
  • RFC 8452 — AES-GCM-SIV (2019).
  • RFC 8555 — Automatic Certificate Management Environment (ACME) (2019).
  • RFC 8996 — Deprecating TLS 1.0 and 1.1 (2021).
  • RFC 9000 — QUIC (2021).
  • RFC 9106 — Argon2 (2021).
  • RFC 9114 — HTTP/3 (2022).

Foundational papers:

  • Diffie, W. and Hellman, M. “New Directions in Cryptography.” IEEE Transactions on Information Theory, 1976.
  • Rivest, R., Shamir, A., Adleman, L. “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems.” Communications of the ACM, 1978.
  • Krawczyk, H., Bellare, M., Canetti, R. “HMAC: Keyed-Hashing for Message Authentication.” RFC 2104 / CRYPTO 1996.
  • Bernstein, D. J. “Curve25519: New Diffie-Hellman Speed Records.” PKC 2006.
  • Bernstein, D. J. et al. “High-speed high-security signatures.” CHES 2011 (Ed25519).
  • Kocher, P. “Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems.” CRYPTO 1996.
  • Bleichenbacher, D. “Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1.” CRYPTO 1998.
  • Wang, X. and Yu, H. “How to Break MD5 and Other Hash Functions.” EUROCRYPT 2005.
  • Stevens, M. et al. “The first collision for full SHA-1.” CRYPTO 2017 (SHAttered).
  • Adrian, D. et al. “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice.” CCS 2015 (Logjam).
  • Biryukov, A., Dinu, D., Khovratovich, D. “Argon2: New Generation of Memory-Hard Functions for Password Hashing.” 2015 (PHC winner).

Graph View