<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Sun, Feb 14, 2021 at 5:18 AM Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jon Callas <<a href="mailto:jon@callas.org" target="_blank">jon@callas.org</a>> writes:<br>
<br>
>My apologies for being pedantic, but it's Counter Mode that makes GCM a<br>
>stream cipher. GCM is a CTR stream cipher combined with GHash to get you the<br>
>integrity bits to make it an AEAD.<br>
<br>
It's not just a stream cipher, it's RC4 all over again.  And by RC4 I don't<br>
mean the stream cipher with statistical weaknesses, I mean the stream cipher<br>
that almost everyone who used it got wrong over and over and over again, until<br>
automated scanning tools immediately flagged any use of it as a security<br>
vulnerability.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Don't hold back, say what you really think.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The really sad part here is that the whole point of AEAD was supposed to be to make it impossible for people to screw up with bad protocols and bad implementations.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am also a bit down on the idea of using the same key for every packet. Key setup is not that expensive. Rotating the key on each call feels right. Maybe go back to specifying a nonce that is used with the primary key to HKDF derive the key and IV for each packet. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I guess at some point I need to do some benchmarking to look at alternative strategies. But the more I look at things, the more I start to think that maybe we should consider 1GB about the limit of what we should ever want to encrypt as a single chunk. Sure, I have 56TB of disk just installed this week and some of those files are larger than 1GB. But if there is an error, I probably want a bit more information than 'something is wrong in this 1TB of data'. And yes, I am saying that after designing the packaging format so that it supports data blobs of 2^64 bytes in length.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>