Differences

This shows you the differences between two versions of the page.

--- pgpfan:schism [2024/01/04 22:17] – [About the "OpenPGP Schism" (2023 Dec)] clarification b.walzer
+++ pgpfan:schism [2024/02/11 22:48] – Credit; time is important. b.walzer
@@ Line 21: / Line 21: @@
 =====GnuPG=====
-The GnuPG faction only wants to add one block cipher mode to the two that OpenPGP currently supports. Koch 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.
+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.
@@ Line 69: / Line 69: @@
 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 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. 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. Since, 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.