[jose] Re: Add AES-OCB mode?

[Richard Barnes <[e-mail]>]

Phil: The registry is Specification Required.  You can just send email to
IANA, there's no need to get the WG to approve it.

https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

On Tue, Sep 30, 2025 at 6:17 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> 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 <[e-mail]>
> 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 <[e-mail]>
>> *Date: *Monday, 29 September 2025 at 18:15
>> *To: *John Mattsson <[e-mail]>
>> *Cc: *Neil Madden <[e-mail]>, [e-mail] <[e-mail]
>> >
>> *Subject: *Re: [jose] Re: Add AES-OCB mode?
>>
>> On Sun, Sep 28, 2025 at 11:53 PM John Mattsson <
>> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>