Re: [openpgp] AEAD Chunk Size

["Derek Atkins" <[e-mail]>]

Hi Neal,

On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote:
> Hi Werner,
>
[snip]
> Can you please explain how to get ciphertext integrity when streaming?
>
> To be clear: for me, truncation is an orthogonal issue; my primary
> concern is how to ensure that no implementations ever release
> plaintext derived from modified ciphertext.

With or without AEAD?

> If you think that the current proposal achieves this, I've presented a
> few critiques in <[e-mail]>
> (https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U):
>
>   1. If messages can't be decrypted, because a chunk won't fit in
>      memory, but unauthenticated streaming would otherwise "work,"
>      implementors will do the latter, because security must not get in
>      the way of a user getting her job done.
>
>   2. If unauthenticated streaming is allowed or tacitly encouraged, it
>      will be done first, because the set of messages that
>      unauthenticated streaming can decrypt is a superset of those that
>      authenticated decryption can handle, and it will perhaps be done
>      exclusively because introducing a second code path that, modulo
>      security concerns, is functionally equivalent to the code path
>      for unauthenticated streaming is extra work, and extra
>      complexity, which developers will try to avoid.
>
>   3. If implementations revert to unauthenticated streaming for large
>      chunk sizes, an attacker can conduct an EFAIL-style attack by
>      changing the chunk size.

Which implementation?  The sender or the receiver?  Also, who is the
attacker?  The Sender?  Or a third party?

Note that the way I see Chunking + AEAD working together is that there is
a 1:1 mapping of Chunk to AEAD block.  I realize this is probably a change
in the way it's currently working (and it's been 20 years since I wrote
the original chunking code), but I feel that AEAD and Chunking go
hand-in-hand.  Specifically, I see chunking as a way to splice a bunch of
separate AEAD blocks together into a chain to ensure you don't drop or
reorder the AEAD chunks.  The only attack is a DoS if the end is
truncated, and the earlier (valid) chunks have already been released.

In other words, AEAD is used for each chunked block as a single, coherent
piece.  Also I don't see how an attacker (third party) could leverage this
at all.  They couldn't change the chunk size enroute.  Granted, if the
attacker is the sender they could do much worse things, so you just need
to ensure that, as you say, unauthenticated plaintext isn't released.  But
that cannot happen given the context above.  Each chunk is either
authenticated, or an error occurs.  On error, it wouldn't be released.

Chunk sizes SHOULD be limited to ensure processing capability, which is
where this conversation started.  Of course, this assumes chunked mode. 
It should still be allowed to have a single AEAD "chunk" if the sender
wants to buffer the message.

> Thanks!
>
> :) Neal

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant