Review of AEAD Encryption API Project; concluding December 5, 2008
hartmans at MIT.EDU
Mon Dec 1 14:40:19 EST 2008
>>>>> "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.
More information about the krbdev