======About the "OpenPGP Schism" (2023 Dec)======

There has been a recent article about a disagreement in the OpenPGP standards process:

[[https://lwn.net/SubscriberLink/953797/7222cd75661fb888/|A schism in the OpenPGP world]]

That article has sparked some discussion. A perfect excuse to throw my own comments into the void...

The politics here as I perceived them:

Way back, there was a rambling and expansive process to update the OpenPGP standard. Years. So eventually it was decided to do a more focused "crypto refresh" that would be restricted to just important cryptography concerns. The GnuPG project was part of this. During the process the head of the GnuPG project (Werner Koch) spent a lot of time pushing back against what he considered pointless or wrongheaded changes. Eventually things seemed to stabilize and there seemed to be a consensus and people started paying less attention. Koch was one of those people.

The process then wound up again and the draft incurred significant changes. A bunch of stuff that Koch opposed ended up in the standards draft. Koch eventually noticed and ended up taking the position that the GnuPG project would not follow the new changes and would instead stay where they were.

More recently, the two factions that fell out of this have been, actively and publicly, promoting their somewhat different proposals. That sparked the article.

I will refer to one faction as the GnuPG faction (now [[https://librepgp.org/|LibrePGP]]) but acknowledge that there are other projects that support this position. For lack of a better name, I will refer to the other faction as Crypto Refresh Current (now [[https://www.rfc-editor.org/rfc/rfc9580.html|RFC 9580]]).

I will only talk about the most contentious issue: the addition of new block cipher modes. The scope of the proposed changes is vast, but the block cipher mode issue is the aspect of this I feel the most qualified to comment on.

=====GnuPG=====

The GnuPG faction only wants to add one block cipher mode to the two that OpenPGP currently supports. Werner Koch (the principal author of GnuPG) has stated that the current authenticated mode is secure, which implies that the new mode is wanted for reasons other than security. The GnuPG project wants a new mode primarily for greater efficiency. The current mode can not work in parallel for encryption. This can make things slow for very large files (100s of GB) on multiprocessor systems. The proposed OCB mode is much faster. The other reason relates to error handling. The current authenticated encryption mode protects the entire file/message at once. That means that the decryption operation completes before returning an error. The new proposed OCB mode breaks the message/file into blocks and checks each separately. That means that an integrity error will stop the decryption immediately. This again can be important for processing large files.

I find the GnuPG position reasonable, but will point out that few users process really large files. There is no strong argument here for superseding the existing authenticated mode in general. An OpenPGP high efficiency mode can be treated as a separate function that the user can decide to activate for the rare situations where it might be appropriate.

Generally the GnuPG position is that as little as possible should be added to the standard. As a minimalist I agree. Complexity breeds insecurity.

=====Crypto Refresh Current=====

The Crypto Refresh Current faction wants to add 3 more block cipher modes to the two that OpenPGP currently supports. Considered separately:

====OCB====

This is more or less the same as the OCB mode proposed by the GnuPG faction. So my previous comments apply. Unfortunately, the Crypto Refresh Current faction has deliberately made their version incompatible with the GnuPG version. It is not clear to me why they did this.

This mode would be made mandatory in the OpenPGP standard.

====GCM====

This is also about efficiency. A browser based implementation of cryptographic functions would be slow running in JavaScript. There is an AES-GCM function in the Web Cryptography API which is supported by most browsers which would move the cryptographic operations to a lower and faster level. So this proposal is really about one mode as exposed by one API.

I am not sure why efficiency is all that important here. It is not likely that anyone will be encrypting/decrypting terabyte scale files in JavaScript. Typical applications would be for things like encrypted email.

I am also not sure that there would be that much of a performance increase. The Web Cryptography API could presumably be persuaded to encrypt a single AES block. It supports the hash used. So past that, the existing OpenPGP authenticated encryption mode only requires a single exclusive OR operation per block. The OCB mode doesn't even require a hash, it just needs a table lookup and an exclusive OR operation per block.

Note that OCB is generically faster than GCM. So GCM has no efficiency advantage outside the JavaScript/web context.

This mode would be made optional in the OpenPGP standard. So it would be very probable that there would be implementations around indefinitely that would not be able to decrypt messages/files encrypted using this mode.

====EAX====

This mode was included because of fears that the patent on the OCB mode might cause trouble and that another mode might be required. The patent in question was disclaimed by the inventor of the OCB mode years ago. Since the GCM mode was added it would work as an alternative mode instead. So as a result no one wants this mode. But bizarrely, it is still in the proposed Crypto Refresh standard. This fact causes me to think that the interest in the Crypto Refresh process has fallen below some critical level and that it is no longer functioning.

This mode is also optional. Chances are, no one will ever implement it. So good?

=====Where are we now?=====

We have a total of 4 new proposed block cipher modes. Each and every mode is incompatible with each and every other mode and the two existing modes. That means that files/messages encrypted with a particular mode can't be decrypted by another implementation that does not support that particular mode. This seems to be the complete opposite of what anyone would want from a standards process.

Subsequent to the split, the Crypto Refresh proposal has had even more stuff added to it. Significant bikeshedding has occurred. Even the title of the standard has been changed from "OpenPGP Message Format" to "OpenPGP". I don't see how it could possibly be legitimately released in its present form.

The really wild aspect of this whole block cipher thing is that it seems to be at least partially based on the incorrect idea that the existing OpenPGP authenticated block mode is insecure in some way. When I started doing my PGP advocacy articles I spent a lot of time trying to figure out why everyone thought it was insecure so I could spin it somehow. I only found misinformation and innuendo. No spin was required. The interested reader is invited to read [[https://articles.59.ca/doku.php?id=pgpfan:mdc|my attempt to explain why it is actually secure]].

From this you might think that I personally support the GnuPG faction. I actually reject both, at least for the cipher feedback modes. Previous to this I wrote an [[https://articles.59.ca/doku.php?id=pgpfan:no_new_ae|editorial]] that argues that the optimal number of new block cipher modes is zero. Even if we ever legitimately end up with another block cipher mode there would be no reason to use it for most applications. Making something like a email client emit messages incompatible with the existing, 20+ year old block cipher authenticated mode, would be nothing less than irresponsible.

The current version of the GnuPG program (2.3, 2.4) is actually generating new and incompatible encrypted files/messages using the OCB mode by default. This is causing subtle and hard to debug interoperability problems. I have seen more than 10 instances of this ([[https://articles.59.ca/doku.php?id=pgpfan:noae_shame|I am keeping a list]]). As the newer versions of  GnuPG hit the popular Linux distributions and as more new keys are generated we will undoubtedly see more. This behaviour might have made sense when it looked like there was some sort of consensus. It is definitely not cool now. What's worse, is that there does not seem to be any way for a user to change the default in a useful way. There seems to be no documentation or FAQ that might warn a user of possible trouble ahead and what to do about it. So the user gets drafted into a war that they have no stake in without their knowlege or consent. They will only realize this when their stored encrypted messages/files are no longer decryptable with whatever eventually ends up winning the war((Some Linux distributions are now patching GnuPG to prevent the emission of new block cipher modes. See:[[https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism]])).

An entity from the Crypto Refresh Current faction is now threatening to start emitting messages using the GCM cipher block mode. You can easily imagine what I think of this.

The reason that everyone thinks it is OK to just start generating encrypted messages/files incompatible with everything else is because of the existence of the OpenPGP preferences system. A PGP identity (PGP PUBLIC KEY) contains a list of preferences. The idea is that by using these preferences, an implementation will only send messages with new cipher block modes to implementations that support them. These preferences are mostly useful to prevent downgrade type attacks and allow transparent upgrades. They don't make it possible for everyone to have their own incompatible modes. That is because a PGP key pair is often generated on one system and then imported into another system. The second system might not support all the modes that the first one did. So things can fail for no apparent reason with no obvious resolution. Ironically the OpenPGP preferences system is making things worse as it makes it so that the problem will only occur when circumstances line up to cause the preferences system to fail. That will be at an indeterminate time after the key generation that originally enabled the problem. As opposed so a connection oriented system like TLS, the files/messages might be kept around for many decades. A usability time bomb...

This article was primarily written to point out that there is a third option available. Speaking from the prospective of the user: if you can't provide me any tangible benefit, if you are making things even a little bit less usable, then please do nothing at all. There is no crisis here. We can just keep using the existing authenticated block cipher mode. If we ended up continuing to use it indefinitely there would be no real downside.

[[pgpfan:index|PGP FAN index]]\\
[[em:index|Encrypted Messaging index]]\\
[[:|Home]]