Initial comments request: AEAD Encryption API
raeburn at MIT.EDU
Wed Nov 5 18:11:11 EST 2008
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
> 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
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
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.
More information about the krbdev