Re: [openpgp] AEAD Chunk Size

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

On Mon, 18 Mar 2019 20:51:32 +0100,
Tobias Mueller wrote:
> On Mon, 2019-03-18 at 11:53 +0100, Neal H. Walfield wrote:
> > > 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. 
> I beg to differ. Because, as you mention:
> 
> >  RFC 5116 doesn't discuss chunking; chunking is not AEAD.
> > 
> Chunking is not AEAD. It's a protocol on top of AEAD messages that you
> have to come up with. And then you have to implement it correctly. The
> security guarantees that AEAD gives you, do not automatically apply to
> your chunking scheme.
> As you've said: Chunking is not AEAD. Hence, it cannot automatically be
> in line with what RFC5116 demands.

The chunks use AEAD.  So 5116 applies to the chunks.  That means, for
a given chunk, either authenticated plaintext is returned or failure.
I don't see a contradiction.

> > You seem to think that AEAD's guarantees must apply to the whole
> > message.  I disagree.  
> I'm glad you're saying this.
> And yes, I think that proper AE means that the full message enjoys the
> security guarantees of AE. Also because I am not aware of definitions
> covering partially authenticated plaintext.

TLS is used by a few billion people.  Let's just do what they do...

> And I think that RFC5116
> leans more towards full messages rather than trying to define security
> guarantees for partial plaintext.

RFC 5116 only talks about AEAD.  But these trade-offs are specifically
addressed by David McGrew, the author of 5116, here:

  https://mailarchive.ietf.org/arch/msg/cfrg/_iVbSmVLW7nY82k8xZmuVFIX6cs

  Fragmenting the plaintexts before applying AEAD requires that each
  AEAD message be independently authenticated, and thus this technique
  has more data/encapsulation overhead.

In his terminology, fragmentation is approximately the same as
chunking in our terminology.  It seems to me, the he says AEAD is
applied to fragments/chunks, not the whole message, which is the
terminology that I've been using.

The whole thread, starting here,
https://mailarchive.ietf.org/arch/msg/cfrg/-lj3IEm9agpfgUOb2yX9JNrtrm8
is an interesting read.  And, I think it generally supports my
position.


> I further think getting as close to
> proper AE as possible is a goal worth pursuing.

I think that if we accept your position, OpenPGP will have less
practical security.

You've repeatedly said that if an implementation doesn't want
authenticated plaintext, it is free to release unauthenticated
plaintext (e.g., "you are free to release unauthenticated plaintext as
much as you want",
[e-mail])
That's much, much worse than a possible truncation attack.  And, David
McGrew agrees:

  https://mailarchive.ietf.org/arch/msg/cfrg/_iVbSmVLW7nY82k8xZmuVFIX6cs

  robustness against decryption misuse is a valuable property for an
  AEAD algorithm to have.  Nonetheless, it would be better if the
  protocol using AEAD actually performed some sort of plaintext
  fragmentation, if it can accommodate the overhead, because the
  security would be better.

> > I agree it is useful, but it is not possible
> > when streaming.
> If you absolutely must stream, then there is no way that you can buffer
> the whole message, otherwise you wouldn't stream.  I claim, however,
> that in the vast majority of use-cases you don't have the requirement of
> having to stream.  As in, purely from a functional perspective, not from
> an implementation perspective.  Hence, imposing the concept of streaming
> onto everybody somehow does not feel right.

Let's consider email, which is a common use case for OpenPGP.  I like
that K-9 just downloads the first few kilobytes of each message.  I
want K-9 to be able to continue to do that even when everyone is
encrypting their email.  For that, I need an authenticated prefix.

Likewise, with a dropbox-like application, I'd like to be able to
preview the content.  Again, I need an authenticated prefix.

I want to be able to stream archives and backups.

Pretty much the only case that I can think of that chunking is not
useful is for verifying software updates.

> I'd like to note, though, that it is possible to not reveal the
> plaintext no matter how large the message is, though.  You can mask the
> output you release, e.g. XOR it or apply CTR mode, and provide the key
> to remove the mask only when the ciphertext has checked out correctly.

I don't see how that helps with streaming.  Basically any further
processing needs to wait until the whole message has been decrypted a
second time...

> From the proposal you made it seem you think we should not even try to
> provide a format for a non-streaming message.  Would you describe that
> as correct?

We should provide exactly one variant.  Additional variants must
justify their existence, and I don't see the huge value add for
"proper AEAD".  In fact, it seems dangerous as I think it will
encourage decryption misuse.

> > I think that even if we add a bit that says: "don't stream",
> > implementations will ignore it.
> Hm. I'd classify this as a wilful violation of the spec rather than an
> accident while implementing it.
> Once you assume that implementations are doing things wilfully wrongly,
> it gets messy.
> I mean... where do we stop making compromises in the security of the
> spec because we believe someone will wilfully ignore the spec? We rely
> on the client not actively misinterpreting the spec. Like.. not making
> secret key material available.

It's a simple question of: "can I use the software to get my work
done"?  If the security is in the way, then the security will be
disabled.  "Proper AEAD" will be in the way often enough that it will
get disabled, and decrease the security of the whole system.

Sorry,

Neal