Re: [Cfrg] New UMAC Draft

"D. J. Bernstein" <djb@cr.yp.to> Fri, 30 September 2005 20:50 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELRq0-0007Kt-1K; Fri, 30 Sep 2005 16:50:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELRpy-0007Jb-5C for cfrg@megatron.ietf.org; Fri, 30 Sep 2005 16:50:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18015 for <cfrg@ietf.org>; Fri, 30 Sep 2005 16:50:32 -0400 (EDT)
Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELRxr-0005rF-3u for cfrg@ietf.org; Fri, 30 Sep 2005 16:58:46 -0400
Received: (qmail 31668 invoked by uid 1016); 30 Sep 2005 20:50:48 -0000
Date: Fri, 30 Sep 2005 20:50:48 -0000
Message-ID: <20050930205048.31667.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@ietf.org
Subject: Re: [Cfrg] New UMAC Draft
References: <3C1D5161-1625-4456-B275-2CF122F37EAB@csus.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Sender: cfrg-bounces@ietf.org
Errors-To: cfrg-bounces@ietf.org

Ted Krovetz writes:
> Please tell me which of the following is not true:
  [ series of lemmas that might be useful in a UMAC security proof ]

As I see it, the main risk of error is not in any of your lemmas, but
in how you're putting the lemmas together to obtain an overall bound on
the UMAC forgery probability. Certainly this is the part that led to
your incorrect UMAC security claims last year, and the part where you're
continuing to be incredibly sloppy.

Your latest UMAC security claim (which, like your incorrect claims, is
alleged to be ``rigorously proven'') appears to be the following:

   Claimed theorem. An attack against UMAC-32n using at most 2^64 chosen
   messages and one forgery attempt cannot have success probability
   larger than 2^{-30n}, if AES is secure.

There isn't much wiggle room here: you haven't defined ``secure'' yet,
but you've clearly stated that you're bounding the forgery probability,
you've clearly stated that your bounds are exactly 2^{-30}, 2^{-60},
2^{-90}, 2^{-120} for UMAC-32, UMAC-64, UMAC-96, and UMAC-128, and
you've clearly stated that you're allowing 2^64 chosen messages.

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

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

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