Review of AEAD Encryption API Project; concluding December 5, 2008
Sam Hartman
hartmans at MIT.EDU
Mon Dec 1 16:01:02 EST 2008
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> On Mon, Dec 01, 2008 at 03:01:53PM -0500, Sam Hartman
Nicolas> wrote:
>> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com>
>> writes:
Nicolas> Think of NFSv4-like COMPOUND above RDDP. A COMPOUND
Nicolas> could have two bulk data operations interspersed with
Nicolas> other operations.
>> I'm still missing it. Why do you think this compound will not
>> be able to identify the crypto header and trailer?
Nicolas> That's not the problem. The problem is that in that
Nicolas> example there are two large chunks of data that will be
Nicolas> directly placed into different destinations.
If you know where the header and trailer are, then don't use the
stream cryptotype.
Nicolas> Think of a pattern like: crypto header, app header, app
Nicolas> data, app header, app data, ..., crypto trailer, MIC.
I would not use stream for this pattern.
Nicolas> I understand that, but please don't paint yourselves into
Nicolas> a corner on this.
>> I think expanding the API in the future would be easy from an
>> interface standpoint. I think that the current behavior is to
>> return an error if you pass in multiple stream buffers, so you
>> can tell which API you have.
Nicolas> Make sure the same applies to the GSS-API extensions.
I have not reviewed that code yet, but I think the same is true of the
iov GSS extension.
More information about the krbdev
mailing list