Hi Sebastian,
On Mon, 2019-03-04 at 09:49 +0100, Sebastian Schinzel wrote:
Your reasoning regarding proper AE is correct, but you are drawing the
wrong conclusions. You want small chunks to do proper AE!
Can you mention what definition of AE you are referring to?
I guess you meant to add that you will need to come up with a secure
scheme to identify the last chunk and implement that properly. And that
you then you will need to buffer all the plaintext until the final chunk
has successfully checked out. Because otherwise you wouldn't get
"proper" AE as in either releasing plaintext or an error.
The advantage of smaller
chunks is that the plaintext can be cached until the chunk's auth tag
is validated. That's to guarantee that no unauthenticated plaintext is
released. (Leaving truncation aside.)
Two things: Firstly, you write "can be cached" rather than "must be
cached".
Unless you relax the security goals of the AEAD protected message.
Secondly, you can release unauthenticated plaintext of an AEAD protected
message of arbitrary size if you don't want to hold all the plaintext of
a decrypted ciphertext. Regardless of the size of the message or chunk.
Hence, there is no advantage of using a small chunk size if you want to
have an AEAD protected message. As in, if you intend to have proper AE
which only releases the full plaintext or an error.
Unless you need the concept of partially authenticated plaintext, the
only reason for using chunks is to detect failures early in the
decryption process rather than at the end. Again, if don't you want your
full message to enjoy the protections AE gives you, then you may be able
to afford partially authenticated messages. I haven't seen anybody
presenting a use-case for those. And even then it seems far fetched to
impose that concept onto each and every OpenPGP user as the current
proposal does.
Cheers,
Tobi
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp