Re: [TLS] Comments on

[[e-mail] (Niels Möller )]

Adam Langley <[e-mail]> writes:

> It appears that IPSec wants the extra 32 bits of nonce. Although this
> is an important change in definition it doesn't actually change the
> wire-format for TLS because the record-length limit means that those
> bits are always zero anyway in both cases.

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.

And my current focus is more on what the chacha programming interface
should look like, not wire format of any particular protocol.

> Keep in mind that it affects more than just your users. By making
> streaming designs easy you allow people to make bad designs (like CMS)
> that force streaming designs on others in order to handle large files.
> The point of AEADs is that it's an easier primitive to use.

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

to send the encrypted data over some untrusted link. And on the
receiving side 

  target-machine$ recv | aead-decrypt -o foo.tar

The point of the "streaming" here is that there's no need to store any
copy of plaintext or cryptotext at the source, and at the receiver, at
least there's no need to store a copy of the ciphertext. (And with some
more care, and a paranoid enough tar program, it's even possibly to
safely extract the received tar file in a pipe, avoiding storing a copy
of the tar file, *if* one arranges to handle the aead-decrypt exit code
properly).

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.

> However, my preference would be to leave it as is because I've already
> got code that does it that way

I'm afraid that's the answer that I expected...

> and I don't believe that streaming is something that should be made
> easy.

We'll probably just have to disagree on that.

>> I see. Vaguely related question: Do you see any need for 128-bit chacha
>> keys?
>
> Since they are no faster I don't believe that anyone will want to
> support them. However, I may be wrong about that.

Thanks. (I currently do support them in my development version, but I'm
considering removing that feature, for simplicity, before release).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.