[Cryptography] AES GCM insecure vs OCB1/OCB3 ??

[Phillip Hallam-Baker]

On Sun, Feb 14, 2021 at 5:18 AM Peter Gutmann <pgut001 at cs.auckland.ac.nz>
wrote:

> Jon Callas <jon at callas.org> writes:
>
> >My apologies for being pedantic, but it's Counter Mode that makes GCM a
> >stream cipher. GCM is a CTR stream cipher combined with GHash to get you
> the
> >integrity bits to make it an AEAD.
>
> It's not just a stream cipher, it's RC4 all over again.  And by RC4 I don't
> mean the stream cipher with statistical weaknesses, I mean the stream
> cipher
> that almost everyone who used it got wrong over and over and over again,
> until
> automated scanning tools immediately flagged any use of it as a security
> vulnerability.
>

Don't hold back, say what you really think.

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.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210214/d8549351/attachment.htm>