Justus Winter <jus...@sequoia-pgp.org> writes: >> I've given it a try, see branch ocb-mode. Based on RFC 7253. Passes >> tests, but not particularly optimized. > > I have wrapped it in our Rust bindings, glued Sequoia to it, and did > some interop testing. Looks all good.
Based on the functions declared in ocb.h, or the struct nettle_ocb_aesxxx? I'm thinking that it might make sense to add the latter as part of the public api for next release, but leave all other functions as internal to let dust settle a bit? >> 2. It's not obvious how to best manage the different L_i values. Can be >> computed upfront, on demand, or cached in some way. Current code >> computes only L_*, L_$ and L_0 up front (part of ocb_set_key), and >> the others recomputed each time they're needed. > > I cannot comment on that. Changing it later we be a bit difficult (ABI break, if more space is needed in the context struct), so we need to decide on something reasonable. >> 3. The processing of the authenticated data doesn't depend on the nonce >> in any way. That means that if one processes several messages with >> the same key and associated data, the associated data can be >> processed once, with the same sum reused for all messages. >> >> Is that something that is useful in practice, and which nettle >> interfaces should support? > > That is an interesting question. Currently, the OpenPGP drafts that > include AEAD do include the chunk index in the authenticated data and > would therefore not benefit from this optimization. However, I've > raised this point in our issue tracker: This choice can affect both API and ABI. >> 4. The way the nonce is used seems designed to allow cheap incrementing >> of the nonce. The nonce is used to determine >> >> Offset_0 = Stretch[1+bottom..128+bottom] >> >> where "bottom" is the least significant 6 bits of the nonce, acting as >> a shift, and "Stretch" is independent of those nonce bits, so >> unchanged on all but one out of 64 nonce increments. >> >> Should nettle support some kind of auto-incrementing nonce that takes >> advantage of this? Nettle does something similar for UMAC (not sure >> if there are others). > > That is also interesting. I have raised the point in our issue tracker, > and Daniel Huigens observed that at least their Go implementation simply > compares the top-most bits with the ones provided for the previous > chunk. Botan does the same. For any kind of optimization of this, one needs to store previous nonce and relatede values in the context. To generalize it to more than auto-increment, one get the problem that for the first set_nonce, there is no previous nonce to compare to. So one would need an extra flag just for that, which I don't think is so nice. Alternatively, use a zero nonce by default at initialization. Then there's another slight complication: To set the nonce, one needs to know the "tag_length". In the current version, that is passed as an argument to set_nonce. It could perhaps be passed with set_key instead, it's now some time since I read the RFC, but I don't think it is proper use to use OCB with the same key, but change tag_length from message to message. > This has the benefit of working for how OpenPGP currently constructs the > nonce, which does not result in monotonically incrementing nonces > (currently, we take an IV and xor in the chunk index). But, we may > change the scheme. I think it would be nice to stick to a simply incrementing nonce value. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
