[jose] Re: Add AES-OCB mode?

[John Mattsson <[e-mail]>]

Hi Phillip,

For robustness I would wait for NIST accordions.
https://csrc.nist.gov/pubs/sp/800/197/a/iprd

RFC 7253 already have very good text on the nonce reuse properties:

   It is crucial that, as one encrypts, one does not repeat a nonce.
   The inadvertent reuse of the same nonce by two invocations of the OCB
   encryption operation, with the same key, but with distinct plaintext
   values, undermines the confidentiality of the plaintexts protected in
   those two invocations and undermines all of the authenticity and
   integrity protection provided by that key.  For this reason, OCB
   should only be used whenever nonce uniqueness can be provided with
   certainty.

Start with reading RFC 7253 and decide if you want to proceed. Unclear how you wanted to do the registrations. The JSON Web Signature and Encryption Algorithms is Specification Required.

> A128OCB,  A192OCB, and A256OCB
I don’t think I have ever seen anyone use AES-192, and can we just call it them AES-128-OCB and AES-256-OCB. A person from NIST recently asked me why I used so weird terminology, and I had to explain its JOSE’s fault :)

Cheers,
John

From: Neil Madden <[e-mail]>
Date: Sunday, 28 September 2025 at 21:58
To: Phillip Hallam-Baker <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [jose] Re: Add AES-OCB mode?



On 28 Sep 2025, at 20:33, Phillip Hallam-Baker <[e-mail]> wrote:

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.

This is essentially what Rogaway’s STREAM does - split the message into chunks (letting the app choose what a natural chunk boundary is), then you partition the nonce so that there is a per-message unique part and then a chunk counter and a single “last chunk” bit. These prevent chunk reordering and truncation attacks.

https://eprint.iacr.org/2015/189.pdf

However, obviously this reduces the effective size of the nonce, so you’d combine it with some nonce-extension scheme using a KDF, as you say.

See https://developers.google.com/tink/encrypt-large-files-or-data-streams for one implementation that does exactly this, and this is also what Age does.

— Neil


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 <[e-mail]<mailto:[e-mail]>> wrote:



On 28 Sep 2025, at 19:07, Phillip Hallam-Baker <[e-mail]<mailto:[e-mail]>> 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