Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes:

> The current HMAC API assumes that the hashing state is kept per call.

I don't think so, but maybe I misunderstand you (or maybe you have found
a bug?).

> That is if I have to hash a series of packets with contents X_0, X_1,
> ..., X_n I do:
> hmac_set_key(s);
> for (i=1;i<n;i++) {
>   hmac_update(s, X_i)
>   hmac_digest(s, output)
> }

That loop should compute HMAC(key, X_0), HMAC(key, X_1), and so on, with
X_0 affecting only the first digest.

> for (i=1;i<n;i++) {
>   hmac_set_key(s);
>   hmac_update(s, X_i)
>   hmac_digest(s, output)
> }

And so should this (assuming you pass the same key to set_key every
time).

Both hmac_set_key and hmac_digest end with identical calls

  memcpy(state, inner, hash->context_size);

to set the state properly for hashing a new message.

> hmac_set_key(struct hmac_key*)
> hmac_init(struct hmac_ctx*, struct hmac_key*)
> hmac_update(struct hmac_ctx*)
> hmac_digest(struct hmac_ctx*, output)

Something like that would make sense.

> It would be nice if umac could be used under such an abstraction (or
> if the umac_set_nonce would imply the reset).

umac_digest should imply a reset (and an increment of the nonce, if you don't
call set_nonce explicitly).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
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

Reply via email to