[Cfrg] Streaming AEAD

"Manger, James" <James.H.Manger@team.telstra.com> Tue, 18 February 2014 05:47 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1CD1A0355 for <cfrg@ietfa.amsl.com>; Mon, 17 Feb 2014 21:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.298
X-Spam-Level: ***
X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, MANGLED_PILL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ3_19xsQpov for <cfrg@ietfa.amsl.com>; Mon, 17 Feb 2014 21:47:37 -0800 (PST)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id DDAB21A00D3 for <cfrg@irtf.org>; Mon, 17 Feb 2014 21:47:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.97,500,1389704400"; d="scan'208";a="173519144"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 18 Feb 2014 16:47:32 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7352"; a="198827981"
Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbni.tcif.telstra.com.au with ESMTP; 18 Feb 2014 16:47:33 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Tue, 18 Feb 2014 16:47:32 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Date: Tue, 18 Feb 2014 16:47:31 +1100
Thread-Topic: Streaming AEAD
Thread-Index: Ac8rt7QH65PxH4WESVOE1QZgNXN9agAohMPQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1153B5ED749@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/-lj3IEm9agpfgUOb2yX9JNrtrm8
Cc: Adam Langley <agl@imperialviolet.org>, Niels Möller <nisse@lysator.liu.se>
Subject: [Cfrg] Streaming AEAD
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 05:47:40 -0000

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:tls-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos
Sent: Monday, 17 February 2014 7:10 PM
To: Adam Langley
Cc: Niels Möller; tls@ietf.org
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls