Re: [Cfrg] Discuss/standardize Preview extension to AEAD abstraction?

[Damien Miller <[e-mail]>]

On Mon, 30 Nov 2015, Bryan Ford wrote:

> A few days ago I started a thread on the TLS list on encrypting TLS
> headers, like SSH has been doing for a long time, to add (limited but
> useful) protection against passive fingerprinting and traffic analysis
> attacks. I then learned that there’s a parallel discussion thread
> touching on the same topic on the SSH mailing list. I don’t want to
> start yet another discussion thread on the merits of header-encryption
> in general (see either of those two existing threads if you want to
> jump in on that :) ) - but I wanted to bring up the technical issue
> of how header-encryption interacts with the shift toward AEAD cipher
> designs. This seemed like a potentially interesting CFRG topic.
>
> The general problem (for TLS or SSH or many other protocols) is that
> we might like to encrypt both the header and the payload, but the
> header typically includes the length field, and the receiver needs
> that length field to know how big of a blob to read and pass to the
> AEAD for decryption and integrity-checking. Thus, we really would
> like a three-stage receive process: (1) decrypt header to retrieve
> length, (2) read the cipher text payload, (3) decrypt the payload and
> integrity-check both the header and payload. Is it worth considering
> a fairly simple extension to the AEAD abstraction that would support
> this form of operation?

Speaking as an application developer, I want a primitive that allows
me to "seal" zero or more bytes of plaintext to be encrypted and
authenticated along with zero or more bytes of AAD to be authenticated
into a self-delimiting blob that preserves the integrity and
*optionally the privacy* of the lengths of the plaintext and AAD.

At the other end, I want to, given enough of the header of that blob,
be able to determine a) how many bytes I need to read to get the whole
thing, b) how much space I'll need to extract the plaintext (if any) and
c) how much space I'll need to extract the AAD (if any).

This is pretty close to the crypto_box abstraction in NaCl or
BoringSSL's EVP_AEAD_CTX_seal, but it goes a little further in making
the result *including length fields* entirely opaque to the application
developer.

IMO this would cover most (not all) application use-cases with a simple,
hard to misuse primitive.

Something like this:

size_t box_seal_need(struct cipher *ctx,
    size_t plaintext_len, size_t aad_len);

int box_seal(struct cipher *ctx,
    const u_char *plaintext, size_t plaintext_len,
    const u_char *aad, size_t aad_len,
    u_char *sealtext, size_t sealtext_len);

size_t seal_header_need(struct cipher *ctx);

int box_open_need(struct cipher *ctx,
    const u_char *seal_header, size_t seal_header_len,
    size_t *sealtext_len, size_t *plaintext_len, size_t *aad_len);

int box_open(struct cipher *ctx,
    const u_char *sealtext, size_t sealtext_len,
    u_char *plaintext, size_t plaintext_len,
    u_char *aad, size_t aad_len);

-d