Review of Kerberos AEAP API

Love Hörnquist Åstrand lha at
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  
> wrote:
>> 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  
> in
> 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  
>> an
> 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- 
>> init
>> 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 mailing list