Re: [openpgp] AEAD Chunk Size

[Tobias Mueller <[e-mail]>]

Hi,

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.


> 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. And I think that RFC5116
leans more towards full messages rather than trying to define security
guarantees for partial plaintext.  I further think getting as close to
proper AE as possible is a goal worth pursuing.

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

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

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

Cheers,
  Tobi