RE: [Cfrg] new authenticated encryption draft
"Blumenthal, Uri" <uri.blumenthal@intel.com> Tue, 12 September 2006 12:30 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7P5-00077C-Bk; Tue, 12 Sep 2006 08:30:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7P3-00076s-U9 for cfrg@ietf.org; Tue, 12 Sep 2006 08:30:13 -0400
Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN7P1-0005dU-Du for cfrg@ietf.org; Tue, 12 Sep 2006 08:30:13 -0400
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 12 Sep 2006 05:30:08 -0700
Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 12 Sep 2006 05:30:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,152,1157353200"; d="scan'208"; a="125266297:sNHT22626534"
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 05:30:08 -0700
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 05:30:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Cfrg] new authenticated encryption draft
Date: Tue, 12 Sep 2006 08:29:59 -0400
Message-ID: <279DDDAFA85EC74C9300A0598E7040569C24FB@hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] new authenticated encryption draft
thread-index: AcbWFNGv1ZXSQMdzRC2knJa5MBSR6gAUkR9Q
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: cfrg@ietf.org
X-OriginalArrivalTime: 12 Sep 2006 12:30:08.0643 (UTC) FILETIME=[2F13A530:01C6D667]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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>
Errors-To: cfrg-bounces@ietf.org
Cryptographically I agree with Dan. -----Original Message----- From: D. J. Bernstein [mailto:djb@cr.yp.to] Sent: Monday, September 11, 2006 10:37 PM To: cfrg@ietf.org Subject: Re: [Cfrg] new authenticated encryption draft Steven M. Bellovin writes: > Many people have made similar proposals; others disagree -- there's a > layering issue here that might impact security. No, there isn't. Nonces used to recognize out-of-order packets have a security requirement, no matter what layer they're in: they _must_ be generated in increasing order. Nonces used as MAC inputs also have a security requirement, no matter what layer they're in: they _must_ be unique. In an efficient protocol, these nonces are unified. There's one piece of security-critical code generating one nonce in increasing order. In an inefficient protocol, these nonces are separated, and there are two pieces of security-critical code generating the two nonces. > Let me give a slightly -- but only slightly -- contrived example. Suppose > you had a site-to-site VPN, where the encryptor used counter mode driven > by the TCP sequence number. The TCP sequence number isn't a nonce; it repeats. The TCP sequence number is the _bottom 32 bits_ of a nonce _for one connection_ (plus an irrelevant offset). The nonce is, as I said before, the number of bytes transmitted through the connection. It's safe to use this nonce to encrypt those bytes in counter mode under a connection-specific key. ---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 _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg
- [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft Hal Finney
- Re: [Cfrg] new authenticated encryption draft Greg Rose
- Re: [Cfrg] new authenticated encryption draft Ted Krovetz
- Re: [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft John Wilkinson
- RE: [Cfrg] new authenticated encryption draft Scott Fluhrer
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft David Wagner
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft Hal Finney
- Re: [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft David Wagner
- RE: [Cfrg] new authenticated encryption draft Santosh Chokhani
- Re: [Cfrg] new authenticated encryption draft Ken Raeburn
- Re: [Cfrg] new authenticated encryption draft John Wilkinson
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft John Wilkinson
- Re: [Cfrg] new authenticated encryption draft D. J. Bernstein
- Re: [Cfrg] new authenticated encryption draft Steven M. Bellovin
- Re: [Cfrg] new authenticated encryption draft D. J. Bernstein
- RE: [Cfrg] new authenticated encryption draft Blumenthal, Uri
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft Tom Shrimpton
- Re: [Cfrg] new authenticated encryption draft D. J. Bernstein
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft John Wilkinson
- RE: [Cfrg] new authenticated encryption draft Doug Whiting
- Re: [Cfrg] new authenticated encryption draft Steven M. Bellovin
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft David McGrew
- Re: [Cfrg] new authenticated encryption draft David McGrew
- RE: [Cfrg] new authenticated encryption draft Tom Shrimpton
- Re: [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft John Wilkinson
- Re: [Cfrg] new authenticated encryption draft Phillip Rogaway
- Re: [Cfrg] new authenticated encryption draft David A. McGrew
- Re: [Cfrg] new authenticated encryption draft David McGrew
- [Cfrg] AES-based key derivation David McGrew