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