2029 PQ Deadline: Filippo Valsorda Overhauls Crypto Right Answers — All Asymmetric Algorithms Must Change

The Cryptographic Right Answers is a long-standing tradition started by Colin Percival (2009), continued by Thomas Ptacek (2015), and updated by Latacora (2018, 2024). In 2026, Filippo Valsorda — former Go cryptography lead — publishes a new edition driven by a single seismic shift: the industry now agrees that post-quantum migration must be completed by 2029 , leaving only three years.

What stays the same: symmetric cryptography

Grover's algorithm does not pose a practical threat; 128-bit brute-force is not feasible. The recommendation remains 256-bit keys (which also mitigates multi-target attacks). No need to change TLS cipher suites — Cobblestone-128's 128-bit key is acceptable because it includes a dedicated multi-target analysis.

Encrypting data: don't manage nonces yourself

XAES-256-GCM : a standard KDF + AES-GCM construction packaged as an extended-nonce AEAD.

XChaCha20Poly1305 : also supports random nonces.

Plain AES-GCM or ChaCha20Poly1305 with random nonces are only safe if you guarantee fewer than one billion messages per key. For large messages, do not feed the whole payload to an AEAD at once (that forces handling plaintext before authentication). Use a STREAM construction; the author recommends Cobblestone-128 , a TLS-derived STREAM variant. (Filippo discloses that XAES-256-GCM and Cobblestone are his own designs but have seen wide external adoption.)

HMAC, hashing, random IDs: old friends still reliable

Symmetric "signature" : HMAC-SHA-256 — authenticate raw byte strings, not structured data, to avoid canonicalization/parser mismatches.

Hashing : SHA-2 remains sufficient; prefer SHA-512/256 (immune to length-extension). For hashing multiple objects together (e.g., multiple columns), use SequenceHash — do not concatenate yourself.

Random IDs : 32 random bytes from the OS CSPRNG. UUIDv4 (~128 bits) is usually fine unless you need >2^48 unique values.

Password handling: ask if you really need a password

Recommended: Argon2id (m=64 MiB, t=2, p=1) or scrypt (N=2^16, r=8, p=1). Bcrypt removed due to its 72-byte truncation issue. Both use the same memory; scrypt costs ~1.5× more CPU but ~¼ GPU time, so Argon2id is slightly preferred. More importantly: can you replace passwords with passkeys (phishing-resistant) or email magic links + OIDC (not SAML)? Current passkeys are not post-quantum, but the author argues quantum attackers could only target a specific site after obtaining its database or intercepting a login.

The three "complete overhaul" areas: all asymmetric algorithms change

Key exchange: X25519+ML-KEM-768 (hybrid)

Historical answers: Percival 2009: 2048-bit Group #14, generator 2 Ptacek 2015: DH-2048 or NaCl Latacora 2018: probably nothing, or Curve25519 Latacora 2024: X25519+ML-KEM-768 Filippo 2026: X25519+ML-KEM-768 (inside a secure standard protocol)

Non-PQ key exchange is a real, urgent risk because of harvest-now-decrypt-later attacks. Do not design your own protocol; use the standardized hybrid:

TLS: X25519MLKEM768 SSH: mlkem768x25519-sha256 HPKE / age: MLKEM768-X25519 (also called X-Wing)

If adopting a hybrid means staying on classic non-PQ key exchange for even one more month, switch directly to pure ML-KEM-768 . Other PQ KEMs are either impractical (HQC-KEM, FrodoKEM) or broken (Classic McEliece). Rule of thumb: if the name doesn't contain ML-KEM or X-Wing, don't use it.

Asymmetric encryption: HPKE arrives

Historical answers: Percival 2009: RSAES-OAEP Ptacek 2015: NaCl Latacora 2018: NaCl/libsodium (box) Latacora 2024: tricky, wait for mature PQ Filippo 2026: HPKE (MLKEM768-X25519 = X-Wing, HKDF-SHA256, AES-128-GCM) or age with PQ keys

HPKE provides a standard for hybrid encryption (asymmetric + symmetric, not classic+PQ). For higher-level envelopes, multiple recipients, or CLI use, choose age with its new age1pq prefix keys based on MLKEM768-X25519; YubiKey and Secure Enclave plugins are adding PQ support. The PQ HPKE KEM is still draft (split across four drafts), prompting Filippo to write filippo.io/hpke-pq; however, authors have frozen the wire format and major crypto libraries have shipped implementations, so it is safe to use . Avoid: RSA, NaCl box, OpenPGP, encrypted email.

Digital signatures: ML-DSA-44

Historical answers: Percival 2009: RSASSA-PSS Ptacek 2015: NaCl, Ed25519, or RFC 6979 Latacora 2018: NaCl or Ed25519 Latacora 2024: short-term Ed25519, otherwise Ed25519+ML-DSA-65 Filippo 2026: ML-DSA-44

Signatures must also migrate to PQ. Concrete guidance:

Use ML-DSA-44 directly.

For pre-hashing, use "external-μ (Mu)" signing, not HashML-DSA.

Store only the 32-byte seed .

Why not hybrid/composite signatures? Hybrid authentication is more complex and less useful than hybrid key exchange. Either you have a key-rotation plan (so you can rotate away from the classic half when broken) or your time horizon is long enough that you must assume the classic half will eventually fall. ML-KEM-768 targets NIST Level 3; ML-DSA-44 targets Level 2, already above 128-bit security with margin. Sole exception: SSH keys — OpenSSH 10.6 chose ssh-mldsa44-ed25519; the author calls this a mistake but deviating from the ecosystem is also a mistake. Reminder: asymmetric signatures are overused and now expensive. Prefer HMAC; replace signed JWTs with random session tokens; for public commitments consider transparency logs. Avoid: RSA, ECDSA, Ed25519, stateful signatures (LMS/XMSS), HashML-DSA, ML-DSA "half-expanded keys", composite signatures, OpenPGP.

Deployment choices: TLS libraries and backup

Possibly the most "impractical" advice: don't use OpenSSL

OpenSSL has made a series of puzzling, problematic decisions over years. The pyca/cryptography team summarized their experience as "a negative trajectory over many years"; HAProxy and curl echo similar criticism. Recommended alternatives:

rustls or Go crypto/tls : memory-safe.

If C is required: BoringSSL or AWS-LC (versioned releases).

s2n-tls : interesting when libssl compatibility isn't needed.

Disclosure: the author is a maintainer of Go crypto/tls.

Whichever you pick, verify it prefers X25519MLKEM768 (requires TLS 1.3). Cloud load balancers may need manual PQ policy selection; RHEL 9 and derivatives require explicit enabling. The article also lists libraries with core-responsibility CVEs (GnuTLS, Mbed TLS, wolfSSL, Botan) — consult the original footnotes.

PKI

Fully controlled applications: self-manage ML-DSA-44 X.509 certificates , self-signed or private root.

Public websites: integrate a mainstream, well-supported ACME client and keep it updated. Merkle Tree Certificates arrive in 2027; prepare for that transition.

Backup: restic replaces Tarsnap

Previous editions always recommended Tarsnap; this edition switches to restic + a sufficiently long random password . Restic uses only symmetric cryptography (quantum-resistant), whereas Tarsnap's asymmetric layer is entirely RSA. The author feels "like betraying a predecessor," but technically only low-privilege keys are at risk (write-only key decrypts archives, read-only key forges archives). Still, with quantum computers looming, it's a liability.

Three actions you can take today

Audit your TLS stack : confirm it enables X25519MLKEM768 (needs TLS 1.3); OpenSSL ≥ 3.5.

Inventory your signatures : which truly need asymmetric signatures? Replace with HMAC or random tokens where possible; plan migration of the rest to ML-DSA-44.

Audit your code : write in memory-safe languages (Rust, Go, etc.) and run the strongest LLM you can afford over the codebase.

2029 is close. Symmetric crypto has already held half the line for the quantum era; the other half is time to act.

Original source: Filippo Valsorda, (Post-Quantum) Cryptographic Right Answers , https://words.filippo.io/right-answers/