Initial comments request: AEAD Encryption API

[Ken Raeburn]

On Nov 5, 2008, at 18:30, Nicolas Williams wrote:
> First, to specify AEAD by generic composition for the existing  
> enctypes.

Not so generic, given that rc4 and simplified-profile versions appear  
to be rather different.  At least, not if we want this to actually be  
compatible with Microsoft, and, separate from extending RFC 3961, MIT  
does need the Microsoft compatibility right now.

> Second, to specify new enctypes that use AEAD modes of AES and avoid
> generic composition.

Probably a good idea eventually, yes, especially if the performance is  
significantly better than the separate encryption and HMAC with  
different keys that we're doing now.

> There may not be enough interest in the latter.

If such a mode is implemented in crypto accelerators (e.g., done for  
IPsec, but not built into the network hardware), there may be some  
benefit to supporting it in Kerberos/GSSAPI kernel modules for NFSv4  
etc, but otherwise I'm not sure where the impetus would come from; I  
don't know that many Kerberos-based applications find encryption to be  
a bottleneck.  And if one does channel bindings to IPsec and skips the  
GSSAPI-level encryption, there'd still be little point.

Ken