Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |
| pgpfan:schism [2024/02/11 22:48] – Credit; time is important. b.walzer | pgpfan:schism [2024/02/11 23:32] (current) – Phrasing. b.walzer |
|---|
| 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. |
