Nikos Mavrogiannopoulos <[email protected]> writes: > On Thu, Mar 28, 2013 at 2:06 PM, Niels Möller <[email protected]> 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 -- 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
