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

[Bryan Ford <[e-mail]>]

On 03 Dec 2015, at 01:28, Damien Miller <[e-mail]> wrote:
> 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).

Agreed, that’s exactly what the APEAD interface-extension I proposed is trying to make possible, at least in the case of TLS.  The same APEAD interface extension also solves a slightly different need in the case of DTLS and similar out-of-order datagram-oriented protocols, where the length isn’t a problem but the receiver instead needs to get at an encrypted sequence number somehow in order to know which nonce to use for decryption.

Philipp Jovanovic, my amazing new postdoc, pointed out that the CAESAR cipher competition defined a “secret message number” feature that AEAD submissions can optionally implement:

	http://competitions.cr.yp.to/caesar-call.html <http://competitions.cr.yp.to/caesar-call.html>

…and pointed to a nice explanation by DJB clarifying both the motivation and intended function of this secret message number feature:

	https://groups.google.com/forum/#!searchin/crypto-competitions/secret$20message$20numbers/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J <https://groups.google.com/forum/#!searchin/crypto-competitions/secret$20message$20numbers/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J>

This seems like exactly the thing the DTLS case wants, although it doesn’t address the encrypted-length problem in the case of TLS.  I’m curious how many CAESAR cipher submissions actually ended up supporting secret message numbers; does anyone have a sense for this?

It seems like the APEAD extension I proposed is more general than an AEADs with secret message numbers, in that it is easy to build an “AEAD with secret message numbers” from an APEAD.  On encryption, just prepend the secret message number to both the plaintext and the nonce and feed them to the APEAD encrypt interface.  On decryption, invoke the APEAD preview call to decrypt the (not-yet-authenticated) secret message number, prepend it to the nonce, and invoke the full APEAD decrypt-and-authentication function.

Perhaps DJB can comment - is my reasoning sound about the relationship between the proposed APEAD extension and the CAESAR competition’s optional secret message number feature?  Is there anything seriously problematic or unsound from a crypto perspective about such an APEAD interface extension or feature, aside from the well-known risks associated with any use of (“previewed”) data before it’s been integrity-checked?

Cheers
Bryan