On Mon, 18 Mar 2019 14:57:37 +0100,
Derek Atkins wrote:
On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote:
Hi Werner,
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?
Well, whatever :). As I understand Werner, he agrees that ciphertext
integrity while streaming is desirable, and, I guess, thinks that is
achievable with the current draft. I don't think it is possible, and
I've raised a few concerns in my prior mails. I hope Werner can
address those concerns.
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?
I'm assuming that the sender is using the best we have to offer, i.e.,
chunked AEAD.
I'm assuming that the receiver emits unauthenticated plaintext in some
situations.
Also, who is the
attacker? The Sender? Or a third party?
I'm thinking of something like EFAIL. So, a third-party attacker who
modifies the ciphertext.
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.
I hacked Sequoia to emit unauthenticated data, and I was able to
change the chunk size and still get the plaintext of at least the
first chunk of a message. So, my concern is: if a receiving
implementation releases unauthenticated plaintext for large chunks
rather than fail with ENOMEM, then a third-party attacker can change
the chunk size of an intercepted message, and cause the receiver to
process unauthenticated data, even though a small chunk size was
originally used.
Each chunk is either
authenticated, or an error occurs. On error, it wouldn't be released.
The question for me is: what does an implementation do if it can't
buffer the message? Does it really throw an error? There already
exists at least one implementation written by an editor listed on
4880bis that processes unauthenticated plaintext.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp