Re: [openpgp] AEAD Chunk Size

[Derek Atkins <[e-mail]>]

Neal,

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

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

I admit that I have not studied the current draft closely, so my
comments might be out of whack, but my expectation is that the AEAD and
Chunking are done hand-in-hand.  The chunk metadata (number/size/etc)
should be protected by the AEAD.

So let's say you have a message that gets processed as:

[Chunk 1] [Chunk 2] [Chunk 3/final]

In the normal case, the receiver will process Chunk 1, then Chunk 2, and
then Chunk 3, and depending on the implementation MAY emit the Chunk 1
plaintext (which HAS BEEN AUTHENTICATED) before it processes Chunk 2
and/or Chunk 3.

What can an attacker do?

* If they modify the chunk size, the AEAD on that chunk will fail and
  therefore the data should not be emitted.  Note that this COULD cause
  the receiver to emit Chunk 1 and then "stop".

* If they cause Chunk 3 to disappear, they could get the receiver to emit
  Chunks 1 and 2 and then stop with.  But again, Chunk1 and Chunk2 are
  still authenticated.

* If they cause Chunk 2 to disappear, the numbering will be out of order
  and the receiver can emit an error.

* They can insert fake chunks.  Let's say they cause the following:
  [Chunk 1] [Chunk 2'] [Chunk 2] [Chunk 3'] [Chink 3/final]

  In this case, the attacker is inserting Chunk 2' and Chunk 3',
  claiming to be chunks 2 and 3 respectively.  So the question is, what
  happens here?  Well, the chunking here is expecting encryption (at
  least I think it should be expecting encryption).  So they would
  authenticate Chunk 1 (and possibly emit it), but when processing Chunk
  2' they would fail on the AEAD because the attacker doesn't know the
  key.

  The chunking should not allow any other type of data here.

Am I missing another attack?

[snip]
>> 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.

In what situations would the receiver emit unauthenticated plaintext?

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

EFAIL was more that that -- it was also leveraging the fact that USERS
of OpenPGP would merge the contents of authenticated and
non-authenticated data when presented in e.g. a MIME context, such that
the processor could not differentiate between the protected and
unprotected content.

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

Sure, but the first chunk of the message was authenticated when it was
emitted.  The SECOND chunk failed, and I bet it stopped processing!

This is what SHOULD happen.

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

I think we have different definitions of unauthenticated plaintext here.

In a chunked message, plaintext is authenticated PER CHUNK.  So once
Chunk 1 is processed, it is considered authenticated, and the
implementation is free to emit it, even if Chunk 2 fails.

If Chunk 2 fails its AEAD check (but Chunk 1 processed successfully), do
you consider the plaintext of Chunk 1 unauthenticated?  If so, why?

-derek

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