Encrypting data: If you’re in the cloud, KMS.

[Website or client-server application security] For If you’re in the cloud, use its ALB/NLB.

I am not in the cloud, what are these?

ALB/NLB appears to be load balancers, which also do TLS termination for you.

score 1 · canonical

If you already have Keccak (SHA-3) around for ML-KEM and ML-DSA, and you want to use it for hashing, draw 32 bytes from SHAKE128.

@FiloSottile Is this because SHAKE supports arbitrary length?
(As a non cryptographer…) Are the preimage discussions around SHAKE not relevant in the “Hash Function” context?

score 1 · canonical

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.

MLKEM768-X25519 “xwing” is in libsodium! But why is AES-128-GCM ok here but not above?

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.

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

Oh I’m glad I found SequenceHash. I’ve noticed bugs in tuple hashing schemes before but didn’t realize there was a formal solution. I always learn something from this series.

score 1 · canonical

Nice to see someone immediately addressing symmetric cryptography being functionally unimpacted by quantum computing

score 1 · canonical