When I first read Rogaway's comments, he described it as tolerating nonce reuse, he doesn't any more. It isn't the direct rake stomp you get from GCM nonce reuse but maybe not good enough to justify a shift at this stage.
He does bring up the issue of being maximally “resilient” to nonce-reuse in the SIV paper. But as he points out there as well, there is a massive performance penalty. Perhaps the way to go is simply breaking up large streams into chunks and GCM-SIV encrypting each chunk. Now for some reason I have never quite understood, folk seem to be very keen on reusing symmetric keys when I think you might as well make the problem maximally hard by doing a KDF to generate a new key as well as an IV each time. Yes, there was a time when the overhead of key setup mattered but that is a long time ago and I don't think any of the apparatus we use today would really benefit much. On Sun, Sep 28, 2025 at 2:53 PM Neil Madden <[email protected]> wrote: > > > On 28 Sep 2025, at 19:07, Phillip Hallam-Baker <[email protected]> > wrote: > > > I am busy writing the drafts for proposing the JSContact exchange scheme > to this group. > > One of the concerns that comes up is that AES-GCM remains a technique that > turns a nice robust block cipher into a stream cipher and that makes it > rather fragile when considering all the possible ways the botched and the > bungles could mis-implement things. > > > I’m not sure OCB is significantly better in this regard. > > > Yes, I know formal methods are all the rage, been there, done that, might > even collect the bit of paper with the ribbon some day. The problem with > formal methods is that they only reveal the security of the system you > analyze and only with respect to the concerns your tools are able to > address. And the problem I have as a protocol designer is that you can end > up with a scheme that is formally verifiable but brittle in operation. Case > in point here being VENONA which led to the execution of the Rosenbergs > despite one time pads being a provably perfect cipher. > > GCM-SIV is one possible option but it requires two pass processing which > is OK for encrypting IP packets but severely limits application of the > result. The DARE Envelope construct I am using as a basis was originally > designed to support exchange of encrypted ZIP-like archives containing TBs > of files. Single pass processing really is a must. > > > You should really be using something like Rogaway’s STREAM to encrypt > large files, regardless of underlying mode. And in that case the drawbacks > of SIV are lessened. (But personally I’d choose something based on the > original SIV, as AES-GCM-SIV has various drawbacks). > > See my earlier draft (which fell between the IETF cracks when the JOSE WG > was disbanded): > https://datatracker.ietf.org/doc/html/draft-madden-jose-siv-mode-02 > > > AES-OCB is much better, it is robust even with IV reuse > > > No it is not - as per > https://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce > > “ What happens if you repeat the nonce? You’re going to mess up > authenticity for all future messages, and you’re going to mess up privacy > for the messages that use the repeated nonce. So don’t do this. It is the > user’s obligation to ensure that nonces don’t repeat within a session. In > settings where this is infeasible, OCB should not be used.” > > That is the same as GCM. > > and we would likely have used it in place of GCM if there hadn't been > three sets of conflicting patent claims. I know one version has issues but > the scheme described in RFC7253 is generally believed to be sound. Phil > Rogaway invented much of the apparatus used for formal analysis of > symmetric algorithms. > > What I propose is adding A128OCB, A192OCB, and A256OCB to the registry > of algorithms following the same approach as AES-GCM. They are just a drop > in replacement. > > > I’m not against adding OCB, but IMO it provides little practical benefit > over GCM, especially for the typical use-cases of JOSE. > > I think one of the AEGIS variants is more interesting - > https://www.ietf.org/archive/id/draft-irtf-cfrg-aegis-aead-17.html > > Best, > > — Neil >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
