IETF Logo Mail Archive

Re: [Cfrg] new authenticated encryption draft

"D. J. Bernstein" <djb@cr.yp.to> Tue, 12 September 2006 01:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMwvC-0002bI-Mg; Mon, 11 Sep 2006 21:18:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMwvB-0002bD-Qi for cfrg@ietf.org; Mon, 11 Sep 2006 21:18:41 -0400
Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GMwv7-0006Ed-HT for cfrg@ietf.org; Mon, 11 Sep 2006 21:18:41 -0400
Received: (qmail 21743 invoked by uid 1016); 12 Sep 2006 01:19:03 -0000
Date: Tue, 12 Sep 2006 01:19:03 -0000
Message-ID: <20060912011903.21742.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 authenticated encryption draft
References: <74A5A0C3-8E6E-47B4-A67B-C51ED97B2897@mindspring.com> <da7b3ce30608201147u12c0c2f6s61694713e59cfa4a@mail.gmail.com> <p06230910c10e98a55c4c@10.30.1.9> <f207274d0608221905t2797ca6ew2a769dd5d9e3d410@mail.gmail.com> <3D640F53-58F3-4AE4-AEFC-145BBD9BC9A0@cisco.com> <f207274d0609011652m3bb76587xdd6cd9e1d3140e63@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
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

Networks often transmit packets repeated, out of order, etc. To detect
and correct these problems, we attach an increasing nonce to each
packet, such as the number of bytes transmitted previously. (The nonce
can be compressed for transport; for example, TCP's ``sequence number''
is essentially the bottom 32 bits of the nonce.)

The obvious way to prevent forgery and eavesdropping is to reuse this
nonce for a MAC and a stream cipher. It's a waste of time and bandwidth
to have a separate cryptographic layer producing its own nonce.

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

v2.23.0 | Report a Bug | By Email