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