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 <[email protected]> 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 <[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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
