Hello,

сб, 20 июл. 2019 г. в 12:00, Daiki Ueno <u...@gnu.org>:
>
> Dmitry Eremin-Solenikov <dbarysh...@gmail.com> writes:
>
> >> Each meta interface shall provide the following 4 functions:
> >>
> >>   nettle_set_key_func *set_key;
> >>   nettle_set_key_func *set_nonce;
> >>   nettle_hash_update_func *update;
> >>   nettle_hash_digest_func *digest;
> >>
> >> where set_nonce is only used by UMAC, and expects that the nonce has
> >> always the same length as AES_BLOCK_SIZE.  For CMAC and HMAC, a no-op
> >> set_nonce function is defined.
> >
> > Will it be usefull to support length + data as arguments of set_nonce 
> > function?
> > Especially if we try to add AES-GMAC a first level citizen.
>
> Maybe I'm missing the context, but wouldn't AES-GMAC better fit in
> `struct nettle_aead` as it is a special case of AES-GCM?

It is, but it is defined as a MAC algorithm.

> The struct also has set_nonce function defined as nettle_set_key_func *.

Hmm, I've missed that point. Then I have no objections.

> > Also it might look good to define (internal) mac_set_nonce_null() function
> > and use it from the HMAC/CMAC meta interface.
>
> Indeed, it makes sense.  I will update the series with it after making
> hmac_*_set_key_expanded internal as suggested.
>
> Thank you for the comments!

Thank you!


-- 
With best wishes
Dmitry
_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to