Re: [openpgp] [EXT] Re: AEAD Chunk Size

[Neil Hunsperger <[e-mail]>]

> From: openpgp <[e-mail]> On Behalf Of Werner Koch
> Sent: Tuesday, April 23, 2019 1:11 AM
> I am not sure about the context.  Are you talking about the partial length encoding or about the AEAD chunk size, a modification of AEAD to allow detection of transmission errors before the end of the data?

Is the disconnect between Werner and many of those replying just whether it's meaningful to have 3 security levels instead of 2?

Level 1: The receiver verified the signature computed over all the data. The data is from Alice.
Level 2: The receiver verified AEAD chunks but not the signature. The data is a prefix of data sent by someone who had the decryption key to that data.
Level 3: The receiver verified neither AEAD chunks nor the signature. The data could be from anyone. It could be from your friend Alice, but modified by Eve in a way that compromises its confidentiality.

If one's threat model lumps levels #2 and #3 into one "untrusted" bucket, then AEAD is purely a convenience mechanism.

If one's threat model aims to protect downstream code that is robust against RCE attacks but weak against information disclosure attacks, then AEAD chunks provide measurable security.

> For all other purposes I propose to use a different protocol on top of OpenPGP a (e.g MIME) and not to overload OpenPGP with unneeded stuff.

I think we can let people rely on OpenPGP to differentiate above levels #2 and #3 without making the OpenPGP protocol any more complicated. The maximum size for chunks just needs to be "small-ish": the value this thread was trying to define.

-Neil

Aside: An even safer way to use AEAD would be to sign something derived from the decryption key and place that signature before the AEAD Encrypted Data Packet. Thus when a library streams out checked AEAD chunks, those chunks are known to be prefixes of a message that Alice sent. This is the strongest security guarantee possible with a pure streaming interface. I think it would only be useful in an environment where unsigned data is always rejected. And this would complicate the spec!