ietf-openpgp
[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size

2019-03-18 05:54:10
Hi Tobias,

On Sun, 17 Mar 2019 21:00:51 +0100,
Tobias Mueller wrote:
On Fri, 2019-03-15 at 12:40 +0100, Neal H. Walfield wrote:
I'm currently convinced that streaming authenticated plaintext is only
possible if we use small chunk sizes.  If we allow large chunk sizes
(e.g., 4 exabytes, which is what the current draft allows), then there
will be cases where an implementation can stream unauthenticated
plaintext, but not authenticated data, and, because it can, it will.
And this is even though pretty much everyone including the IETF (see
RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext.

  [1] https://tools.ietf.org/html/rfc5116#section-2.2
Maybe we're hitting a terminology issue here.

I think we do.

For me, a plaintext is authenticated if the whole ciphertext could be
successfully authenticated. Which seems to be very well in line with the
definition you've linked to.

4880bis defines a chunking mechanism based on AEAD: the message is
split into multiple chunks.  In 4880bis, AEAD operates on a per-chunk
basis.  The chunking algorithm provides mechanisms for ensuring chunks
can't be reordered, detecting the end of the message, etc.  Using AEAD
to decrypt a chunk authenticates that chunk's ciphertext; for a given
chunk, the decryption operation will either return the correct
plaintext, or it will return an error.  This is exactly what RFC 5116
requires.  RFC 5116 doesn't discuss chunking; chunking is not AEAD.

The chunking mechanism in 4880bis (assuming implementors follow RFC
5116 with respect to AEAD on chunks) ensures that plaintext is only
released from authenticated ciphertext.  It does not protect against
truncation attacks.  Since OpenPGP decided to support streaming in RFC
2440 (which introduced One Pass Signature packets), this is inline
with OpenPGP's philosophy.  I don't think removing support for
streaming is useful.


You seem to think that AEAD's guarantees must apply to the whole
message.  I disagree.  I agree it is useful, but it is not possible
when streaming.

I think that even if we add a bit that says: "don't stream",
implementations will ignore it.  Moreover an attacker can just clear
it, and then the receiver streams it anyways.


Now, if you modify a (long) ciphertext that has been broken into chunks
near the end and a decryption routine reveals the first parts of the
decrypted ciphertext, would you agree that revealing those parts of the
plaintext does not meet the definition that you've linked to?

No.  AEAD is applied to chunks.

And do you further agree that you would need to find a way to prevent
any plaintext to be revealed unless the full message has been
authenticated correctly in order to match the definition that you've
mentioned?

No.  AEAD is applied to chunks.  When a chunk is decrypted, it either
returns authenticated plaintext, or an error.



Referring to 
<734216a3ee1c0e252ecf0ad297be2cfdcb049c2e(_dot_)camel(_at_)cryptobitch(_dot_)de>
On Sun, 17 Mar 2019 21:01:32 +0100,
Tobias Mueller wrote:
On Thu, 2019-03-07 at 18:09 +0100, Neal H. Walfield wrote:
You're afraid of bugs.  So am I.  Dynamically resizing buffers is
error prone.  Even computing AEAD's chunk size is hard:
point taken. Programming is hard. Programming C is even harder. Tooling
could be improved. We ought to write a spec that achieves a security
goal while making it less likely that people implement the spec wrongly.

I agree.  Less flexibility in the spec is better, which is what I
want.

You rightly argue, I think, that AEAD without chunking is easier to
implement.  But, OpenPGP supports streaming, which is incompatible
with AEAD without chunking.  Consequently, streaming using AEAD
without chunking means releasing unauthenticated (as I have defined it
above) plaintext.

Releasing unauthenticated plaintext is much worse than releasing only
an authenticated prefix.  Releasing unauthenticated plaintext allows
for an EFAIL style attack; releasing an authenticated prefix does not.
Releasing an authenticated prefix prevents ciphertext malleability.

You've made a point but you haven't really taken a stance on the point
that I raised. Which boils down to your proposal forcing everybody to
use chunking which in turn can be implemented wrongly while providing no
benefit in return.

Only releasing plaintext from authenticated chunks prevents
EFAIL-style attacks.  That is not no benefit, that is not a little
benefit, that is a huge benefit.

I believe that the potential for releasing plaintext although the
ciphertext has not been authenticated is higher if I need to call that
oracle multiple times, invent a secure scheme for detecting truncation,
and implement that scheme correctly.

I agree that the added complexity that chunking imposes is not worth
it *if* the only reason to introduce chunking is to detect
transmission errors early.  But, it is not.  It prevents modifications
to the ciphertext.

Your proposal removes the option for the message producer to decide
whether it wants to have the recipient (which may very well be the same
entity) rely on an implementation which gets all that right. Because
with the status quo, one can opt for producing one chunk which is
trivially protected against truncation and other attacks.

You say that it is trivially protected, but this is not the case,
because exactly in those cases implementors will just stream
unauthenticated data.  They should only be able to stream data from
authenticated chunks.

Unless I understand your proposal wrong. But then my question is, how
would I encode a message that is not susceptible to (at least)
truncation attacks? Again, assuming the above mentioned oracle.

OpenPGP allows streaming.  The implementation doesn't provide a
mechanism to prevent streaming.  I'm not sure it would be a good idea
to provide one, as I don't think there is a sensible way for the
sender to decide when to set that bit.

I don't fully understand why you are mentioning dynamically resizing
buffers. Strictly speaking, you need space for a single digit number of
blocks (!) to decrypt an EAX or OCB message.

The size of the message is not known apriori if partial body length
encoding is used.  Even an upper bound is not known if compression is
used.

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>