Niels Möller nisse@lysator.liu.se 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:
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).
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,
- 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