Subject: RE: [Cfrg] Re: universal MACs

From: "Erik Zenner" <[email-masked]>
Date: Wed, 19 Jan 2005 15:34:21 +0100

Dear all,

> thanks for posting the links to the new info.  It is 
> interesting work.  
> I encourage you to consider writing up an internet draft on this MAC 
> and then moving it to an informational RFC if there is interest; my 
> guess is that there will be plenty of interest.

we have recently proposed another Wegman-Carter based MAC design, named
"Badger". Information is available from the IACR eprint server at
http://eprint.iacr.org/2004/319. As with UMAC and Poly1305, the
performance is very good, with very fast tagging available for short
messages (as relevant for e.g. TLS or IPSec). 

Any comments are welcome!

Erik Zenner

--
Dr. Erik Zenner    Phone:  +45 39 17 96 06    Cryptico A/S
Cryptographer      Mobile: +45 60 77 95 41    Fruebjergvej 3
[email-masked]    www.cryptico.com           DK 2100 Copenhagen

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

---

From: Ted Krovetz <[email-masked]>
Date: Thu, 20 Jan 2005 10:06:06 -0800

>> An implementation could easily mask such timing differentials
>
> But your public implementation doesn't.

It really doesn't need to. If you look carefully, POLY is only executed 
on messages longer than 1K, and the difference between a long POLY 
invocation and a short one is just a dozen or so instructions, 
something that will be lost in the noise over the network delay and 
thousands of instructions needed to hash the 1K of message.

But, if it is a serious concern, we could add some conditional 
compilation to mask it. The difference in performance would not be 
significant.

> You summarize this as ``If an attacker could try out 2^60 MACs, then 
> the
> attacker would probably get one right.'' I don't think that's an honest
> summary. The 2^60 isn't what you've actually proven, and ``one'' is a
> wild underestimate of the number of successful forgeries.

Your point here is well taken. We will amend our statement to reflect 
that a birthday bound is applicable if one is using a permutation 
rather than a function.

> reconsider your assertion that UMAC-64 is ``safe.''
>
> You say that moving to a much more reasonable security level costs only
> 0.5 cycles per byte. Why haven't you done it?

Because UMAC-32, UMAC-64 and UMAC-96 are all safe in various contexts, 
and we wish to provide high-speed tools for various scenarios.

Rather than get into some sort of flame war with you over UMAC, I will 
sign off now, and let you have the last word if you wish.

Cheers,
Ted Krovetz
Computer Science Department
California State University, Sacramento