Re: [TLS] Comments on

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

Adam Langley <[e-mail]> writes:

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

The proper way is to process the file incrementally (with bounded RAM),
write the result to a temporary file on disk (preferably hidden, if
supported by the OS). At the end of data, check authentication, and
either rename the file and advertise it, or delete it and return a
failure exit code.

And I think this is the right way to do it no matter of you use plain
AEAD or some "AEAD chunking format" (more on truncation below).

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

Under the assumption that processing of a truncated version or "prefix"
of the authenticated file is somehow safe, an AEAD chunking format has
an advantage over plain AEAD, in that it can provide prefixes of the
authenticated file early.

But in the case that you really want proper authentication of the
*complete* file before you start processing it, I think an AEAD chunking
format is additional complexity with no benefit over plain AEAD, since
plain AEAD provides exactly the type of autentication needed.

I'd prefer not assume that prefixes are safe. I don't have any very
concrete example, but I think that in general handling a truncated file
should be considered dangerous. As one example, I think pdf files have
some kind of master index at the end, and also some possibility to edit
earlier contents by appending data and a new index at the end (intended
for adding notes on top of a signed pdf, iirc).

> (*) 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);

I intend to provide an interface like that in the Nettle library; the
streaming/incremental interface will not be the only one. And I expect
that the one-shot functions will be the right choice for most
applications.

But since the one-shot functions will be implemented on top of the
lower-level incremental interface I described earlier, any additional
complexity there is relevant also for applications exlusively using the
one-shot interface.

Regards,
/Niels

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