Re: [TLS] Comments on

Adam Langley <agl@google.com> Fri, 14 February 2014 19:51 UTC

MIME-Version: 1.0
In-Reply-To: <nnsirlldyf.fsf@bacon.lysator.liu.se>
References: <nnha83nwy9.fsf@bacon.lysator.liu.se> <CAL9PXLyWhqSdG5YRyrOprW5wgCYCwHn7_a=R2sb+mN-irkMYbA@mail.gmail.com> <nna9dum6fk.fsf@bacon.lysator.liu.se> <CAL9PXLyC98rc73x7o4gDeu-UBz1k0VP_qTdbCqgSSObuKf9+LA@mail.gmail.com> <nnsirlldyf.fsf@bacon.lysator.liu.se>
From: Adam Langley <agl@google.com>
Date: Fri, 14 Feb 2014 14:49:38 -0500
Message-ID: <CAL9PXLzgHqguYfKwhiVyjDeSCUkqwbsoujAcz8UPN0FQyfaodg@mail.gmail.com>
To: Niels Möller <nisse@lysator.liu.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ULJbYdCDaycBGBUI_hye3SSo2ok
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments on
Precedence: list

On Fri, Feb 14, 2014 at 1:57 PM, Niels Möller <nisse@lysator.liu.se> wrote:
> Right, with some care both views these input words could perhaps
> coexist. And a 32-bit counter (256 GB message size, if I manage to get
> the powers right) ought to be sufficient for almost all applications.
> But I'm afraid it might to slow adoption of chacha if there are multiple
> slightly incompatible specifications.

I intend for the 64/64 bit version to be dead at this point. I think
everyone can agree on the 96/32 split. I wouldn't want there to be two
versions if it can be avoided.

> 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.

> If I want to encrypt a large file (say, with key derived from a
> passphrase, or with an random and RSA-encrypted session key), I see no
> clearly better or easier way to do that than as a single large AEAD
> message processed using a streaming/incremental API. Sure, I could
> divide the data into reasonably sized shorter blocks and process each
> block as a separate message with AEAD, but then I would have to think
> about how to do sequence numbers and a properly authenticated EOF
> indication, to prevent reorder and truncation. And to me, that's also
> very much against the spirit of AEAD as a safe and easy-to-use
> mechanism.

I disagree here and this seems to contradict your statement above that
decryption in a pipeline is a "dangerous habit". Wouldn't your
streaming/incremental API return unauthenticated plaintext to the
caller and thus encourage just this habit?

Certainly I have much sympathy with the problem of giving the user a
simple API for dealing with large files. However, I think such an API
should, under the covers, chunk the data and apply an AEAD to each
chunk. That design can avoid holding large amounts of plaintext or
ciphertext in memory and also avoid returning unauthenticated
plaintext.

There is still the need to handle unexpected truncation, but I think
that's fundamental when one cannot hold the whole file in memory at
once.

So I think that what you want is an "AEAD chunking format" which is a
higher level concept than an AEAD and that our disagreement arises
from merging what I see as two different layers.

(*) by one-shot I mean that it does the whole operation in one call. I.e.:

ssize_t EVP_AEAD_CTX_seal(const EVP_AEAD_CTX *ctx,
                         unsigned char *out, size_t max_out_len,
                         const unsigned char *nonce, size_t nonce_len,
                         const unsigned char *in, size_t in_len,
                         const unsigned char *ad, size_t ad_len);

Cheers

AGL

Re: [TLS] Comments on Adam Langley
Re: [TLS] Comments on Wan-Teh Chang
[TLS] Comments on Niels Möller
Re: [TLS] Comments on Niels Möller
Re: [TLS] Comments on Dr Stephen Henson
Re: [TLS] Comments on Adam Langley
Re: [TLS] Comments on Niels Möller
Re: [TLS] Comments on Adam Langley
Re: [TLS] Comments on Niels Möller
Re: [TLS] Comments on Adam Langley
Re: [TLS] Comments on Nikos Mavrogiannopoulos
Re: [TLS] Comments on Watson Ladd
Re: [TLS] Comments on Adam Langley
Re: [TLS] Comments on Adam Langley
Re: [TLS] Comments on Watson Ladd
Re: [TLS] Comments on Bill Frantz
Re: [TLS] Comments on Watson Ladd
Re: [TLS] Comments on Bill Frantz
Re: [TLS] Comments on Alfredo Pironti
Re: [TLS] Comments on Niels Möller
[TLS] dealing with AEAD partial delivery [was: Re… Daniel Kahn Gillmor
Re: [TLS] Comments on Bill Frantz
Re: [TLS] Comments on draft-nir-cfrg-chacha20-pol… Niels Möller
Re: [TLS] Comments on draft-nir-cfrg-chacha20-pol… Adam Langley
Re: [TLS] Comments on draft-nir-cfrg-chacha20-pol… Niels Möller
Re: [TLS] Comments on draft-nir-cfrg-chacha20-pol… Niels Möller
Re: [TLS] Comments on draft-nir-cfrg-chacha20-pol… Adam Langley
Re: [TLS] Comments on draft-nir-cfrg-chacha20-pol… Niels Möller