Initial comments request: AEAD Encryption API

[Luke Howard]

>> Supporting multiple data chunks that are not block-size aligned is  
>> tricky . Is it actually needed?
>
> Without a spec, I can only guess that it would be, at least for the  
> associated data.

I think it is fine to support, and in any case likely easier for the  
associated data (I'm not aware of any checksum mechanisms used with  
Kerberos that require the input data to be padded).

In the current implementation, a single padding buffer is provided to  
pad the total length of all encrypted data buffers to the blocksize.  
For GSS, the padding buffer length is indicated by the contents  
thereof (pre-RFC 4121) or EC (post-RFC 4121).

> It already looks like the protection is kind of weak for two  
> consecutive chunks of the same type; an attacker could push data  
> around and adjust some lengths, and ciphertext and plaintext wind up  
> moving from one block to another, with no change to the checksum.   
> If the chunking is purely for convenience and not intended to be  
> protected or to carry meaning, then yes, I think perhaps we could  
> define something based on RFC 5116.

I'm not familiar with RFC 5116 but I will read it. But yes, I have  
been assuming chunking is for convenience and associated data. The  
chunks would typically be concatenated before sending.

>> The API design assumes fixed-length headers, padding and trailers.
>
> It also looks like for decryption you have to know how to separate  
> the different components (e.g., ciphertext from trailer) before  
> decrypting.

Yes. For the DCE case this is carried in the RPC PDU itself.

-- Luke