Subject: Re: [Cfrg] new authenticated encryption draft

From: Ted Krovetz <[email-masked]>
Date: Mon, 21 Aug 2006 09:25:29 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "David A. McGrew" <[email-masked]>
Date: Mon, 21 Aug 2006 17:02:49 -0700

Hi Ted,

On Aug 20, 2006, at 9:35 AM, Ted Krovetz wrote:

> 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  

Great, thanks!

David