Hi Neal,
On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote:
Hi Werner,
[snip]
Can you please explain how to get ciphertext integrity when streaming?
To be clear: for me, truncation is an orthogonal issue; my primary
concern is how to ensure that no implementations ever release
plaintext derived from modified ciphertext.
With or without AEAD?
If you think that the current proposal achieves this, I've presented a
few critiques in <87mum6ekbd(_dot_)wl-neal(_at_)walfield(_dot_)org>
(https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U):
1. If messages can't be decrypted, because a chunk won't fit in
memory, but unauthenticated streaming would otherwise "work,"
implementors will do the latter, because security must not get in
the way of a user getting her job done.
2. If unauthenticated streaming is allowed or tacitly encouraged, it
will be done first, because the set of messages that
unauthenticated streaming can decrypt is a superset of those that
authenticated decryption can handle, and it will perhaps be done
exclusively because introducing a second code path that, modulo
security concerns, is functionally equivalent to the code path
for unauthenticated streaming is extra work, and extra
complexity, which developers will try to avoid.
3. If implementations revert to unauthenticated streaming for large
chunk sizes, an attacker can conduct an EFAIL-style attack by
changing the chunk size.
Which implementation? The sender or the receiver? Also, who is the
attacker? The Sender? Or a third party?
Note that the way I see Chunking + AEAD working together is that there is
a 1:1 mapping of Chunk to AEAD block. I realize this is probably a change
in the way it's currently working (and it's been 20 years since I wrote
the original chunking code), but I feel that AEAD and Chunking go
hand-in-hand. Specifically, I see chunking as a way to splice a bunch of
separate AEAD blocks together into a chain to ensure you don't drop or
reorder the AEAD chunks. The only attack is a DoS if the end is
truncated, and the earlier (valid) chunks have already been released.
In other words, AEAD is used for each chunked block as a single, coherent
piece. Also I don't see how an attacker (third party) could leverage this
at all. They couldn't change the chunk size enroute. Granted, if the
attacker is the sender they could do much worse things, so you just need
to ensure that, as you say, unauthenticated plaintext isn't released. But
that cannot happen given the context above. Each chunk is either
authenticated, or an error occurs. On error, it wouldn't be released.
Chunk sizes SHOULD be limited to ensure processing capability, which is
where this conversation started. Of course, this assumes chunked mode.
It should still be allowed to have a single AEAD "chunk" if the sender
wants to buffer the message.
Thanks!
:) Neal
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp