Valsorda's Post-Quantum Cryptographic Right Answers: ML-KEM-768 Hybrids, ML-DSA-44 and Argon2id Settings

Filippo Valsorda published "(Post-Quantum) Cryptographic Right Answers" on October 12, 2026, a checklist of which primitives to choose for new systems, with the post-quantum transition, in his words, needing to "complete by 2029". The recommendations are one person's, not a standard, but they name specific parameter sets that engineers can act on.

Key exchange: X25519 plus ML-KEM-768

The post says to use X25519 combined with ML-KEM-768, and gives the names this takes in each protocol: X25519MLKEM768 in TLS, mlkem768x25519-sha256 in SSH, and MLKEM768-X25519 in HPKE and age. If a hybrid would delay migration by even a month, it says to use pure ML-KEM-768 instead. P-256 with ML-KEM-768 is acceptable but less common.

ML-KEM-768 is one of three parameter sets in NIST's FIPS 203, published August 13, 2024, alongside ML-KEM-512 and ML-KEM-1024. The post recommends the middle one and rejects ML-KEM-512. It also says OpenSSL 3.5 is the first release with X25519MLKEM768, so earlier versions should be avoided.

Signatures: ML-DSA-44, and one hybrid he regrets

For post-quantum signatures the post says to use ML-DSA-44, signing with external-μ and storing keys as 32-byte seeds. It describes ML-DSA-44 as NIST category 2, with margin above the 128-bit level. SLH-DSA is called slow and large, and FN-DSA is not yet available.

The post advises against hybrid or composite signatures, with one named exception: OpenSSH 10.6's ssh-mldsa44-ed25519, which the author calls a mistake. Merkle Tree Certificates, the post says, are expected to roll out in 2027.

The rest of the checklist

The symmetric advice is unchanged by quantum computers, because the post says Grover's algorithm does not matter for it. The table lists the post's other picks.

Task	Recommendation in the post
Symmetric encryption	XAES-256-GCM or XChaCha20Poly1305 with random nonces; 256-bit keys
Message authentication	HMAC-SHA-256, compared in constant time
Hashing	SHA-2; SHA-512/256 if available; 32 random bytes for random IDs
Passwords	Argon2id with m=64 MiB, t=2, p=1, or scrypt with N=2^16, r=8, p=1
Asymmetric encryption	HPKE with MLKEM768-X25519, HKDF-SHA256 and AES-128-GCM, or age with age1pq keys
Backups	restic with a long random password

On passwords, the post prefers passkeys wherever passwords are needed only for login. It avoids SHA-1, MD5 and truncation below 256 bits unless a cryptographer approves. For backups, it points out that Tarsnap's asymmetric layer is RSA, which it counts as a risk against future quantum computers.

A worked example: auditing one service against the post

Take a service that terminates TLS itself, hashes passwords and encrypts files at rest. The post gives a concrete test for each part.

For TLS, the question is whether the library is OpenSSL 3.5 or later, or one of the stacks the post lists: rustls, Go's crypto/tls, BoringSSL, AWS-LC or s2n-tls. In the cloud, it says to use the provider's ALB or NLB with a maintained ACME client rather than run the termination yourself.

For passwords, the check is the stored parameters. Argon2id at m=64 MiB, t=2, p=1 matches the post, and so does scrypt at N=2^16, r=8, p=1. Anything using SHA-1 or MD5 falls under its avoid list.

For files at rest, the post says to use the cloud provider's KMS. Locally it says to use XAES-256-GCM or XChaCha20Poly1305 with random nonces of at least 128 bits, and to switch to Cobblestone-128 chunked encryption for anything over a few MB.

What it does not claim

The post is a set of defaults, not a measured comparison. It gives no benchmark figures, and this site has not tested any of the libraries it names. Its rating of ML-DSA-44 as category 2 is the author's statement, and the FIPS 203 page this story read covers the key-encapsulation standard, not ML-DSA.

The practical effect is on procurement and configuration. A team on a release older than OpenSSL 3.5 is, by the post's account, outside its advice for the TLS hybrid. Weak credentials remain the more common failure; the site's report on the Danish CPR breach involved a password of 123456, which no key-exchange choice would have fixed. For patching discipline, see CISA's October 8 additions.

The next dated item on the post's own list is 2027, when it expects Merkle Tree Certificates to roll out.