Re: [Cfrg] new authenticated encryption draft
"David A. McGrew" <david.a.mcgrew@mindspring.com> Tue, 22 August 2006 00:02 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFJjL-0002U2-52; Mon, 21 Aug 2006 20:02:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFJjK-0002Tn-5T for cfrg@ietf.org; Mon, 21 Aug 2006 20:02:54 -0400
Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFJjI-0000B1-QE for cfrg@ietf.org; Mon, 21 Aug 2006 20:02:54 -0400
Received: from [128.107.248.220] (helo=[172.17.198.35]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1GFJjI-0008Ef-2k; Mon, 21 Aug 2006 20:02:52 -0400
In-Reply-To: <BC265F50-6FE3-42D2-99F1-DAA732F050A3@acm.org>
References: <E1GETF9-0006RW-PH@megatron.ietf.org> <BC265F50-6FE3-42D2-99F1-DAA732F050A3@acm.org>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1240BDA3-A9DB-4D27-8F57-2BFCC145177E@mindspring.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <david.a.mcgrew@mindspring.com>
Subject: Re: [Cfrg] new authenticated encryption draft
Date: Mon, 21 Aug 2006 17:02:49 -0700
To: Ted Krovetz <tdk@acm.org>
X-Mailer: Apple Mail (2.752.2)
X-ELNK-Trace: ad1f9a46c4c7bfd19649176a89d694c0f43c108795ac45079896f847cd55457ddbb28f10f6389839350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 128.107.248.220
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: cfrg@ietf.org
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
Hi Ted, On Aug 20, 2006, at 9:35 AM, Ted Krovetz wrote: > Hello David, > > Thank you for this. > > I am developing AEAD methods based on UMAC and VMAC. (VMAC is a 64- > bit cousin to UMAC that MACs at a peak rate of 0.5 cpb on 64-bit > architectures.) I will keep your recommendations in mind while > making my definitions, and if I have any comments I'll get them to > you ASAP. > > One thing my definition does is allow for associated data to be > added after encryption, so an encryption can have both an > authenticated header and footer. (What is MACed is Header|| > Ciphertext||Footer.) This seems like it might be useful if one is > encrypting something long. If a scheme only can MAC Header|| > Ciphertext, and one wants to MAC Header||Ciphertext||Footer, then > what must be done is buffer Ciphertext until Footer is ready and > MAC Header||Footer||Ciphertext. > > Do your definitions allow for such flexibility? Is my intuition > that Footers may be useful valid? > A footer would certainly be useful in some situations; it's mentioned in the draft as the first of the "Open Questions" in Section 8. There is at least one application where an authenticated footer would be useful AFAIK, which is SRTP, but in that protocol it is not really inconvenient to put the 'footer' data into the authenticated header (putting the authenticated data into a footer is a minor implementation convenience that allows the MAC to be computed in a single continuous pass over the data input instead of using an init/ update/update/final sort of approach). There might be applications in which it is essential to have a footer in order to avoid buffering, as you point out. The GCM and CCM algorithms don't support authenticated footers, unfortunately. So if the interface was changed to support a footer, then it would need to be defined as being optional. This is why I didn't include it in the first draft; I figured that the additional complexity of an additional input that not all algorithms supported wasn't worth it (since I didn't know of an application where a footer was essential). I'd really value input from others here. Anyone know of a case where a footer is required? > If you are curious about my schemes, you can see them at > fastcrypto.org. > Great, thanks! David > Cheers, > Ted > _______________________________________________ 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