| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| pgpfan:schism [2024/02/11 22:48] – Credit; time is important. b.walzer | pgpfan:schism [2024/10/06 05:36] (current) – [About the "OpenPGP Schism" (2023 Dec)] we have better names now. b.walzer |
|---|
| More recently, the two factions that fell out of this have been, actively and publicly, promoting their somewhat different proposals. That sparked the article. | 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 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 (the latest IETF draft). | 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. | 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. |
| 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. | 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. | 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. | 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. Since, as opposed so a connection oriented system like TLS, the files/messages might be kept around for many decades. A usability time bomb... | 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. | 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. |
