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