Subject: [Cfrg] Please stop the UMAC posts!

From: Ted Krovetz <[email-masked]>
Date: Tue, 4 Oct 2005 14:38:30 -0700

Fellow sufferers,

By now, and perhaps for quite some time, we have all had enough of  
these endless UMAC posts. They seem to be characterized by Bernstein  
flinging mud (or something rather smellier) at UMAC and its authors,  
and us feeling obliged to respond because UMAC is in IESG review.

Today is the date of the original 4-week timeout that the RFC editor  
placed on the IESG for UMAC comments. In that spirit I ask, please,  
Russ Housley, or whoever else has the authority to end this madness,  
please close the comment period so that we can all get on with our  
lives. (Hugo humorously has called Bernstein's posts a denial-of- 
service attack on all of us.)

An internet draft is not a place to state formal theorems; it is a  
document to specify a technology. In the case of security mechanisms,  
it is desirable (and seldom done) to provide some information about  
the results backing up the proposed mechanisms. UMAC has done this,  
providing much more information and accuracy than most I-Ds (and  
RFCs) do. It has never been our intention to provide mathematical  
statements in this document. Those are provided in scientific papers  
and referred to in the I-D. We have lately added clarifications on  
the insignificance of the birthday bounds, since this was not  
included in the UMAC publications, which only talked about PRFs.  
Shortly we will put a note on the UMAC web page to document a sample  
sequence of claims that can be used to conclude the stated UMAC  
bounds starting from a PRP (instead of starting with a PRF, as in our  
original work).

At this point it needs to be stated clearly and unequivocally that  
our explanations and descriptions of UMAC in the I-D have always been  
honest, fair, and accurate. None of the "errors" pointed out by  
Bernstein have been problematic issues; the complaints seem mostly to  
be aimed to discredit the scheme and its authors. We have been  
incredibly patient in responding to these calumnious allegations.  
Where a worthy complaint was made concerning the missing prf-to-prp  
argument, we verified that it was not an issue, added a comment in  
the I-D, and, as we said, we'll drop a note to the UMAC web page to  
document the (easy) sequence of steps one needs to conclude the given  
bounds. The rest has just been tiresome personal attacks, plaguing  
this list with a lot of unpleasantness.

Our patience has limits and we cannot keep answering to every  
fabricated piece of "evidence" by Bernstein against UMAC and its  
authors. So as long as there are no further *substantial* comments,  
we will ignore further postings by this person.

We request IESG consideration for RFC publication of the current UMAC  
draft.

Thank you,
Ted Krovetz

PS -- As for Bernstein's latest attempt to make mud stick? Krovetz's  
thesis does have a stated bound of 3*2^(-32) + 2^(-33). This is true.  
But, perhaps Bernstein does not understand how bounds work? They can  
be correct and loose at the same time. The bound is correct, but not  
as tight as could be. It collects terms to be more readable and has  
2^-32 too much because the thesis version referred to signed  
multiplication in the first-layer hash. A tighter bound is 2^-31 +  
2^-34 + 2^49, which works fine without exceeding the 2^-30n bound  
stated in the I-D.

I pointed this out to him on this list Sep 28, so it looks like  
Bernstein is so desperate he is even flinging the same discredited  
mud twice!

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

---

From: Hal Finney <[email-masked]>
Date: Tue, 4 Oct 2005 17:00:31 -0700

I can offer one data point with regard to some of the questions of
motivation and personal animosity which have been aired here. Recently
I was looking for a fast AXU2 hash function for use with some timing
tests of Naor-Reingold based disk encryption, and had done some
experiments with Dan Bernstein's Poly1305 hash. I spoke with him at
Crypto about it, and he recommended that I look at the hash from UMAC,
that it might be better suited to my purposes. I did try that out,
with help from Ted Krovetz, and got good results.

Dan did not express any hostility, animosity, or any negative opinions
about the UMAC hash. Nor, if you read his messages carefully, has he
done so here. If he had some kind of vendetta against UMAC, perhaps as
a rival to his hash function, he wouldn't be pointing people towards
it.

It is clear to me that Dan's objections to UMAC and its presentation
are not personal, but philosophical and professional. He strongly
advocates the use of careful mathematical proofs and correspondingly
accurate statements about what is proven. No one who has read Dan's
publications can fail to be impressed by the accuracy and care which
go into his claims.

Hal Finney

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Oct 2005 00:17:39 -0000

Ted Krovetz writes:
> honest, fair, and accurate.

Such as the introductory claim that UMAC ``has been rigorously proven to
be secure''? And the claim in the next paragraph that ``When UMAC
produces 32-, 64-, 96- or 128-bit tags, the probability that an attacker
can produce a correct tag for any message of its choosing is no more
than 1/2^30, 1/2^60, 1/2^90 or 1/2^120, respectively''?

I posted a detailed explanation of a reasonably fast UMAC-128 attack
that forges a tag with probability above 1/2^(88.001). You accuse me of
fabricating evidence; are you denying that this attack's success
probability is billions of times larger than your claimed 1/2^120 bound?
In what wacko universe are your claims ``honest, fair, and accurate''?

You're not going to be able to weasel out of this one. I see that I'm
successfully pressuring you into attempting to prove your bounds on the
UMAC forgery probability (rather than merely issuing the false claim
that you've already ``rigorously proven'' the bounds); however, even if
you eventually succeed in proving your questionable 1/2^60 claim, you
will never succeed in proving your false 1/2^90 and 1/2^120 claims.

> these endless UMAC posts.

I've had enough of your false UMAC advertising over the past year.
You're not content to state the facts regarding UMAC; you insist on
exaggerating them into something wildly inaccurate. I thought at first
that your misstatements could be adequately explained by stupidity, but
at this point we all know that you're deliberately stretching the truth.
You ought to have apologized and corrected your errors many months ago.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

---

From: Ted Krovetz <[email-masked]>
Date: Tue, 4 Oct 2005 20:37:15 -0700

David,

> If a scheme claims to provide provable security, it's not unreasonable
> to ask for these things, and if they are missing, to point out that  
> fact.

We have come to the conclusion that a proof should be posted, and  
earlier today I committed us to posting one in the next day or two.

The delay in doing so has never been about us not having a proof, as  
Bernstein so rashly postulates. Instead, it has not been produced for  
a few reasons:

- It is elementary and tedious,

- It was not written down in a publishable form (beyond the \e-SU  
proof of UHASH), and

- The request came from Bernstein only after he had been calling us  
liars and despicable weasels. (It is difficult to fulfill anybody's  
request when they behave so rudely.)

I will post here again when the proof is posted on our website.

Thank you,
Ted Krovetz

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Oct 2005 04:24:52 -0000

> The request came from Bernstein only after he had been calling us  
> liars and despicable weasels.

On 20 January 2005, after pointing out most of the same issues and
catching yet another of your security-bound calculation errors, I wrote:

   I've been quite careful to quantify the Poly1305-AES security
   guarantee in terms of the number of authenticated messages, the
   number of forgery attempts, and the attacker's chance of breaking
   AES; I suggest that you do the same for UMAC, and then reconsider
   your assertion that UMAC-64 is ``safe.''

Back then, I thought that your exaggerations were accidents, and I spent
a lot of time politely explaining what you were doing wrong. Rather than
saying thanks and correcting your errors, you continued stating unproven
(and often false) ``rigorously proven'' security bounds in new drafts of
your UMAC specification. Stupidity is not an adequate explanation for
this behavior; it is blazingly clear that you are not being honest.

I understand that you like UMAC. It has many virtues; it's close to the
state of the art, except in key agility. BUT YOU HAVE A RESPONSIBILITY
TO THE USERS TO STOP CLAIMING SECURITY BOUNDS THAT HAVE NOT BEEN PROVEN.
You need to immediately withdraw your false claims of 1/2^90 and 1/2^120
bounds on the UMAC-96 and UMAC-128 single-forgery probabilities, and you
need to characterize any remaining UMAC forgery-probability bounds as
conjectures unless and until they have been proven.

---

From: David McGrew <[email-masked]>
Date: Thu, 6 Oct 2005 12:24:21 -0700

Ted and fellow CFRGers,

here's a quick recap of the process and where we stand.  The umac  
draft is in review as a CFRG draft.  When the RG has reached a rough  
consensus that it should be published as an RFC, then it is the  
responsibility of the RG chairs to request the area director to move  
it forward.

At present, the authors are writing some additional material.  Let's  
hold off discussion on topics specific to this draft pending this  
update.  Afterwards, we'll figure out what the rough consensus is.   
If the group feels the need to ask the authors for changes, we'll do  
so.  Otherwise, we'll notify Russ and move forward.

David

p.s. - for those people not familiar with the IRTF and IETF  
processes: you might be interested to read ftp://ftp.isi.edu/in-notes/ 
rfc2014.txt

On Oct 4, 2005, at 2:38 PM, Ted Krovetz wrote:

>
> Today is the date of the original 4-week timeout that the RFC  
> editor placed on the IESG for UMAC comments. In that spirit I ask,  
> please, Russ Housley, or whoever else has the authority to end this  
> madness, please close the comment period so that we can all get on  
> with our lives.