Re: [openpgp] OpenPGP encryption block modes

["brian m. carlson" <[e-mail]>]

On 2022-08-12 at 16:20:07, Bruce Walzer wrote:
> On Wed, Aug 10, 2022 at 09:50:03PM +0000, brian m. carlson wrote:
> [...]
> > > That raises a question for me as I hold the position that OpenPGP does
> > > not need any more block cipher modes. I had the impression that
> > > SEIP-MDC (OCFB-MDC) would be relatively fast as the slow part is
> > > SHA1. SHA1 is one of the faster cryptographic hashes and is hardware
> > > accelerated on common platforms. I assumed that the slowness was
> > > because no one had ever bothered to optimize things. Is this true?
> > 
> > SHA-1 is no longer considered secure, and thus we can't assume that a
> > SHA-1 hash of the data intrinsically indicates that it hasn't been
> > changed.
> 
> I don't think this is correct as stated for normal OpenPGP usage. SHA1
> is only broken for collisions. The best an attacker can do is
> create two messages that when hashed with SHA1 will come out to the
> same value. So SHA1 does in fact prevent an entity other than the
> originator from making an undetected change. Fortunately this
> distinction is entirely irrelevant for SHA1 use in OCFB-MDC. The hash
> used only requires the property of irreversibility.

Yes, it's true that SHA-1 is only broken for collisions.  However, if
Mallory can send messages to Alice, who inspects them and then sends
them to Bob encrypted, then we still wouldn't want Mallory to be able to
modify the message after Alice had inspected it.  Perhaps Alice only
allows things looking like valid purchase orders to be sent, but Mallory
has a collision that turns the document into something else.

Now, with CFB and SHA-1, we don't presently think that Mallory can
modify both the message and the hash in this way, but CFB is vulnerable
to modification in predictable ways, and using SHA-1 for this leads us
to rely on the fact that Mallory cannot modify the CFB-encrypted
plaintext in a way that also converts the message into the other half of
a collision.

This is not a good assumption to make, and using SHA-1 in a modern
algorithm is to be avoided.  We absolutely do not want to make the
assumption that users will only be sending messages that are completely
trusted or which are not of a special form.  We also have to consider
the fact that in some organizations, SHA-1 cannot be used at all for
compliance or audit reasons and thus the entire approach is
unacceptable.

Peter mentioned SHA-1 with HMAC as well.  It's known that typically HMAC
relies on different assumptions than collision resistance.  However,
we've also tended to find that HMAC is vulnerable to distinguishing
attacks with MD4, MD5, SHA-0, and HAVAL, all of which have collisions.
Thus, a reasonable person might consider that HMAC-SHA-1 is not a great
idea, either.

It is much better when designing cryptosystems to use primitives that
are unambiguously secure, since attacks only get better.  OCFB-SHA-1 may
in fact end up being completely unbreakable, but it poses practical
problems and we have an opportunity to use options which are faster,
parallelizable, provably secure, and meet compliance and audit
requirements.  I also just don't want to design a system that uses
broken crypto, even if it happens to be secure, because explaining why
doing this is not presently a security problem again and again to
customers, security teams, and auditors is extremely tedious and boring
and I'd rather be doing more interesting things.

> I would be interested in a reference. It would be helpful here to know
> how well the workaround actually works in practice. Such a workaround
> is not required for OCFB-MDC as it is completely secure using regular
> SHA1.

The discussion of SHA-1-DC has happened earlier on the list, and I refer
you to the archives.  I believe Sequoia was the implementation thinking
about using SHA-1-DC, but I don't recall.  Typically an implementer
replaces their SHA-1 algorithm with SHA-1-DC, and they don't carry two
implementations, and thus, the performance matters.

As to the speed of SHA-1-DC, I can personally testify that it's limited
to about 50 MB/s, and that's information that a former colleague of mine
collected working on Git and which I've verified as a core Git
contributor.  The implementation is slower than every other well-known
hash algorithm except for MD2, which isn't a rousing endorsement.

> And that is the point we really should address here. We have a working
> and well standardized block cipher mode. It seems to make no sense to
> add three new block cipher modes for a total of five in the standard
> (OCFB still exists and is in current use). We have even had to create
> a preferences system just for the block cipher mode. Would any of
> this make any rational sense in any other context? Why does it make
> sense in this context?

I don't think having a preference here is a problem any more than having
a preference is a problem for cipher, hash, or compression algorithm.

I do think as people have mentioned there are approaches which offer
provable security behaviour, which OCFB-SHA-1 does not; which are 10 to
15 times faster and parallelizable, which OCFB-SHA-1 is not; meet
compliance needs for organizations working with the U.S. and Canadian
governments, which OCFB-SHA-1 does not; and don't get callouts from
cryptographers for bad design on Twitter, which OCFB-SHA-1 does.  The
performance alone is a compelling reason, and we have three other
reasons as well.

To summarize, I don't think there is consensus in the working group for
keeping OCFB-SHA-1 as the preferred encryption method and in fact there
is a great deal of consensus for replacing it with one (or possibly
more) AEADs.  I don't, therefore, think that continuing to defend it or
play devil's advocate is helpful or productive here, nor do I think it's
likely to change the product of the working group.  In the interests of
producing the crypto refresh RFC as expediently as possible, I think we
should stop giving serious consideration to proposals which are neither
in the charter nor have consensus in the working group.  As a result, I
will not be commenting further on your proposal.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA