{"id":112077,"date":"2023-12-08T15:10:14","date_gmt":"2023-12-08T13:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp"},"modified":"2023-12-08T15:10:14","modified_gmt":"2023-12-08T13:10:14","slug":"avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"The author of GnuPG founded LibrePGP, a fork of the OpenPGP standard.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, the main developer and creator of the GnuPG (GNU Privacy Guard) project, established the LibrePGP project, focused on developing an updated specification alternative to the OpenPGP standard. The fork was created in response to changes proposed by the IETF working group for the next specification update of OpenPGP (RFC-4880), which Koch perceived as questionable in terms of maintaining compatibility and ensuring security. Supporters of the fork, including developers from GnuPG, RNP (the OpenPGP implementation from Thunderbird), and Gpg4win, fear that the proposed changes could be detrimental to existing OpenPGP-based application implementations, whose users rely on the long-term stability of the specification and are not willing to accept changes that disrupt compatibility. <\/p>\n
LibrePGP includes useful improvements developed in recent years for the future version of the OpenPGP specification, while excluding changes that negatively impact compatibility. For example, compared to the current standard RFC-4880, LibrePGP includes features such as: <\/p>\n
\n
Support for the Camellia encryption algorithm (RFC-5581),\n
ECC (Elliptic Curve Cryptography) extensions for OpenPGP (RFC-6637).\n
Mandatory support for SHA2-256 hashes (SHA-1 and MD5 are considered deprecated, and the ability to decrypt data without verifying integrity is classified as completely outdated).\n
Increased fingerprint size to 256 bits.\n
Support for digital signature schemes EdDSA and elliptic curves BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488, and X448.\n
Support for the CRYSTALS-Kyber algorithm, resistant to attacks from quantum computers.\n
Support for authenticated encryption modes OCB (Offset Codebook Mode).\n
Implementation of the fifth version of the digital signature format with metadata protection.\n
Support for extended subpackets with digital signatures. <\/ul>\n
Key elements of criticism of the new OpenPGP specification: <\/p>\n
\n
The IETF working group has attempted to reinvent the standard instead of a gradual incremental update to the specification, introducing significant changes that disrupt compatibility.\n
The imposition of support for the GCM (Galois\/Counter Mode) symmetric encryption mode, which is difficult to implement correctly, while ignoring the OCB (Offset Codebook Mode), for which patents expired several years ago.\n
The addition of optional packets with random padding to protect against traffic analysis. According to the creators of LibrePGP, such packets with unverifiable initial random padding pose a threat of being used to create hidden data transmission channels and bypass data leakage prevention systems. Previously, the idea of including padding was rejected as being an issue at the application layer rather than the encryption layer.\n
The use of a modified ECDH encryption scheme (changing the OID format), instead of the version already described in RFC-6637 and implemented in PGP and GnuPG.\n
Removal of some commonly used features, such as the classic key revocation method, the flag «m» for marking MIME data, and the flag «t» for separating text data from binary data (the flag «t» has been replaced by the flag «u» for UTF-8 text).\n
The refusal to include metadata protection of the signed file in the new signature format (for example, without violating the signatures, one can change the file name).\n
The dubious ability to add 'salt' to signatures (Salted Signature) to enhance protection against prefix collision attacks. The salted value can be used as an undetectable hidden channel to transmit 32 bytes of data in the signature.\n
A shift of the standard towards the primary use for online communication, ignoring the needs for long-term data storage. <\/ul>\n
Supporters of OpenPGP have already published criticisms of the criticism. In the end, if a compromise cannot be found, the split may lead to increasing incompatibilities in OpenPGP\/LibrePGP implementations. Partially to address this issue, OpenPGP developers have fixed the fifth version of the signature format in a manner compatible with LibrePGP and have started working on the sixth version. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"