6 ms·
> To me, the takeaway is that assumptions made for certain algorithms may lose their validity within ten years. If we hit 2^64 bytes transferred in under one h
by CiPHPerCoder 10y ago
> To me, the takeaway is that assumptions made for certain algorithms may lose their validity within ten years.
If we hit 2^64 bytes transferred in under one hour as a norm before 2030, I'll be immensely surprised. (This would implicate 128-bit block ciphers for birthday collisions.)
- emilburzo 10y ago> 2^64 bytes 18446.74 PB
- tptacek 10y agoGCM has trouble after just 72PB, because of the way the initial block is divided between counter and IV.
- sdevlin 10y agoWhere are you getting that number?
- tptacek 10y agoThe Noise framework documentation. I know there's "a" number for GCM, but I always forget what it is, so I keep going back to Noise.
- deleted 10y ago[deleted]
- sdevlin 10y agoI don't think their bound is related to nonce-management issues. From the documentation: > The GCM security limit is 2^56 bytes because: > This is 2^52 AES blocks (each block is 16 bytes). The limit is based on the risk of birthday collisions being used to rule out plaintext guesses. The probability an attacker could rule out a random guess on a 2^56 byte plaintext is less than 1 in 1 million (roughly (2^52 * 2^52) / 2^128).
- tptacek 10y agoYep. I'm wrong. I'll stop sourcing that number from Noise. :) (Clarified offline: I'm thinking of the 32 bit counter in GCM, which will wrap in tens of gigabytes worth of bytes under a single nonce. Not a TLS issue, a concern for custom protocols.)
- mercora 10y agoeven if we would. that could easily be defeated by regular rekeying like done in ipsec or not?
- CiPHPerCoder 10y agoMy hope is that, by then, we'd be using 256-bit blocks so we don't need to worry about it.