Initial comments request: AEAD Encryption API
raeburn at MIT.EDU
Wed Nov 5 20:05:44 EST 2008
On Nov 5, 2008, at 18:30, Nicolas Williams wrote:
> First, to specify AEAD by generic composition for the existing
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.
More information about the krbdev