Werner Koch, a principal developer and creator of the GnuPG project, founded the LibrePGP project, focused on developing an updated specification that serves as an alternative to the OpenPGP standard. The 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 regarded as questionable in terms of maintaining compatibility and ensuring security. Developers from GnuPG, RNP (the OpenPGP implementation for Thunderbird), and Gpg4win who supported the fork are concerned that these proposed changes could be detrimental to existing OpenPGP-based application implementations, whose users depend on the long-term stability of the specification and are not willing to accept compatibility-breaking changes.
LibrePGP includes useful enhancements that have been 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 accepts 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 categorized as deprecated, and the possibility of decrypting data without integrity verification is considered completely obsolete).
- An increase of the fingerprint size to 256 bits.
- Support for EdDSA digital signature schemes and elliptic curves 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 OCB (Offset Codebook Mode).
- Implementation of the fifth version of the digital signatures format with metadata protection.
- Support for extended subpackets with digital signatures.
Key points of criticism towards the new OpenPGP specification:
- The IETF working group attempted to reinvent the standard instead of making gradual incremental updates to the specification, resulting in significant changes that disrupt compatibility.
- A szimmetrikus GCM (Galois/Counter Mode) titkosítási mód támogatásának bevezetése, amelyet nehéz helyesen megvalósítani, figyelmen kívül hagyva az OCB (Offset codebook mode) módot, amelynek szabadalma már évekkel ezelőtt lejárt.
- Opcionális csomagok hozzáadása véletlenszerű kiegészítő kitöltéssel a forgalomelemzés elleni védelem érdekében. A LibrePGP készítői szerint az ilyen csomagok, amelyek ellenőrizhetetlen kezdeti véletlenszerű kitöltést tartalmaznak, veszélyt jelentenek a rejtett adatsugárzási csatornák létrehozása és az adatszivárgás-ellenőrző rendszerek megkerülése szempontjából. Korábban a kiegészítő kitöltés bevezetésének ötlete elutasításra került, mivel az nem a titkosítás szintjén, hanem az alkalmazás szintjén zajlott.
- A módosított ECDH titkosítási séma alkalmazása (OID formátum módosítása), a RFC-6637-ban leírt és a PGP-ben, valamint a GnuPG-ben megvalósított változat helyett.
- Néhány gyakorlatban használt funkció eltávolítása, például a klasszikus kulcstörlés módszer, az „m” jelző a MIME-adatok megjelölésére, és a „t” jelző a szöveges adatok megkülönböztetésére a bináris adatokról (a „t” jelzőt az „u” jelző váltotta fel a UTF-8 kódolású szöveghez).
- A legújabb aláírási formátumban a aláírt fájl metaadatainak védelme kizárva (például a fájlnevet a aláírás megsértése nélkül meg lehet változtatni).
- Kérdéses lehetőség a „só” hozzáadása az aláírásokhoz (Sózott aláírás) a megadott előtaggal rendelkező ütközési támadások elleni védelem fokozása érdekében. A sózott érték használható, mint egy kikapcsolhatatlan rejtett csatorna 32 bájt adat átvitelére az aláírásban.
- A szabvány elmozdulása az online kommunikáció alapvető használata felé, figyelmen kívül hagyva az adatok hosszú távú tárolásának igényeit.
Az OpenPGP támogatói már közzétették kritikájukat a kritikára. Végső soron, ha nem sikerül megállapodást találni, a szétszakadás növelheti az OpenPGP/LibrePGP megvalósítások közötti inkompatibilitásokat. Részben e probléma megoldása érdekében az OpenPGP fejlesztői rögzítették az aláírások ötödik verzióját, amely kompatibilis a LibrePGP-vel, és elkezdték a hatodik verzióra való átállást.
Forrás: opennet.ru
