Nikos Mavrogiannopoulos <[email protected]> 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
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
