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. > * Since I have been working with side-channel silence recently, it > seems natural to try to make the POLY function silent. On the other > hand, I'm not sure what the threats are. If the MAC is applied to a > secret message, we may leak some information about the message, I > guess? Is it a problem worth bothering about? Well, it seems that hiding information about the data being protected isn't one of the main properties of a MAC algorithm. MAC algorithms struggle to protect against key recovery, insertion attacks and modification attacks. Your remark about the possibility of extracting information about the plaintext is indeed interesting and one more argument for applying the MAC after encryption. > * 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 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. I'd keep the UMAC-AES/UMAC a single algorithm and not separate the AES part. The fact that other ciphers could be used isn't very interesting since these options are neither standardized nor studied. Once such an other option is available sometime in the future it can be another algorithm e.g. umac-des. > * I'm leaning towards having separate types and functions for > UMAC-AES-32, UMAC-AES-64, UMAC-AES-96 and UMAC-AES-128, which would > all use common primitives for layer 1, 2 and 3 hashing. The > primitives should be independent of AES. It would then be easy to > define UMAC with other ciphers and KDFs if ever needed (and as far > as I understand, a *block* cipher shouldn't be strictly necessary, > since it's essentially used in CTR mode anyway, e.g., UMAC-SALSA20 > should be possible). Making things so general would actually complicate the interface without any benefit for the time being. Yes it would be future-proof, but there is no guarantee that another variant of UMAC will be defined in the future - it may be VMAC - nor something like that is planned. > * 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? If not I'd say don't bother. My impression with the contexts in nettle is that a single context is used in a single thread. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
