Subject: [Cfrg] UMAC draft changes

From: David McGrew <[email-masked]>
Date: Mon, 12 Sep 2005 15:14:19 -0700

Hi Ted,

several points have been raised about the UMAC draft that ought to be 
addressed.  I would like to see the draft be published as an RFC, but I 
think that these points should be cleared up first.

Here are the items that I think are important (comments welcome):

1.  Information about the key may be leaked via timing attacks.  The 
standard fix of implementing a fixed-time comparison will work, and in 
my opinion should be a MUST for UMAC implementations.

2. The security claims don't take into consideration the number of 
times that AES is evaluated.

3. The security claims seem to imply that repeat forgeries are not an 
issue, saying that ``a 1 / 2^60 forging probability means that if an 
attacker could try out 2^60 MACs, then the attacker would probably get 
one right.''  Isn't it the case with UMAC that an attacker who can 
perpetrate a successful forgery would be able to use information from 
that success to forge more messages?   This issue is especially 
important because of the presence of short tags in the spec.

Also, Dan Bernstein points out that the POLY64 hash might leak timing 
information.  It would be good to get some quantification of this, if 
possible.

Do you think that it would be possible for you and the other UMAC 
authors to address these points?  I know that there are several people 
interested in UMAC that are probably willing to help, at least on item 
1.

Thanks, and best regards,

David

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Shai Halevi" <[email-masked]>
Date: Mon, 19 Sep 2005 22:26:29 -0400

Daniel, bad-mouthing is a rather poor utilization of this bandwidth
(and the time of the people reading this list). It is definitely your right
to peddle your own scheme and claim that it is better than UMAC on
this point or the other, but name-calling and FUD is not a very
appropriate (or effective) way of doing that.

> [...]
>    * They talk about how long it would take for a single sender to
>      transmit 2^64 messages. So what? Transmitting 2^34 messages is a
>      billion times faster than that.

If you would bother reading the note before replying, you would discover
that that illustration was there to demonstrate that 2^{64} is a safe bound
for any realistic system. You seem to agree with that  point.

>    * They claim that the A^2/2^129 term ``is widely believed to be of no
>      practical consequences in any realistic setting.'' Even if this is
>      true, so what? The question is about what ``has been rigorously
>      proven,'' not about what people might believe.

Maybe for you it is, but for people using MAC the question is how safe it is
to use, not what DBJ was able to prove about it.

> The UMAC security claim is clearly, obviously, indisputably false.

Actually, the technical claim in the paper is correct, and I believe that
the English
interpretation in the RFC is a reasonable one. You may think otherwise
(which
you made blatantly clear), but the readers of this group are intelligent
enough to
make their own mind regarding that.

Regards,

--Shai