LibrePGP is an updated alternative specification of the OpenPGP encryption standard
The main developer and maintainer of the encryption and signing tool The main developer and maintainer of, Werner Koch made it known a few days ago the news ofCreation of the LibrePGP project, which is a fork focused on developing an updated alternative specification to the OpenPGP standard.
It is mentioned that within the reasons of the creation of this fork It is apparently in response to a dispute within the Internet Engineering Task Force (IETF) on the future development of the OpenPGP standard, as Koch perceived the upcoming update to the OpenPGP specification as questionable from a compatibility and security perspective.
According to Koch:
The starting point for the separation of work within the IETF and for the start of LibrePGP is that the planned updates to the OpenPGP standard (RFC 4880) are "detrimental to the current use of OpenPGP software," he stated. In the Announcement he writes. Without going into specific technical details, the dispute goes back to the question of how to adapt the current OpenPGP standard for the future.
And the IETF, instead of gradually updating the specification, attempted to reinvent the standard and make significant changes to it that violated interoperability, in addition to imposing support for the GCM symmetric encryption mode, which is difficult to implement correctly, ignoring the OCB (Offset codebook mode), whose patents expired several years ago.
Developers of the GnuPG, RNP (Thunderbird OpenPGP implementation) and Gpg4win projects that supported the fork fear that the planned changes will be detrimental to existing implementations of OpenPGP-based applications, whose users expect the specification to be stable in the long term. and are not ready to support changes that break compatibility.
In addition to this, the LibrePGP creators question adding optional packages with random padding to protect against traffic analysis. According to them, these packets with unverifiable initial random filling pose a threat of being used to create hidden data transmission channels and bypass data leak prevention systems. Previously, the idea of including padding was rejected as an application-level issue rather than an encryption-level issue.
Moreover, They also question the use of a modified ECDH encryption scheme, instead of using the option already described in RFC-6637 and implemented in PGP and GnuPG, as well as the elimination of some practical features, such as the classic key revocation method, the "m" flag for marking MIME data and the “t” flag to separate text from binary data (the “t” flag was replaced by the “u” flag for UTF-8 encoded text).
Given this and other issues, were the reasons for the creation of LibrePGP, which is mentioned as incorporating useful improvements that have been developed in recent years for a future version of the OpenPGP specification, but avoids changes that would negatively affect compatibility. For example, compared to the current RFC-4880 standard, LibrePGP has adopted the following features:
- 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 classified as not recommended, and the ability to decrypt data without integrity checking is classified as completely deprecated).
- Increasing the fingerprint size to 256 bits.
- Supports the EdDSA digital signature scheme and the BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488, and X448 elliptic curve signature schemes.
- Support for the CRYSTALS-Kyber algorithm, which is resistant to selection in quantum computers.
- Support for OCB (Offset Codebook Mode) authenticated encryption modes.
- Implementation of the fifth version of the digital signature format with metadata protection.
- Support for extended subpackages with digital signatures.
Finally, it is worth mentioning that OpenPGP supporters They have already published criticism after criticism. As a result, if a compromise cannot be found, splitting can lead to increasing incompatibilities in OpenPGP/LibrePGP implementations. To partially solve this problem, the OpenPGP developers fixed the fifth version of the signature format as compatible with LibrePGP and moved on to work on the sixth version.
If you are interested in knowing more about it, you can check the details In the following link.