Re: [openpgp] AEAD Chunk Size

["Neal H. Walfield" <[e-mail]>]

On Mon, 18 Mar 2019 14:57:37 +0100,
Derek Atkins wrote:
> On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote:
> > Hi Werner,
> > 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?

Well, whatever :).  As I understand Werner, he agrees that ciphertext
integrity while streaming is desirable, and, I guess, thinks that is
achievable with the current draft.  I don't think it is possible, and
I've raised a few concerns in my prior mails.  I hope Werner can
address those concerns.

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

I'm assuming that the sender is using the best we have to offer, i.e.,
chunked AEAD.

I'm assuming that the receiver emits unauthenticated plaintext in some
situations.

> Also, who is the
> attacker?  The Sender?  Or a third party?

I'm thinking of something like EFAIL.  So, a third-party attacker who
modifies the ciphertext.


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

I hacked Sequoia to emit unauthenticated data, and I was able to
change the chunk size and still get the plaintext of at least the
first chunk of a message.  So, my concern is: if a receiving
implementation releases unauthenticated plaintext for large chunks
rather than fail with ENOMEM, then a third-party attacker can change
the chunk size of an intercepted message, and cause the receiver to
process unauthenticated data, even though a small chunk size was
originally used.

> Each chunk is either
> authenticated, or an error occurs.  On error, it wouldn't be released.

The question for me is: what does an implementation do if it can't
buffer the message?  Does it really throw an error?  There already
exists at least one implementation written by an editor listed on
4880bis that processes unauthenticated plaintext.