[Cfrg] Re: universal MACs

[Ted Krovetz <tdk at csus.edu>]

> > 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


_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg