Review of Kerberos AEAP API
Love Hörnquist Åstrand
lha at kth.se
Tue Dec 2 13:35:27 EST 2008
2 dec 2008 kl. 19:06 skrev Nicolas Williams:
> On Tue, Dec 02, 2008 at 09:46:20AM -0800, Love Hörnquist Åstrand
>> Hello here is my comments from the initial pass over the document.
>> Limiting to only on DATA buffer is overly restrictive.
> I made the same comment. I strongly recommend that more than one DATA
> buffer be allowed on encryption and decryption. At the very least the
> API needs to allow for support for more than DATA buffer to be added
> the future (but I think it effectively does).
>> On decryption, the HEADER/TRAILER data should be define to be read
>> only as well as the ivec content, ie it should be possible to setup
> I don't understand that.
Setup header, data (padding right), trailer in a ivec, fill with data,
call decrypt, fill with new data, decrypt again.
The decryption should not touch header/trail data, nor the content of
header/trailer so that there is only one setup needed.
>> recv'er ivec array and keep reusing it over and over again w/o re-
>> the data.
>> There should be an option to have a readonly DATA buffer, but I can
>> live w/o that for now.
> So an option to not always do in-place crypto? It could be useful on
> encryption for filesystems (where the source is a page in the fs page
> cache that must not be modified, say).
Or (more likly) RO network buffers.
More information about the krbdev