Re: [Cfrg] New UMAC Draft

> I'm going away for a few days. In my absence, please run the
> following algorithm
>
>

Funny thing... It turns out they have the Internet in the cafes of  
San Francisco!

> Please define ``secure'' and then show us the proof of this claimed
> forgery-probability bound.
>
>

Dan, I suggest to you that we have strayed far from the point of this  
discussion. On September 9, Russ Housley asked if there were any  
``cryptographic concerns'' with UMAC. You have stated your concerns  
and we have responded both online and with a revised Internet-Draft.  
Your concerns at this point no longer seem to me to be cryptographic  
in nature, but instead seem to be about history and process (ie, what  
bounds were claimed in the past and should RFCs be accompanied by  
formal proofs).

Clearly you believe that an \e-SU hash family wed with AES makes a  
good MAC (witness Poly1305-AES). So, your demands for "show me the  
proof, show me the proof", peppered with "your bounds were  
inaccurate, your bounds were inaccurate" ring as hollow haranguing to  
me. If you have any cryptographic concerns with our claim that UHASH  
is \e-SU or that it is wed appropriately with AES, please detail the  
worry (in any security model of your choosing).

I contend that a proof that UHASH is \e-SU along with the proofs of  
Wegman, Carter and Bernstein should be enough for any cryptographer  
worth his salt to be satisfied enough to accept UMAC passing into an  
RFC.

If you don't think people should use UMAC or if you can find a  
weakness in any security model of your choosing, you are welcome to  
publish your findings in whatever forum you choose. But, please, in  
the meantime, keep your comments focussed on cryptographic concerns  
affecting UMAC's passing into an RFC.

Ciao from North Beach,
Ted Krovetz

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