In the tradition started by Colin Percival and Thomas Ptacek, a set of “Cryptographic Right Answers” updated for the accelerated post-quantum transition timeline.
Encrypting data: If you’re in the cloud, KMS. Otherwise, XAES-256-GCM or XChaCha20Poly1305 with random nonces. If you’re encrypting more than a few MB, use Cobblestone-128.
It’s a testament to @FiloSottile’s influence he invented XAES-256-GCM and within two years every major vendor supported it.
NaCl/libsodium’s secretbox is just a paper-thin wrapper around a less common AE construction (XSalsa20+Poly1305), so instead I recommend XAES-256-GCM or XChaCha20Poly1305. The former is an efficient composition of a standard KDF and AES-GCM, packaged as an extended-nonce AEAD, so even if your library doesn’t provide it under that name you can assemble it from the KDF and AES-GCM APIs.
I’d be surprised if XAES-256-GCM was a more common AE construction than either X(Salsa20|ChaCha)20Poly1305 especially given the their use in TLS, NaCl/libsodium, WireGuard, SSH, etc.
Also, I thought the idea was that I shouldn’t be assembling constructions by hand?
Very important is how you handle large messages […] you should use STREAM […] There are a lot of options—too many, in fact—and shamefully none are the consensus answer. Tink has one, libsodium has one, the AWS Encryption SDK has one, FLOE is one, age has one, and the list goes on. […]
In absence of a common off-the-shelf answer, are the off-the-shelf answers from Tink, libsodium, et al wrong? That is, should I implement Cobblestone-128 if it’s not available?
Key exchange: X25519+ML-KEM-768
Asymmetric encryption: HPKE with (MLKEM768-X25519 a.k.a. X-Wing, HKDF-SHA256, AES-128-GCM), or age with PQ keys.
For key exchange, using an ECC hybrid is cheap enough to be worth it, and indeed ML-KEM is usually deployed alongside ECDH. However, if picking or implementing the hybrid is going to make you stay even a single month longer on a classical, non-PQ key exchange, go straight to pure ML-KEM-768 now.
It’s a testament to @FiloSottile’s influence he invented XAES-256-GCM and within two years every major vendor supported it.
I’d be surprised if XAES-256-GCM was a more common AE construction than either X(Salsa20|ChaCha)20Poly1305 especially given the their use in TLS, NaCl/libsodium, WireGuard, SSH, etc.
Also, I thought the idea was that I shouldn’t be assembling constructions by hand?
In absence of a common off-the-shelf answer, are the off-the-shelf answers from Tink, libsodium, et al wrong? That is, should I implement Cobblestone-128 if it’s not available?
MLKEM768-X25519 “xwing” is in libsodium! But why is AES-128-GCM ok here but not above?
In case you’re like me and wondering what “worth it” means here and why we should move to pure PQ post-haste for signatures but not for key exchange or encryption: https://mailarchive.ietf.org/arch/msg/tls/CI9HgxA2UKBIyNj0xNSumH3Qogg/
score 1 · canonical