{"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\/de\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"Der Autor von GnuPG gr\u00fcndete LibrePGP, einen Fork des OpenPGP-Standards.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, der Hauptentwickler und Sch\u00f6pfer des GnuPG-Projekts, gr\u00fcndete 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 \u00c4nderungen f\u00fcr das n\u00e4chste Update der OpenPGP-Spezifikation (RFC-4880) erstellt, die von Koch als bedenklich in Bezug auf die Wahrung der Kompatibilit\u00e4t und die Gew\u00e4hrleistung der Sicherheit angesehen wurden. Die Entwickler von GnuPG, RNP (die OpenPGP-Implementierung von Thunderbird) und Gpg4win, die den Fork unterst\u00fctzen, bef\u00fcrchten, dass die geplanten \u00c4nderungen bestehende Implementierungen von OpenPGP-basierten Anwendungen, deren Nutzer auf die langfristige Stabilit\u00e4t der Spezifikation angewiesen sind, gef\u00e4hrden und nicht bereit sind, mit \u00c4nderungen zu leben, die die Kompatibilit\u00e4t brechen. <\/p>\n
LibrePGP umfasst n\u00fctzliche Verbesserungen, die in den letzten Jahren f\u00fcr eine zuk\u00fcnftige Version der OpenPGP-Spezifikation entwickelt wurden, schlie\u00dft jedoch \u00c4nderungen aus, die sich negativ auf die Wahrung der Kompatibilit\u00e4t auswirken. Im Vergleich zum aktuellen Standard RFC-4880 wurden in LibrePGP unter anderem folgende Funktionen \u00fcbernommen: <\/p>\n
\n
Unterst\u00fctzung des Camellia-Verschl\u00fcsselungsalgorithmus (RFC-5581),\n
Verpflichtende Unterst\u00fctzung f\u00fcr SHA2-256-Hashes (SHA-1 und MD5 wurden als nicht empfohlen eingestuft, und die M\u00f6glichkeit, Daten ohne Integrit\u00e4tspr\u00fcfung zu entschl\u00fcsseln, wurde als vollst\u00e4ndig veraltet eingestuft).\n
Erh\u00f6hung der Fingerprint-Gr\u00f6\u00dfe auf 256 Bit.\n
Unterst\u00fctzung f\u00fcr digitale Signaturschemata EdDSA und elliptische Kurven BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 und X448.\n
Unterst\u00fctzung des CRYSTALS-Kyber-Algorithmus, der gegen Angriffe von Quantencomputern resistent ist.\n
Unterst\u00fctzung von Modus authentifizierter Verschl\u00fcsselung OCB (Offset-Codebuchmodus).\n
Implementierung der f\u00fcnften Version des Formats digitaler Signaturen mit einem Schutz der Metadaten.\n
Unterst\u00fctzung erweiterter Subpakete mit digitalen Signaturen. <\/ul>\n
Hauptkritikpunkte an der neuen Spezifikation von OpenPGP: <\/p>\n
\n
Die IETF-Arbeitsgruppe hat anstelle eines schrittweisen inkrementellen Updates der Spezifikation versucht, den Standard neu zu erfinden und erhebliche \u00c4nderungen vorzunehmen, die die Kompatibilit\u00e4t verletzen.\n
Die Erzwungene Unterst\u00fctzung des symmetrischen Verschl\u00fcsselungsmodus GCM (Galois\/Z\u00e4hler-Modus), der schwer korrekt zu implementieren ist, w\u00e4hrend der OCB-Modus (Offset Codebook Mode), dessen Patente vor mehreren Jahren abgelaufen sind, ignoriert wird.\n
Die Hinzuf\u00fcgung von optionalen Paketen mit zuf\u00e4lligem zus\u00e4tzlichen Padding zum Schutz vor Traffic-Analyse. Laut den Entwicklern von LibrePGP stellen solche Pakete mit nicht \u00fcberpr\u00fcfbarem anf\u00e4nglichem Zufalls-Padding eine Bedrohung f\u00fcr die Schaffung versteckter Datenkan\u00e4le und die Umgehung von Datenverlust-Pr\u00e4ventionssystemen dar. Zuvor wurde die Idee, zus\u00e4tzliches Padding einzuf\u00fcgen, als unangemessen abgelehnt, da sie nicht dem Verschl\u00fcsselungslevel, sondern dem Applikationslevel zuzuordnen ist.\n
Die Anwendung eines modifizierten ECDH-Verschl\u00fcsselungsschemas (\u00c4nderung des OID-Formats) anstelle der bereits in RFC-6637 beschriebenen und in PGP und GnuPG implementierten Variante.\n
Entfernung einiger praktischer Funktionen, wie die klassische Methode zum Widerruf von Schl\u00fcsseln, das Flag «m» zur Kennzeichnung von MIME-Daten und das Flag «t» zur Trennung von Textdaten von bin\u00e4ren (anstelle des Flags «t» wurde das Flag «u» f\u00fcr Text in UTF-8-Codierung eingef\u00fchrt).\n
Der Verzicht auf den Einschluss von Datenschutz in das neue Format von Signaturen f\u00fcr die Metadaten der signierten Datei (zum Beispiel kann der Dateiname ge\u00e4ndert werden, ohne die Signatur zu verletzen).\n
Zweifelhafte M\u00f6glichkeit, «Salz» zu Signaturen (Salted Signature) hinzuzuf\u00fcgen, um den Schutz vor Kollisionangriffen mit einem bestimmten Pr\u00e4fix zu verst\u00e4rken. Der Wert mit Salz kann als nicht abschaltbarer versteckter Kanal zur \u00dcbertragung von 32 Bytes an Daten in der Signatur verwendet werden.\n
Die Verschiebung des Standards hin zu einer prim\u00e4ren Nutzung f\u00fcr Online-Kommunikation, w\u00e4hrend die Bed\u00fcrfnisse f\u00fcr die langfristige Speicherung von Daten ignoriert werden. <\/ul>\n
Bef\u00fcrworter von OpenPGP haben bereits Kritik an der Kritik ver\u00f6ffentlicht. Letztendlich k\u00f6nnte ein Mangel an Kompromiss zu einer Zunahme von Inkompatibilit\u00e4ten in den Implementierungen von OpenPGP\/LibrePGP f\u00fchren. Teilweise zur L\u00f6sung dieses Problems haben die Entwickler von OpenPGP die f\u00fcnfte Version des Signaturformats in einer mit LibrePGP kompatiblen Weise festgelegt und arbeiten nun an der sechsten Version. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"