Werner Koch, the primary developer and creator of the GnuPG (GNU Privacy Guard) project, founded the LibrePGP project, focused on developing an updated alternative specification to the OpenPGP standard. The fork was created in response to changes planned by the IETF working group for the next update to the OpenPGP specification (RFC-4880) and perceived by Koch as questionable from a compatibility and security perspective. Developers of the GnuPG, RNP (Thunderbird's OpenPGP implementation) and Gpg4win projects who 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 put up with changes that break compatibility.
LibrePGP incorporates useful improvements that have been developed in recent years for a future version of the OpenPGP specification, but avoids changes that would negatively impact compatibility. For example, compared to the current RFC-4880 standard, LibrePGP has adopted the following features:
- Camellia encryption algorithm support (RFC-5581),
- ECC (Elliptic Curve Cryptography) extensions for OpenPGP (RFC-6637).
- Mandatory support for SHA2-256 hashes (SHA-1 and MD5 are classified as deprecated, and the ability to decrypt data without integrity verification is classified as completely obsolete).
- Increasing the fingerprint size to 256 bits.
- Supports EdDSA digital signature scheme and BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 and X448 elliptic curve signature schemes.
- Support for the CRYSTALS-Kyber algorithm, which is resistant to selection on 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.
The main elements of criticism of the new OpenPGP specification:
- The IETF working group, instead of gradually incrementally updating the specification, tried to reinvent the standard and make significant changes to it that violated interoperability.
- Imposing support for the symmetric GCM (Galois/Counter Mode) encryption mode, which is difficult to implement correctly, while ignoring the OCB (Offset codebook mode), the patents for which expired several years ago.
- Adding optional packages with random padding to protect against traffic analysis. According to the creators of LibrePGP, such 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 being an application level issue rather than an encryption level issue.
- Use of a modified ECDH encryption scheme (change in OID format), instead of using the option already described in RFC-6637 and implemented in PGP and GnuPG.
- Removal of some practical features, such as the classic key revocation method, the "m" flag for marking MIME data, and the "t" flag for separating text from binary data (the "t" flag was replaced by the "u" flag for encoded text UTF-8).
- Refusal to include protection of the signed file’s metadata in the new signature format (for example, you can change the file name without violating the signature).
- The dubious possibility of adding “salt” to signatures (Salted signature) to enhance protection against collision attacks with a given prefix. The salted value can be used as a non-disabled covert channel to carry 32 bytes of data in the signature.
- Shift of the standard towards the main use for online communication, ignoring the needs for long-term data storage.
OpenPGP supporters have already published criticism upon criticism. As a result, if a compromise cannot be found, the split may lead to increasing incompatibilities in OpenPGP/LibrePGP implementations. Partially to 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.
Source: opennet.ru
