Hacker News Reader

Comment by cakoose | Hacker News Reader

The first example shows AES.GCM.seal(...) and then states:

> This code avoids some of the numerous pitfalls that you can encounter when constructing encryption schemes yourself. For example, it ensures that you use a randomly selected nonce, and that you authenticate your ciphertext.

The AES-GCM nonce is only 96 bits, which might be enough in many contexts, but is still a little short for comfort when selecting nonces randomly: https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html

It's surprising that the blog post just declared success without bringing this up at all.

(It looks like AES.GCM.seal does let you specify the nonce, though, in cases where you can maintain a counter yourself.)

View on HN

This gives you a collision after 2^48 messages (via the birthday problem). Each message can be up to 2^36 - 256 bytes long.

This is less of a problem when each message also generates a random key, but still annoying to contend with.

XChaCha20-Poly1305 lets you generate 2^96 messages before having to worry about rekeying. https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...

2^48 is an absurdly large number.

That's enough that you can generate 1000 messages a second for several millenia.

Yeah, 2^48 is huge, but that gets you a collision probability of ~40%.

You'd want a probability more like 1-in-a-million (or 1-in-a-billion). That's 2^39 (or 2^34), which is 1000 messages a second for 17 years (or 7 months).

Again, probably still safe for many use cases. But you do have to think about it for a second. XChaCha20's 192-bit nonce capacity lets you totally ignore that factor, which is a nice property for generic crypto recommendations.

There’re also SIV constructions if you’re the more cautious type, which isn’t a bad type to be in cryptography.

Don’t use SIV unless you know what you are doing. SIV is a deterministic encryption scheme, which invariably leaks information.

A naïve hash of the data you’re encrypting stuffed into the nonce leaks whether two plaintexts are the same (or…collided). A hash of the key and plaintext leaks whether the two plaintexts are the same under the same key. Using a proper keyed MAC prevents any rainbow table style attack in either case.

Generally speaking leaking that two plaintexts are the same is better than leaking two plaintexts XORed together. If you’re in a use case where that’s liable to happen (i.e., you don’t rekey “frequently”) I’d happily take the former leaked bit over the latter leaked messages.

There are also a handful of existing constructions you can just take off the shelf rather than rolling your own thing and getting it wrong.

AES-GCM-SIV takes a nonce; if you reuse a nonce with two identical plaintexts, you reveal that the plaintexts were identical, but not much more.

With AES-GCM, if you reuse a nonce with two different plaintexts, you reveal the XOR of the two plaintexts!

Reply on news.ycombinator.com