Der Autor von GnuPG gründete LibrePGP, einen Fork des OpenPGP-Standards.

Werner Koch, der Hauptentwickler und Schöpfer des GnuPG-Projekts, gründete das LibrePGP-Projekt, das sich auf die Entwicklung einer aktualisierten Spezifikation konzentriert, die eine Alternative zum OpenPGP-Standard darstellt. Der Fork wurde als Reaktion auf die von der IETF-Arbeitsgruppe vorgeschlagenen Änderungen für das nächste Update der OpenPGP-Spezifikation (RFC-4880) erstellt, die von Koch als bedenklich in Bezug auf die Wahrung der Kompatibilität und die Gewährleistung der Sicherheit angesehen wurden. Die Entwickler von GnuPG, RNP (die OpenPGP-Implementierung von Thunderbird) und Gpg4win, die den Fork unterstützen, befürchten, dass die geplanten Änderungen bestehende Implementierungen von OpenPGP-basierten Anwendungen, deren Nutzer auf die langfristige Stabilität der Spezifikation angewiesen sind, gefährden und nicht bereit sind, mit Änderungen zu leben, die die Kompatibilität brechen.

LibrePGP umfasst nützliche Verbesserungen, die in den letzten Jahren für eine zukünftige Version der OpenPGP-Spezifikation entwickelt wurden, schließt jedoch Änderungen aus, die sich negativ auf die Wahrung der Kompatibilität auswirken. Im Vergleich zum aktuellen Standard RFC-4880 wurden in LibrePGP unter anderem folgende Funktionen übernommen:

• Unterstützung des Camellia-Verschlüsselungsalgorithmus (RFC-5581),
• Erweiterungen für ECC (Elliptische-Kurven-Kryptographie) für OpenPGP (RFC-6637).
• Verpflichtende Unterstützung für SHA2-256-Hashes (SHA-1 und MD5 wurden als nicht empfohlen eingestuft, und die Möglichkeit, Daten ohne Integritätsprüfung zu entschlüsseln, wurde als vollständig veraltet eingestuft).
• Erhöhung der Fingerprint-Größe auf 256 Bit.
• Unterstützung für digitale Signaturschemata EdDSA und elliptische Kurven BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 und X448.
• Unterstützung des CRYSTALS-Kyber-Algorithmus, der gegen Angriffe von Quantencomputern resistent ist.
• Unterstützung von Modus authentifizierter Verschlüsselung OCB (Offset-Codebuchmodus).
• Implementierung der fünften Version des Formats digitaler Signaturen mit einem Schutz der Metadaten.
• Unterstützung erweiterter Subpakete mit digitalen Signaturen.

Hauptkritikpunkte an der neuen Spezifikation von OpenPGP:

• Die IETF-Arbeitsgruppe hat anstelle eines schrittweisen inkrementellen Updates der Spezifikation versucht, den Standard neu zu erfinden und erhebliche Änderungen vorzunehmen, die die Kompatibilität verletzen.
• Die Erzwungene Unterstützung des symmetrischen Verschlüsselungsmodus GCM (Galois/Zähler-Modus), der schwer korrekt zu implementieren ist, während der OCB-Modus (Offset Codebook Mode), dessen Patente vor mehreren Jahren abgelaufen sind, ignoriert wird.
• Die Hinzufügung von optionalen Paketen mit zufälligem zusätzlichen Padding zum Schutz vor Traffic-Analyse. Laut den Entwicklern von LibrePGP stellen solche Pakete mit nicht überprüfbarem anfänglichem Zufalls-Padding eine Bedrohung für die Schaffung versteckter Datenkanäle und die Umgehung von Datenverlust-Präventionssystemen dar. Zuvor wurde die Idee, zusätzliches Padding einzufügen, als unangemessen abgelehnt, da sie nicht dem Verschlüsselungslevel, sondern dem Applikationslevel zuzuordnen ist.
• Die Anwendung eines modifizierten ECDH-Verschlüsselungsschemas (Änderung des OID-Formats) anstelle der bereits in RFC-6637 beschriebenen und in PGP und GnuPG implementierten Variante.
• Die Streichung einiger praxisrelevanter Funktionen, wie der klassischen Methode zum Widerrufen von Schlüsseln, dem „m“-Flag zur Kennzeichnung von MIME-Daten und dem „t“-Flag zur Trennung von Text- und Binärdaten (das „t“-Flag wurde durch das „u“-Flag für UTF-8-codierten Text ersetzt).
• Der Verzicht auf den Einschluss von Datenschutz in das neue Format von Signaturen für die Metadaten der signierten Datei (zum Beispiel kann der Dateiname geändert werden, ohne die Signatur zu verletzen).
• Die fragwürdige Möglichkeit, „Salz“ zu Signaturen hinzuzufügen (Salted Signature), um den Schutz vor Kollisionen mit festgelegtem Präfix zu verstärken. Der Wert mit Salz könnte als nicht ausschaltbarer geheimer Kanal zur Übertragung von 32 Byte Daten in der Signatur verwendet werden.
• Die Verschiebung des Standards hin zu einer primären Nutzung für Online-Kommunikation, während die Bedürfnisse für die langfristige Speicherung von Daten ignoriert werden.

Befürworter von OpenPGP haben bereits Kritik an der Kritik veröffentlicht. Letztendlich könnte ein Mangel an Kompromiss zu einer Zunahme von Inkompatibilitäten in den Implementierungen von OpenPGP/LibrePGP führen. Teilweise zur Lösung dieses Problems haben die Entwickler von OpenPGP die fünfte Version des Signaturformats in einer mit LibrePGP kompatiblen Weise festgelegt und arbeiten nun an der sechsten Version.

Quelle: opennet.ru