| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| pgpfan:schism [2024/02/11 23:32] – Phrasing. 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. |
