Subject: Re: [openpgp] AEAD mode unverified chunks

From: Marcus Brinkmann <[email-masked]>
Date: Sun, 1 Jul 2018 15:39:03 +0200

On 07/01/2018 08:53 AM, Peter Gutmann wrote:
> Marcus Brinkmann <marcus.brinkmann=[email-masked]> writes:
> 
>> If a chunk can not be authenticated, implementations MUST discard the
>> plaintext without further processing.  Unauthenticated plaintext MUST not be
>> output to other applications or the user.
> 
> Unfortunately it's nowhere near as simple as that, in general, this is an
> unsolveable problem.  See:
> 
> https://tools.ietf.org/html/rfc6476#section-6
> 
> for a discussion.

Maybe the above wording was not clear. The plaintext in question refers
to that of a single chunk.  Here is another suggestion for a specific text:

  If a chunk can not be authenticated, implementations MUST discard the
  plaintext of that chunk without further processing, and stop
  processing the message with an error.  Unauthenticated
  plaintext MUST NOT be output to other applications or the user.
  Truncated, authenticated plaintext MAY be output, if the truncation is
  reported as an error to the application or the user after the fact.

In case of truncation, it is true that the (authenticated) beginning of
the whole message might have been output to applications or users. That
is strictly (and vastly) better than outputting tampered plaintext for
any particular chunk.  Truncated plaintext can still be detected and the
error can be indicated after the fact.

Aborting an ongoing operation is a failure case that application
developers and users are familiar with. It happens all the time, for
many reasons (for example, lack of disk space or out of memory
conditions, or any number of simple bugs when processing the data). It
is unsurprising, and it can be dealt with at the application and user side.

Tampered plaintext can be dangerous in many surprising and compromising
ways, as the EFAIL researchers have shown. It is not a failure case that
users or application developers are familiar with. They should not have
to deal with it.

If an impossible problem is easily separable in a solvable problem that
achieves 99% of the goals, and an impossible problem for the remaining
1%, that's a resounding success.

Thanks,
Marcus

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 1 Jul 2018 13:55:30 +0000

Marcus Brinkmann <marcus.brinkmann=[email-masked]> writes:

>  plaintext of that chunk without further processing

But that then requires the artificial chunk-size restriction you mentioned in
an earlier message, which also means you'll start expanding messages if you
have to break them up into smallish chunks with IVs and MACs and whatnot in
each chunk...

Hmmm, and a comment on the text:

"A new random initialization vector MUST be used for each message".

That should be "for each chunk", along with a strong warning about the fact
that you'll get a catastrophic failure of security if you don't do this and
use a highly brittle AEAD mode like GCM.  That is, this isn't just some nice
thing to do like the usual comment about using fresh IVs, you'll get a
catastrophic security failure if you don't, far more so than with any other
encryption mode that uses IVs.

Peter.

---

From: Marcus Brinkmann <[email-masked]>
Date: Sun, 1 Jul 2018 17:14:03 +0200

> encryption mode that uses IVs.

My reading is that the nonces for individual chunks are derived from the
message IV by XORing an index number. See the subsections on EAX and OCB
that follow.

Thank you for taking a look at the AEAD part of the specs.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Jul 2018 12:17:40 -0500

> have to break them up into smallish chunks with IVs and MACs and whatnot in

Aren't we talking about a greenfield new proposal that can in fact mandate
such chunk-size restrictions?

-Ben

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 2 Jul 2018 03:03:22 +0000

Marcus Brinkmann <marcus.brinkmann=[email-masked]> writes:

>message IV by XORing an index number. See the subsections on EAX and OCB that
>follow.

Sure, however if in the future someone adds another AEAD mode, and in
particular the very fashionable (in fact I'm surprised it isn't already in
there) but also very brittle GCM, then safe IV handling is criticial to
security.  It's just a personal preference, but I'd add a somewhat stronger
warning to the text in 5.16 for per-chunk unique/random IVs and the
consequences of not using them when some AEAD modes are used.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Mon, 23 Jul 2018 16:22:38 +0200

> consequences of not using them when some AEAD modes are used.

What about this:

  A new random initialization vector MUST be used for each message.
  Failure to do so for each message will lead to a catastrophic failure
  depending on the used AEAD mode.

Or propose a different text.

Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 24 Jul 2018 07:18:34 +0000

>  depending on the used AEAD mode.

Sounds good.

Peter.