Werner Koch, principal developer and creator of the GnuPG (GNU Privacy Guard) project, founded the LibrePGP project, focused on developing an updated specification, 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 perceived as questionable regarding compatibility preservation and security assurance. Developers supporting the fork 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 ready to accept changes that disrupt compatibility.
LibrePGP includes useful improvements that have been developed in recent years for the future version of the OpenPGP specification, while excluding changes that negatively affect compatibility. For example, compared to the current standard RFC-4880, LibrePGP includes such features 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 ability to decrypt data without integrity verification is categorized as completely obsolete).
- Increase of the fingerprint size to 256 bits.
- Support for the EdDSA digital signature scheme and the elliptic curves BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488, and X448.
- Support for the CRYSTALS-Kyber algorithm, resistant to attacks by quantum computers.
- 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 elements of criticism of the new OpenPGP specification:
- The IETF working group attempted to reinvent the standard instead of gradually incrementing the specification, making significant changes that disrupt compatibility.
- Impunerea suportului pentru modul de criptare simetric GCM (Galois/Counter Mode), care este dificil de implementat corect, ignorând însă modul OCB (Offset codebook mode), a cărui patenturi au expirat acum câțiva ani.
- Adăugarea de pachete opționale cu umplutură aleatorie adăugată pentru a proteja împotriva analizei de trafic. Potrivit creatorilor LibrePGP, astfel de pachete cu umplutură aleatorie inițială neconfirmată creează o amenințare de utilizare pentru crearea de canale ascunse de transmitere a datelor și ocolirea sistemelor de prevenire a scurgerilor de date. În trecut, ideea includerii umpluturii a fost respinsă, considerându-se ca fiind un obiect la nivel de aplicație, nu de criptare.
- Aplicarea unui format modificat al schemei de criptare ECDH (schimbarea formatului OID), în locul utilizării versiunii deja descrise în RFC-6637 și implementate în PGP și GnuPG.
- Eliminarea unor funcționalități utilizate în practică, cum ar fi metoda clasică de revocare a cheilor, semnul „m” pentru etichetarea datelor MIME și semnul „t” pentru separarea datelor text de cele binare (înlocuind semnul „t” cu semnul „u” pentru text în codificarea UTF-8).
- Refuzul de a include în noul format de semnături protecția metadatelor fișierului semnat (de exemplu, numele fișierului poate fi modificat fără a încălca semnătura).
- O posibilitate discutabilă de adăugare a „sării” la semnături (Salted signature) pentru a întări protecția împotriva atacurilor de coliziune cu prefix prestabilit. Valoarea cu sare poate fi folosită ca un canal ascuns nelimitat pentru transmiterea a 32 de biți de date în semnătură.
- Deplasarea standardului către utilizarea principală pentru comunicarea online, ignorând nevoile pentru stocarea pe termen lung a datelor.
Susținătorii OpenPGP au publicat deja critici asupra criticilor. În consecință, dacă nu se va găsi un compromis, divizarea poate duce la un număr tot mai mare de incompatibilități în implementările OpenPGP/LibrePGP. Parțial pentru a rezolva această problemă, dezvoltatorii OpenPGP au fixat a cincea versiune a formatului de semnături într-un mod compatibil cu LibrePGP și au început lucrările la a șasea versiune.
Sursa: opennet.ro
