Hello, [email protected] (Niels Möller) writes:
> Dmitry Eremin-Solenikov <[email protected]> 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. > > 1. 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). > 2. 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, -- Daiki Ueno _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
