Initial comments request: AEAD Encryption API

[Sam Hartman]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Wed, Nov 05, 2008 at 06:11:11PM -0500, Ken Raeburn
    Nicolas> wrote:
    >> On Nov 5, 2008, at 11:18, Sam Hartman wrote: > Folks, I'm
    >> helping Luke Howard who is working on getting a number of >
    >> Microsoft extensions integrated into MIT Kerberos.  I'm putting
    >> > together documentation sufficient for our review of the work
    >> as well > as reviewing his code.
    >> >
    >> > I'd like to get some early comments on >
    >> http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API .
    >> 
    >> A spec for the crypto stuff would help.  And API docs.

    Nicolas> +1

    >> > The API exposes padding separate from trailers. However RFC
    >> 3961 has > neither concept. Is this the right balance?
    >> 
    >> Once you start doing scatter-gather and in-place encryption,
    >> it's hard to keep things abstract.  RFC 3961 imposes a few
    >> arbitrary-looking constraints, but having easily separated
    >> padding and trailers, and an identifiable integrity-check tag,
    >> is not among them.

    Nicolas> A revision certainly seems likely to be needed.

Both this and a spec for the protocol level details of what Microsoft has done are out of scope for what Luke and I are funded to do.
I don't know if the EU filings from Microsoft contain details on this.

    >> > The implementation is parallel to the existing
    >> implementation. In > particular, the existing APIs are not
    >> implemented in terms of the > new APIs. New code is required
    >> (with significant copying) from the > generic API layer down to
    >> the enc_provider layer, although of course > raw crypto
    >> primitives are used.

    Nicolas> If that's for performance reasons, then that's quite
    Nicolas> understandable.

It was done to simplify implementation and to avoid the whole tree depending on a new feature.


--Sam