Niels Möller <[email protected]> writes: > The alternative I see is to have the _set_nonce function store the > intended digest size in the context, and use that at _digest time. That > makes the digest functions a bit more consistent with the rest of > nettle, and it also makes it harder to use inconsistent digest size to > the two calls. One drawback is that the size becomes less obvious from > the _digest call site.
I'm moving forward with this change; CCM already merged to master, OCB changes currently on master-updates for CI testing. > Some questions related to this: > > 1. For both functions, I would like to minimize the risk of large memory > overwrites in the case of bugs, say the tag_length member has been > clobbered by bugs elsewhere. Currently, I have an > > assert (ctx->tag_length <= 16); I'm sticking to this assert, with no additional defensive coding. And I'm also document that 16 bytes is always sufficient (if there are usecases where you want to call the _digest function, without allocation depending on which size was passed to _set_nonce). > 3. For OCB, size of both plaintext and the auxilliary authenticated data > is "unlimited", according to RFC 7253. Currently, Nettle uses a > size_t to count number of blocks for each input, which will wrap > around and produce out-of-spec output when size exceeds 2^36 bytes > (with 32-bit size_t) or 2^68 bytes (with 64-bit size_t). > > It would make some sense to replace size_t with uint64_t, to get the > same limit regardless of platform. > > If we go to 64-bit counts, I also wonder if it makes sense to steal 4 > of the high bits to store the tag_length (otherwise, due to padding, > an extra struct field for the tag_length increases the ocb_ctx from > 80 bytes to 96 (on a 64-bit platform). With my current changes, I use uint32_t for the associated data counter, and uint64_t for the message counter. Then I can put in the the new tag_length member in the context struct without excessive padding. It is a bit like stealing top 32 bits of a 64-bit associated data counter, but more straight forward. Do you see any reason why a 32-bit counter for associated data would not be sufficient? I'm not aware of any AEAD usescases that passes several GB of associated data, > 4. The reason I was looking into this now, is that I'm thinking about > adding support for blake2 (RFC 7693), which also similarly has > variable digest size, and that size encoded into a parameter word at > init time. I think these ocb/ccm changes is the last things I want to get in before nettle-4.0. Support for blake2 (and other ongoing projects) have to wait until a later release. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
