Re: [openpgp] Replacing the OpenPGP Encryption Mode is Harmful and Pointless

[Bruce Walzer <[e-mail]>]

On Fri, Jul 15, 2022 at 12:15:51PM +0000, Daniel Huigens wrote:
[...]

> If the check is there, there's no reason to do the attack, and thus
> the error should only show up if there's some bug, which should be
> caught quickly thanks to the check. So I think that errors being bad
> UX is not a sufficient argument not to have the check (you also have
> to somehow argue why the errors would show up at all).

If the error is in the spec, then I, as the application programmer,
have to deal with it somehow. So I can't get around having to decide
what to provide the user instead of the message they are expecting.

> Then, if you (somewhat) agree with that, I want to bring up a practical
> advantage of the new scheme: it breaks up messages into chunks, which
> can be checked and released to the application individually, instead of
> having to wait for the MDC at the end of the message.

Why would the application programmer perfer having to dechunk the
message?

> > approach based on, you know, authenticity?
> 
> EFAIL is an attack against confidentiality, not just authenticity.

I don't understand how this relates to anything I said in the article.

> That's why it should be fixed at the encryption layer, imo. You might
> also not have the public key of the sender, and requiring that just to

I was not suggesting that anonymous/unsigned messages should be
withheld, only modified.

> Then, you might still ask, why use AEAD instead of OCFB-MDC.
> A proper AEAD scheme integrates confidentiality and integrity, which
> makes providing both more efficient and more secure.

Are we implying here that OCFB-MDC is inefficient? I don't know how
you can get more secure than secure.

> If you want proof
> of that, you should ask a cryptographer instead of me, but a security
> proof is typically included with the paper of any good AEAD scheme.

A proof that depends on a set of assumptions. So all that means is
that to break the scheme you defy the assumptions. For example, if you
assume that your MAC check is invulnerable to attack then you can make
a scheme that entirely depends on the MAC that is also invulnerable
under that assumption.

> A security proof for OCFB-MDC doesn't exist, as far as I know, and
> it's doubtful whether it's possible to provide one, which in itself
> should be worrying, even if nobody has been able to come up with a
> practical attack (so far).

What is the purpose of the security proof in the first place? I would
suggest it is intended to produce schemes that will go a long time
before someone figures out how to break them. If someone could
magically claim that a particular theoretical approach would guarantee
perfect security for 20 years then I think it would be agreed that
that approach was a very good one. OCFB-MDC has already run out that
much time. At some point experience has to trump analysis. If 20 years
is not enough then how long would it take?

Bruce