Hello Niels :) sorry for not following up earlier. Thanks for working on it!
[email protected] (Niels Möller) writes: > [email protected] (Niels Möller) writes: > >> If someone wants to work on it, please post to the list. I might look >> into it myself, but as you have noticed, I have rather limited hacking >> time. > > 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. > Some comments and questions: > > 1. Most of the operations use only the enrypt function of the underlying > block cipher. Except ocb decrypt, which needs *both* the decrypt > function and the encrypt function. For ciphers that use different key > setup for encrypt and decrypt, e.g., AES, that means that to decrypt > OCB one needs to initialize two separate aes128_ctx. To call the > somewhat unwieldy > > void > ocb_decrypt (struct ocb_ctx *ctx, const struct ocb_key *key, > const void *encrypt_ctx, nettle_cipher_func *encrypt, > const void *decrypt_ctx, nettle_cipher_func *decrypt, > size_t length, uint8_t *dst, const uint8_t *src); I don't mind it being unwieldy. > 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. > 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: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/86 > 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. https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/84 https://github.com/ProtonMail/go-crypto/blob/70ae35bab23f26f6188bab82cb34d7f7adf2b200/ocb/ocb.go#L157 https://botan.randombit.net/doxygen/ocb_8cpp_source.html#l00264 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. Thanks, Justus
signature.asc
Description: PGP signature
_______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
