Dmitry Eremin-Solenikov <dbarysh...@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. 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. 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
