Hello,
nisse@lysator.liu.se (Niels Möller) writes:
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
There will be a nonce for GMAC.
Ok. If we keep set_nonce, we have to clarify what it means. There are a couple of cases, where the first two are relatively easy.
nonce_size == 0, set_nonce == NULL: Never call set_nonce. This is the HMAC case.
nonce_size == 0, set_nonce != NULL: This could mean that nonce is optional. Does that make any sense?
nonce_size > 0, set_nonce != NULL: Would then be used for UMAC and GMAC.
For the last case, I have a couple of questions.
Comment says "suggested nonce_size", but I take it only that one size is possible, since set_nonce is nettle_set_key_func, with no length argument. Or do you intend to allow other sizes?
I think I'd prefer fix size, to keep things simple. And treat variants with different nonce size as separate mac algorithms, for this abstraction. Just like with the key size.
I think fixed size would be sufficient (the code was merely copied from the nettle_aead definition).
What should be the behavior for usage like
->set_key ->set_nonce ->update ->digest ->update ->digest
with second set_nonce missing?
Should it just keep the nonce from the first digest? (Sounds a bit dangerous). Or autoincrement? (That's what umac does, because it's defined in a way to make that more efficient). Or be specified as invalid, triggering asserts whenever it is easy to detect?
I think it has to be specified; it will be too confusing if UMAC behaves in one way and GMAC behaves differently.
Provided that the two types of MACs (nonces are required or not) are supposedly not intermixed, another option might be to provide a separate struct (say, nettle_nmac) for MACs that require nonces (UMAC and GMAC, not sure if there will be more to come), and mandate set_nonce != NULL:
- nettle_mac (from the testutils.h definition) for HMAC, CMAC - nettle_nmac (nettle_nmac + set_nonce) for UMAC, GMAC
That would be analogous to the distinction between nettle_cipher and nettle_aead and serve the documentation.
Regards,