back
2 comments
In the next 10 years or so the use of AEAD modes like AES-GCM and ChaCha20-Poly1305 will come back to bite people. As per usual, the culprit will be really smart people convinced they can get away with compromises made for the benefit of speed and message size overhead, and who feel absolved from responsibility when application developers don't read the fine print.

This vicious cycle won't stop until we simply use a minimum of 256-bit block sizes at all stages. IOW, until it's literally impossible to reuse or overrun nonce and IV space without being willful about it. Anything beyond "initialize X to 0 and initialize Y to 128 bits of random data" will come back to bite people, and the only way to make things that simple is to increase block sizes.

Another way to look at it is that every aspect of the system should provide a minimum of 128 bits of security, irrespective of context--message size, number of messages, birthday attack, etc. Anything less is not future proof, and the future always comes much faster than you think. Again, the only way to get that is 256-bit or 512-bit block sizes.

Alas, even AES-256 still has 128-bit output blocks, which makes AES-256-GCM less than fail-safe when you need to worry about multi-gigabyte streams. Yes, technically doable; trivial, even. But if you have to think about it--if the scheme's characteristics change between a single, 1-byte message and billions of multi-gigabyte messages--you've already lost. On the network and in the cloud systems that are contingent on magnitude are dangerous. I think the future will be in approaches like STROBE. SHA-3 will seem less like it's over engineered and more like it's the final solution.

The relevant diff from the patch can be found here[1].

[1] https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd4225...