The reason I prefer OCB over GCM is that the plaintext is one of the inputs to the block function in OCB while in GCM it does not. GCM converts AES into a stream cipher.
So yes, nonce reuse does leak some information. It means that an attacker presented with two plaintexts encrypted under the same nonce can see if blocks are the same or different. That is potentially a pretty serious security concern. But it isn't the rake stomp you get from GCM. If you reuse the same nonce with GCM I can immediately work out the XOR of the two plaintexts and that is more than enough to recover both plaintexts if the input is text. There is a difference and that difference is one of the reasons I am a bit wary of folk who seem to think formal methods are a magic wand, they are not. Given that NIST is going to have to look for functions that do prevent the type of attack OCB is vulnerable to, it is pretty clear that they have to guarantee the ciphertext depends on every bit of plaintext and they are going to require multiple passes. That means that the only way to achieve efficient encoding and nonce reuse resilience is going to be something like GCM-SIV on individual chunks of plaintext. I would still prefer OCB-SIV,... but there are more interesting windmills to tilt at right now. What this means is that it would be useful to have an envelope format that allowed the Payload to specify the chunking for decryption purposes. Then GCM-SIV can be used on each chunk in turn and whatever accordion functions NIST might provide can fit into the same slot. On Mon, Sep 29, 2025 at 12:35 PM John Mattsson <[email protected]> wrote: > >Certainly hard to see Prof Rogaway being involved > > > > He was invited to the first workshop in 2023 to have a keynote on block > ciphers and surprised everybody by instead talking about radical CS :) > > > https://csrc.nist.gov/csrc/media/Presentations/2023/radical-cs/images-media/sess-1-rogaway-bcm-workshop-2023.pdf > > >if there is an effort to develop new modes. > > > > But note that NIST accordions will very likely be two-pass so that the > last bit in the plaintext can affect the first bit in the ciphertext. There > are limits to what you can do with one pass. > > > > Cheers, > John > > *From: *Phillip Hallam-Baker <[email protected]> > *Date: *Monday, 29 September 2025 at 18:15 > *To: *John Mattsson <[email protected]> > *Cc: *Neil Madden <[email protected]>, [email protected] <[email protected]> > *Subject: *Re: [jose] Re: Add AES-OCB mode? > > On Sun, Sep 28, 2025 at 11:53 PM John Mattsson <[email protected]> > wrote: > > Hi Phillip, > > For robustness I would wait for NIST accordions. > > https://csrc.nist.gov/pubs/sp/800/197/a/iprd > > > > Oohhh, very interesting. Just have to wonder if it is going to continue > given the random nature of US government under this administration. > Certainly hard to see Prof Rogaway being involved given his current > focus and he essentially invented the construct. > > > > On the other hand, if the effort does bring a community of cryptographers > together to work on this topic, it probably won't be too hard for that work > to find a home if there is some peculiar event. > > > > > > 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. > > > > Yeah, undermining is not the same as the rake-stomp effect of reusing the > nonce in GCM. But this is obviously not the time to go further down the OCB > road if there is an effort to develop new modes. > > > > > > > > > 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 :) > > > > Oh I agree there. I think there is almost no situation where 128 is going > to be insufficient when I am not going to go to 256. > > > > I went even further in my designs for the Mesh, I only use AES-256, > SHA-2-512 and SHA-3-512/SHAKE256. If I want a shorter digest, I truncate. > > > > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
