Re: [Cfrg] new authenticated encryption draft

Ted Krovetz <tdk@acm.org> Mon, 21 August 2006 16:26 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCbA-0003uU-4j; Mon, 21 Aug 2006 12:26:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCb8-0003uP-SW for cfrg@ietf.org; Mon, 21 Aug 2006 12:25:58 -0400
Received: from ylpvm12-ext.prodigy.net ([207.115.57.43] helo=ylpvm12.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCb7-0008RH-Lt for cfrg@ietf.org; Mon, 21 Aug 2006 12:25:58 -0400
X-ORBL: [71.143.31.60]
Received: from [192.168.0.199] (adsl-71-143-31-60.dsl.scrm01.pacbell.net [71.143.31.60]) by ylpvm12.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k7LGPnUY019429 for <cfrg@ietf.org>; Mon, 21 Aug 2006 12:25:50 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <E1GETF9-0006RW-PH@megatron.ietf.org>
References: <E1GETF9-0006RW-PH@megatron.ietf.org>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <F297F17D-CAE7-4909-9B0A-F668755B5DFB@acm.org>
Content-Transfer-Encoding: 7bit
From: Ted Krovetz <tdk@acm.org>
Subject: Re: [Cfrg] new authenticated encryption draft
Date: Mon, 21 Aug 2006 09:25:29 -0700
To: cfrg@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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

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?

If you are curious about my schemes, you can see them at fastcrypto.org.

Cheers,
Ted


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