Post-quantum Cryptographic Right Answers rewrites asymmetric picks with 2029 deadline

A new edition, three years before the deadline

The "Cryptographic Right Answers" tradition — short documents that tell developers exactly which cryptographic tools to reach for — gained a new entry on 12 October 2026, published on the words.filippo.io blog and boosted to Hacker News' front page. Colin Percival wrote the first version in 2009, Thomas Ptacek followed in 2015, and Latacora updated the series in 2018 and again in 2024.

The new post justifies a fresh edition with timing. According to its author, the post-quantum migration schedule shifted sharply in early 2026, and there is now agreement across the field that the transition should be complete by 2029 — roughly three years from publication. The consequence is stark: every asymmetric recommendation has changed since 2018, and most have changed since 2024, while the symmetric layer stays largely as it was.

The cheat sheet

The condensed advice in the post:

• Data encryption: a cloud KMS where one is available; otherwise XAES-256-GCM or XChaCha20Poly1305 with random nonces, and Cobblestone-128 for payloads beyond a few megabytes.
• Symmetric key length: 256-bit if you must choose, but not worth agonising over.
• Symmetric authentication: HMAC-SHA-256.
• Hashing: SHA-2, with a real multihash construction such as SequenceHash when hashing several values together.
• Random identifiers: 32 random bytes.
• Passwords: Argon2id or scrypt — with passkeys floated as the better alternative.
• Key exchange: X25519 combined with ML-KEM-768, inside a proper standard protocol.
• Public-key encryption: HPKE using the X-Wing hybrid (MLKEM768-X25519), HKDF-SHA256 and AES-128-GCM, or age with post-quantum keys.
• Signatures: ML-DSA-44.
• Websites and client-server apps: a cloud application or network load balancer, or else rustls, Go's crypto/tls, BoringSSL, AWS-LC or s2n-tls, paired with a popular, updated ACME client.
• Online backups: restic with a long random password.

The post assumes readers are not bound by a strict compliance regime. It describes the picks as largely compatible with FIPS 140 and advises anyone under something stricter, such as CNSA 2.0, to substitute as needed.

Symmetric answers barely move

Per the post, symmetric cryptography comes through the quantum era essentially untouched: Grover's algorithm offers no practical advantage worth engineering around. HMAC, SHA-2 and 256-bit randomness therefore carry over from earlier editions, and the interesting refinements concern misuse.

For local encryption, the post recommends AEADs that take random nonces of at least 128 bits — XAES-256-GCM or XChaCha20Poly1305 — rather than NaCl's secretbox, which it describes as little more than a wrapper around the less common XSalsa20+Poly1305. Plain AES-GCM or ChaCha20Poly1305 with random nonces is acceptable only when you are certain a key will protect fewer than about a billion messages.

Large data gets its own rule: never hand a single huge message to an AEAD, and never touch unauthenticated stream ciphers. Use a STREAM-style construction instead. Among the many competing options, the post endorses Cobblestone-128, a TLS-derived variant that already ships in pyca/cryptography and is on its way into Go's standard library.

Key size advice is deliberately relaxed: 256-bit keys rule out multi-target attacks, but 128-bit keys are fine when the suite's design accounts for that threat, as Cobblestone's does. Forcing 256-bit cipher suites in TLS preferences is called unnecessary, and AES-256 is noted as slower than AES-128 in practice. For HMAC, the guidance is to authenticate a verbatim copy of the bytes you are protecting — not a re-serialised object — to sidestep canonicalisation and parser-alignment bugs, and to compare tags with constant-time functions.

Hashing stays with SHA-2, preferring SHA-512/256 where available since it resists length-extension attacks. SHA-3 is called unnecessary and slow, though not wrong; if you already carry Keccak code for ML-KEM and ML-DSA, drawing 32 bytes from SHAKE128 is acceptable. Multi-value hashing should go through SequenceHash with SHA-2 or TupleHash with SHA-3 rather than home-made schemes.

New meta-rules join the list

Beyond primitives, the post adds two process-level recommendations: build in a memory-safe language, and have a strong LLM review your code, since — in the author's assessment — modern models are now genuinely good at finding bugs. Both are presented as standing right answers rather than optional extras.

Why it matters

The 2029 deadline applies to the asymmetric layer — TLS handshakes, key exchange, signatures and public-key encryption — which sits inside nearly every application, usually via libraries and protocols rather than code teams wrote themselves. Guidance this specific lowers the cost of acting early: the recommended hybrids keep today's classical security while adding quantum resistance, and most are already available in maintained libraries. Teams that inventory their cryptographic dependencies now and roll out hybrid handshakes early face a routine upgrade; teams that wait face a compressed, riskier migration. The inclusion of LLM-based review also signals that even security review, historically scarce and expensive, is becoming practical for ordinary projects.