GnuPG Creator Launches LibrePGP: A Fork of the OpenPGP Standard

Werner Koch, the main developer and founder of the GnuPG (GNU Privacy Guard) project, has launched LibrePGP, a project focused on developing an updated specification as an alternative to the OpenPGP standard. This fork was created in response to changes proposed by the IETF working group for the next update of the OpenPGP specification (RFC-4880), which Koch considers questionable in terms of maintaining compatibility and ensuring security.

Developers from projects such as GnuPG, RNP (the OpenPGP implementation used by Thunderbird), and Gpg4win have supported the fork. They are concerned that the planned changes could be detrimental to existing OpenPGP-based applications, whose users rely on long-term specification stability and are not prepared to accept compatibility-breaking changes.

LibrePGP incorporates useful improvements that have been developed in recent years for the future OpenPGP specification, but excludes changes that would negatively impact compatibility. Compared to the current RFC-4880 standard, LibrePGP introduces features such as:

• Support for the Camellia encryption algorithm (RFC-5581)
• ECC (Elliptic Curve Cryptography) extensions for OpenPGP (RFC-6637)
• Mandatory support for SHA2-256 hashes (SHA-1 and MD5 are now discouraged, and decrypting data without integrity verification is considered fully obsolete)
• Increasing the fingerprint size to 256 bits
• Support for EdDSA digital signature schemes and elliptic curves including BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488, and X448
• Support for the CRYSTALS-Kyber algorithm, which is resistant to quantum computer attacks
• Support for authenticated encryption modes such as OCB (Offset Codebook Mode)
• Implementation of the fifth version of the digital signature format with metadata protection
• Support for extended subpackets with digital signatures

Main Criticisms of the New OpenPGP Specification

• The IETF working group attempted to reinvent the standard with significant changes that break compatibility, instead of making gradual, incremental updates.
• Mandating support for the GCM (Galois/Counter Mode) symmetric encryption mode, which is difficult to implement correctly, while ignoring the OCB mode, whose patents expired years ago.
• Adding optional packets with random padding to protect against traffic analysis. According to LibrePGP’s creators, such packets with unverifiable random padding could be used to create covert data channels and bypass data leak prevention systems. Previously, the idea of adding padding was rejected as it should be handled at the application level, not the encryption level.
• Using a modified ECDH encryption scheme (changing the OID format) instead of the version already described in RFC-6637 and implemented in PGP and GnuPG.
• Removing some practical features, such as the classic key revocation method, the “m” flag for marking MIME data, and the “t” flag for distinguishing text from binary data (the “t” flag is replaced by the “u” flag for UTF-8 encoded text).
• Refusing to include metadata protection for signed files in the new signature format (for example, allowing the filename to be changed without breaking the signature).
• The questionable addition of “salt” to signatures (Salted signature) to strengthen protection against chosen-prefix collision attacks. The salt value could be used as a non-removable covert channel for transmitting 32 bytes of data in the signature.
• Shifting the standard’s focus toward online communication, while ignoring the needs of long-term data storage.

Supporters of OpenPGP have already published a response to these criticisms. If no compromise is reached, the split could lead to increasing incompatibilities between OpenPGP and LibrePGP implementations. To partially address this issue, OpenPGP developers have locked in the fifth version of the signature format to be compatible with LibrePGP and have begun work on a sixth version.