Review of AEAD Encryption API Project; concluding December 5, 2008

[Sam Hartman]

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

    Nicolas> For the decrypt side I think you need the option for:

    Nicolas> 1. One or more buffers of type KRB5_CRYPTO_TYPE_STREAM

    Nicolas>    Instead of exactly one KRB5_CRYPTO_TYPE_STREAM chunk.

    Nicolas>    The reason is that the peer may be sending data split
    Nicolas> into multiple chunks.  Think of applications like RDDP,
    Nicolas> where the sender has used the IOV AEAD API and laid out
    Nicolas> the encrypted results and MICs of complex data structures
    Nicolas> such that each piece will end up in the right place on
    Nicolas> the receiving side.

I don't think stream buffers would be useful in the rddp case: rddp has fairly strong information about the data layout.

The only reason we include the stream buffer type is so that there is
a relatively easy API to use if you have AEAD but you do not know the
message structure.  Otherwise you'd just use the old APIs.

It makes the stream code significantly easier if it only has to deal
with one stream buffer.  So my belief is that this is not worth the
code complexity.  Based on a couple of wrong turns we made with
handling padding, I think I have good handle on exactly how much
complexity is introduced by supporting more buffers than is required.