4 ms·

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

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/aead https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...

TylerE 7y ago
2^48 is an absurdly large number. That's enough that you can generate 1000 messages a second for several millenia.
- cakoose 7y ago
  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.
karanlyons 7y ago
There’re also SIV constructions if you’re the more cautious type, which isn’t a bad type to be in cryptography.
- netheril96 7y ago
  Don’t use SIV unless you know what you are doing. SIV is a deterministic encryption scheme, which invariably leaks information.
  - karanlyons 7y ago
    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.
  - cakoose 7y ago
    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!

TylerE 7y ago

2^48 is an absurdly large number. That's enough that you can generate 1000 messages a second for several millenia.

cakoose 7y ago
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.

karanlyons 7y ago

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

netheril96 7y ago
Don’t use SIV unless you know what you are doing. SIV is a deterministic encryption scheme, which invariably leaks information.
- karanlyons 7y ago
  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.
- cakoose 7y ago
  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!