Initial comments request: AEAD Encryption API
lhoward at MIT.EDU
Sat Nov 8 08:09:21 EST 2008
>> 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
Yes. For the DCE case this is carried in the RPC PDU itself.
More information about the krbdev