Ron Frederick <[email protected]> writes: > I’m not a cryptographer
And I'm an amateur when it comes to cryptanalysis. > but how would this be different than supporting a copy() function for > something like HMAC, where you generate a digest for both a message > and its prefix? Difference is that HMAC doesn't have a nonce. When the attacker gets the HMAC of two messages (related or not) using the same key, the attacker is supposed to only be able to tell if the messages were identical or not. > I thought the main attack against UMAC when you reused > both a key and a nonce for two different messages was that the key > stream for both messages was identical and it was only later mixed > with data from the messages. I'm afraid I can't give a concrete attack, but my gut feeling is that the security analysis depends on nonces being unique, it's generally a bad idea to depart from that. I don't recall all details of UMAC; it's some years since I wrote it. But the way I understand it, it works by computing a relatively weak low-complexity function of the expanded key and message. IIRC, L1 is a plain linear convolution, and L2 is some kind of polynomial evaluation. And then to hide the low-complexity structure from the attacker, a value derived from the key and nonce is XORed to the tag at the end. Looking at the code, that final "whitening" is the only use of the nonce I see. So basically, umac(key, nonce, msg) = F(key, msg) ^ AES(pdf_key, nonce) where F(key, msg) is a low-complexity function. So if you compute t0 = umac(key, nonce, "foo") t1 = umac(key, nonce, "foobar") then t0 XOR t1 = F(key, "foo") ^ F(key,"foobar") which looks a bit too well structured, and defeats the whitening step. I can't tell if it leads to practical attacks, but I wouldn't be suprised of a few of these would let the attacker derive the parts of the expanded key corresponding to the suffix, and then forge additional messages with identical tag. > Admittedly, PEP 247/452 > doesn’t explicitly contemplate hash functions with nonces, but it > would cover cases where multiple digests were generated using the same > key and no other randomization to make the two digests independent. As I said, multiple messages with the same key is pretty normal use of HMAC, and if one doesn't want the attacker to be able to identify identical messages from the MACs, one can prepend a sequence number to the message. Supposedly unique per-message nonces make the situation quite different. > I agree that a separate function is probably better than a flag. What > do you think of the name partial_digest(), or perhaps > running_digest()? running_digest sounds quite clear to me. Or maybe snapshot_digest? > So, would you basically have two different context objects in this > case, one associated with just the key and a separate one associated > with the nonce and the message data provided so far? It seems like > you’d still need to make a copy of the second object before > calculating a digest if you wanted to support partial digests and > didn’t have a “pure” digest function that could do that without > modifying the state, but at least the amount of data you had to copy > might be smaller. That's the idea. For umac, the second part is quite large too, so it would make some sense with a function that can produce the digest without clobbering (or copying) it. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
