Initial comments request: AEAD Encryption API

[Ken Raeburn]

On Nov 5, 2008, at 11:18, Sam Hartman wrote:
> Folks, I'm helping Luke Howard who is working on getting a number of
> Microsoft extensions integrated into MIT Kerberos.  I'm putting
> together documentation sufficient for our review of the work as well
> as reviewing his code.
>
> I'd like to get some early comments on
> http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API .

A spec for the crypto stuff would help.  And API docs.

> In particular, I'd definitely like feedback on the open design
> questions and on the implementation choices.  If you want to look at
> code, take a look at the mskrb-integ branch.

> Design questions
> 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.

> The API exposes padding separate from trailers. However RFC 3961 has  
> neither concept. Is this the right balance?

Once you start doing scatter-gather and in-place encryption, it's hard  
to keep things abstract.  RFC 3961 imposes a few arbitrary-looking  
constraints, but having easily separated padding and trailers, and an  
identifiable integrity-check tag, is not among them.

I'd have been happy to rework 3961 to include some form of AEAD  
support so we don't have to provide the building blocks for SSPI to  
build it at a higher level, but that got shot down every time I  
suggested it.  (To be fair, we were focusing on 4120 at the time,  
where it could've been used but not without making more drastic  
changes relative to 1510 than most of us wanted.)  Skimming the code  
and trying to work back to a rough idea of how a spec might work, it  
looks to me like AEAD is "defined" for RC4 and for the simplified- 
profile cryptosystems, but not in the general case.  (And much as we  
might dislike DES, if we want to provide AEAD as truly general  
functionality, it must be defined there too.)  So if we were to adopt  
an algorithm that doesn't use the simplified profile, we'd have to  
also specify how AEAD would work, with (as yet) no framework for how  
that specification should be written up.

> With the existing crypto systems, the order between data chunks and  
> sign_only chunks matters. That is, (data|sign_only|data) will  
> produce a different checksum than (sign_only|data|data). Do we want  
> callers to depend on this, or will doing so create a problem if we  
> have a crypto system based on RFc 5116? I suspect that we want to  
> say that a crypto system may treat the sign_only chunks as one  
> ordered sequence and the data chunks as another ordered sequence but  
> not require that the relative ordering between data chunks and  
> sign_only chunks affect the cipher text.

Depends on SSPI usage, I guess.  That may be a loosening of the  
security properties it currently gives.  That may be something to talk  
about in Minneapolis if you're going; it looks like I won't be.   
(Either a change to SSPI, with Larry, or a convergence between GSS-API  
and SSPI functionality, and the associated effect on Kerberos crypto  
if we want to maintain a generic Kerberos mechanism, in either or both  
working groups.)

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.

> 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.

> I'm not sure how padding is supposed to work. Does the API reduce  
> padding size?

> Implementation notes
> While the API supports in-place encryption the implementation does  
> not significantly reduce the number of copies.

We should decide if in-place encryption is important to us.  Forcing  
the application to explicitly copy an input it wants to use multiple  
times is annoying, but in-place encryption can help memory-constrained  
environments.

I can imagine some specific uses for separate inputs and outputs with  
scatter-gather.  For example, Tom and I have discussed a possible ASN. 
1 encoder scheme that tracks the various bits of data to be put  
together (tags, encoded numbers, etc), but avoids actually copying the  
application data (strings, buffers) until assembling the final result  
(instead of our current annoying copy-backwards-and-reverse-at-the-end  
approach); for a message part to be encrypted, with scatter-gather  
input and a big buffer output, we could avoid the copying altogether  
except as it happens in the encryption process.  Requiring it to be in- 
place means copying the application data to temporary storage before  
encrypting, like we do now.

But trying to implement the "ask for the size needed" approach in  
encryption would probably have to be extended to (1) ask for the  
number of chunks needed, and (2) ask for the size of each, or maybe  
all at once, once the iov structures are allocated.

> The implementation is parallel to the existing implementation. In  
> particular, the existing APIs are not implemented in terms of the  
> new APIs. New code is required (with significant copying) from the  
> generic API layer down to the enc_provider layer, although of course  
> raw crypto primitives are used.
> Currently sanity checking buffers--for example making sure there is  
> a trailer chunk--is left to the enc_provider implementations.

Currently, there's no AEAD for DES, so we can't just build generic  
encryption on top of generic AEAD.  And having to separate ciphertext  
and trailers means building generic decryption on top of generic AEAD  
would be kind of ugly even if we had the DES support, unless we  
implement a new chunk type for "everything thrown together", or a way  
to pull out the lengths of the different parts.

Ken