AEAD - Wan Teh's proposal

[Michael StJohns <msj@nthpermutation.com>]

Hi -

I was listening in via phone during the F2F, but unfortunately I ended 
up in a dead spot just as Wan Teh started talking about his AEAD 
proposal, so I pretty much missed any context information not present in 
his slides.   It's possible some of my comments below will be OBE based 
on those - so bear with me.

I made a somewhat different proposal on the list back on 15 Feb but 
heard no direct comments back.  At the end of my proposal I listed a 
number of characteristics of my proposal and I'm going to try and 
compare Wan Teh's proposal to mine point by point.

> This approach
>
> a) allows for any length of message or encrypted stream (e.g. while 
> the mechanism may restrict this, the API doesn't)
Based on slide 16, Wan Teh's proposal supports this.

> b) makes no assumption about whether or not decrypted data may be 
> released before the integrity tag is verified. (again, mechanism or 
> mode of HSM may restrict this).

Slide 9 appears to require all modes that use AEAD decryption to not 
release data until the tag is verified.  I believe this should not be a 
characteristic of the API, but of specific modes or even of the HSM in a 
specific (e.g. FIPS) mode.

> c) has no requirement for pre-call marshalling and formatting of the 
> crypto stream (e.g. no assumptions about exactly where the integrity 
> tag is and its length nor where the AAD is and its length - no memory 
> to memory copies should be required prior to the call).

Slide 13 appears to indicate that Wan Teh's proposal does not support 
this.  AFAIK ALL existing AEAD algorithms have an identifiable set of 
bytes that are the integrity tag.  In protocols, generally, but not 
always,  the tag follows the data, but that should not be a restriction 
of the API.

> d) can deal with AAD preceeding and following the ciphertext/data to 
> be encrypted (future proofing)
Slide 11 indicates no support.  This slide actually has an error of 
fact.   McGrew has proposed an AEAD cipher based on CBC and HMAC and 
uses the following construct for the calculation of the MAC  T = 
MAC(MAC_KEY, A || S || AL) - where A is the associated data and AL is 
the length of the associated data.  For our purposes, the AL is actually 
unencrypted associated data which means that the associated data both 
precedes and follows the ciphertext.   And yes, the mode could do this - 
but that's less general that permitting prefix and suffix AAD.

> e) handles message based encryption as a separate and backwards 
> compatible item from AAD and IV generation. (e.g. can actually do 
> per-message CBC stuff within an association using new calls).

I can't find anything equivalent in Wan Teh's proposal.

> f) divorces IV generation specification from mechanism specification - 
> same mechanism can use multiple IV generation mechanisms (future 
> proofing).

Slide 14 indicates this isn't supported.

> g) mirrors, extends or combines existing functions so easy transitions 
> for future programming.
There's some of this.

> h) possible to use IV generator for decrypt, but not required.
Maybe possible - slide 10 seems to tie this to AEAD vs non AEAD rather 
than mechanism specific.

> i) includes functions to do message verification and signature

Not supported by Wan Teh's proposal.  This is at least as important as 
the encrypt message stuff.


One final thing - Wan Teh's message based 
encryption/decryption/sign/verify seems to be tied specifically to AEAD 
modes - that misses the point that the need for message processing is a 
distinct and separate requirement from supporting AEAD constructs and 
misses the need for message processing for just signature/verify constructs.

I appreciate the desire to solve this specifically for TLS, but I 
believe that approach is short sighted.  The API should be as general as 
possible, and should not have constraints based on current usages.