Nikos Mavrogiannopoulos nmav@gnutls.org writes:
On Thu, Mar 28, 2013 at 2:06 PM, Niels Möller nisse@lysator.liu.se wrote:
I'm a bit worried about testing; the test vectors in RFC4418 seem inadequate to get confidence in an implementation. I include the README file (an extended version of the notes I mailed earlier) below.
Unfortunately yes. Moreover vectors of the UMAC-128 tags are not even mentioned. It may be better to generate any desired vectors using Krovetz' implementation.
I mailed him and asked, and he also suggested using rthe python (or ruby) implementation. Will be some work though.
Well, it seems that hiding information about the data being protected isn't one of the main properties of a MAC algorithm.
Right, maybe we don't need to care about that.
- It's natural to provide the nonce at the time the digest (or "tag") is extracted, since (i) that's when it is needed, and (ii) for other macs, that's the only function which is called precisely once per message. (Current code doesn't do that).
I think a generic interface for macs should be followed. The fact that this algorithm requires the nonce during digest extraction seem pretty UMAC-specific. Having a set_nonce function to be called after init seem reasonable.
It's something like that in the gcm code (but called set_iv). So we should aim for some consistency.
Maybe one could also have a default autoincrementing nonce?
- It's desirable to keep the underlying AES cipher separate from the rest of the UMAC code, and provide it only for key setup.
UMAC is only specified with AES, and RFC4418 when it mentions UMAC it means UMAC-AES.
[...]
Making things so general would actually complicate the interface without any benefit for the time being.
I agree that it's not worth to make the user-level interface, nor the implementation, more complex to achieve separation, but some level of separation may actually make implementation clearer.
- In some ways it would be nice and proper to separate the subkeys, which are constant while messages are being processed, from the per-message state (applies also to the HMAC code). One potential use would be to have a single key and several threads using it to process messages.
Does this property exist in any other nettle algorithms?
It's (trivially) true for the block ciphers, and the gcm code separates key state (struct gcm_key) from message state (struct gcm_ctx). The hmac code does not, and I'd like to change that *if* I can find some reasonable way to do it.
Regards, /Niels