Subject: [Cfrg] Streaming AEAD
From: "Manger, James" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Adam Langley <[email-masked]>,Niels Möller <[email-masked]>
Date: Tue, 18 Feb 2014 16:47:31 +1100
List-Id: Crypto Forum Research Group <cfrg.irtf.org>

Authenticated Encryption with Additional Data (AEAD) is a great primitive for securing messages, but it has one serious limitation: you only learn that the plaintext is authentic after processing all of the ciphertext. A crypto library performing decryption either has to: 1) cache the whole message (of arbitrary size) before returning the authentic plaintext; or 2) return unauthenticated plaintext chunks, and indicate authenticity only later when (or if) the end of the message is reached.
Neither of these choices are ideal.

What is needed is a way to use an AEAD algorithm to secure a message in chunks. Streaming-AEAD would allow a recipient to know they have received an authentic prefix of a message. It would allow crypto APIs to support streaming modes while never returning unauthentic plaintext.

A discussion on this topic has started on the IETF TLS list (in a thread unhelpfully titled "Comments on")
http://www.ietf.org/mail-archive/web/tls/current/msg11282.html

I think this would be a perfect topic for CFRG to address.

Instead of sending C = AEAD(N, A, P);
send C = AEAD(N1, A1, P1) || AEAD(N2, A2, P2) || ... || AEAD(Nm, Am, Pm).
Presumably incrementing nonces can be used (eg N2 = N1 + 1).
How do you flag the end of the message: a flag in the nonce; a flag in the AAD; empty plaintext; inside a modified AEAD primitive?
How do you flag the start of the message?
Should the byte offset of each chunk be put in that chunk's AAD?
Is the real AAD fed to the first or last AEAD instantiation; or can parts be passed to any AEAD instantiation?

Should this be built from AEAD primitives? What about ones without nonces (eg draft-mcgrew-aead-aes-cbc-hmac-sha2)?
Is it sufficient for a Streaming-AEAD primitive to distinguish 4 modes (full message; 1st chunk; intermediate chunk; last chunk) plus a stipulation to use incrementing nonces for successive chunks?
Or should we aim for a Streaming-AEAD that can create extra intermediate authentication tags, without affecting the final tag?

As a strawman, what if OCB [draft-irtf-cfrg-ocb] was tweaked so the internal 128-bit Nonce field was changed from:
Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N
to:
Nonce = num2str((TAGLEN mod 128)/4,5) || num2str(FLAG,2) || zeros(120-bitlen(N)) || 1 || N
where
FLAG = 00 means the AEAD operation covers a full message,
FLAG = 01 means the AEAD operation covers the first chunk of a message,
FLAG = 10 means the AEAD operation covers a subsequent chunk of a message (incrementing N),
FLAG = 11 means the AEAD operation covers the last chunk of a message (incrementing N).

With 5 minutes analyses from a non-cryptanalyst that looks sufficient for a secure streaming-AEAD :)

--
James Manger

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Nikos Mavrogiannopoulos
Sent: Monday, 17 February 2014 7:10 PM
To: Adam Langley
Cc: Niels Möller; [email-masked]
Subject: Re: [TLS] Comments on

On Fri, 2014-02-14 at 14:49 -0500, Adam Langley wrote:

> > By streaming, I don't advocate you do the decryption in a pipe line;
> > that's clearly a dangerous habit. Usecase is more like on one machine
> > running
> >   src-machine$ tar -cf - foo-dir | aead-encrypt | send
> This use of streaming is fine by my criteria, assuming that
> "aead-encrypt" is chunking the input into different blocks and
> applying the AEAD to each block. This is perfectly fine with a
> one-shot(*), AEAD API at the core.

I'd pretty much agree with the chunked approach, but I now realize that
it is more hard to get it right than the streaming one. In the chunked
approach one would need to implement sequence numbers (could be implicit
as additional data) and a termination block. So both approaches have
quite some disadvantages. The streaming approach allows for misuse of
the API which may cancel the benefits of AEAD, and the chunked approach
requires the developer to create a safe protocol over AEAD.

If the idea is for AEAD to be used by an average developer, it seems we
need even a higher abstraction than that; even for such a simple
use-cases.

regards,
Nikos

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls