Initial comments request: AEAD Encryption API
hartmans at MIT.EDU
Wed Nov 5 20:49:47 EST 2008
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> On Wed, Nov 05, 2008 at 06:11:11PM -0500, Ken Raeburn
>> 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.
>> > 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
It was done to simplify implementation and to avoid the whole tree depending on a new feature.
More information about the krbdev