{"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\/novosti-interneta\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"Der Autor von GnuPG hat LibrePGP gegr\u00fcndet, einen Fork des OpenPGP-Standards.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, der Hauptentwickler und Gr\u00fcnder des GnuPG-Projekts (GNU Privacy Guard), hat das Projekt LibrePGP ins Leben gerufen, das sich auf die Weiterentwicklung einer aktualisierten Spezifikation konzentriert, die als Alternative zum OpenPGP-Standard dient. Dieser Fork wurde als Reaktion auf die von der IETF-Arbeitsgruppe geplanten \u00c4nderungen f\u00fcr das n\u00e4chste Update der OpenPGP-Spezifikation (RFC-4880) erstellt. Koch empfand diese \u00c4nderungen als fragw\u00fcrdig, insbesondere in Bezug auf die Wahrung der Kompatibilit\u00e4t und Sicherheit. Die unterst\u00fctzenden Entwickelnden der GnuPG-, RNP- (die OpenPGP-Implementierung von Thunderbird) und Gpg4win-Projekte bef\u00fcrchten, dass die geplanten \u00c4nderungen bestehende OpenPGP-Anwendungen sch\u00e4digen k\u00f6nnten, deren Nutzer auf langfristige Stabilit\u00e4t der Spezifikation angewiesen sind und nicht bereit sind, Kompatibilit\u00e4ts\u00e4nderungen hinzunehmen. <\/p>\n
LibrePGP umfasst n\u00fctzliche Verbesserungen, die in den letzten Jahren f\u00fcr die zuk\u00fcnftige Variante der OpenPGP-Spezifikation entwickelt wurden, schlie\u00dft jedoch \u00c4nderungen aus, die sich negativ auf die Gew\u00e4hrleistung der Kompatibilit\u00e4t auswirken. Im Vergleich zum aktuellen Standard RFC-4880 wurden in LibrePGP zum Beispiel folgende F\u00e4higkeiten eingef\u00fchrt: <\/p>\n
\n
Unterst\u00fctzung des Verschl\u00fcsselungsalgorithmus Camellia (RFC-5581)\n
Verpflichtende Unterst\u00fctzung f\u00fcr SHA2-256-Hashes (SHA-1 und MD5 sind nicht mehr empfohlen, und die M\u00f6glichkeit, Daten ohne Integrit\u00e4tspr\u00fcfung zu entschl\u00fcsseln, gilt als vollst\u00e4ndig veraltet).\n
Erh\u00f6hung der Fingerabdruckgr\u00f6\u00dfe auf 256 Bit.\n
Unterst\u00fctzung des EdDSA-Digital-Signaturschemas und elliptischer Kurven wie BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 und X448.\n
Unterst\u00fctzung des CRYSTALS-Kyber-Algorithmus, der gegen Angriffe auf Quantencomputern resistent ist.\n
Unterst\u00fctzung f\u00fcr den authentifizierten Verschl\u00fcsselungsmodus OCB (Offset Codebook Mode).\n
Implementierung der f\u00fcnften Version des Formats f\u00fcr digitale Signaturen mit Schutz der Metadaten.\n
Unterst\u00fctzung f\u00fcr erweiterte Subpakete mit digitalen Signaturen. <\/ul>\n
Wesentliche Kritikpunkte an der neuen OpenPGP-Spezifikation: <\/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 beeintr\u00e4chtigen.\n
Die Unterst\u00fctzung des symmetrischen Verschl\u00fcsselungsmodus GCM (Galois\/Counter Mode) wird eingef\u00fchrt, w\u00e4hrend der OCB-Modus (Offset Codebook Mode), dessen Patente vor einigen Jahren abgelaufen sind, ignoriert wird.\n
Die Hinzuf\u00fcgung optionaler Pakete mit zuf\u00e4lligen Zusatzf\u00fcllungen zum Schutz vor Traffic-Analyse. Laut den Entwicklern von LibrePGP stellen solche Pakete mit nicht \u00fcberpr\u00fcfbarem anf\u00e4nglichem Zufallsinhalt eine Bedrohung dar, da sie zur Schaffung verborgener Daten\u00fcbertragungskan\u00e4le und zum Umgehen von Datenverlustpr\u00e4ventionssystemen verwendet werden k\u00f6nnen. Zuvor wurde die Idee der Einbeziehung zus\u00e4tzlicher F\u00fcllungen als nicht relevant f\u00fcr die Verschl\u00fcsselung, sondern auf der Anwendungsebene liegend, abgelehnt.\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 der klassische Schl\u00fcsselr\u00fcckforderungsmethode, das Flag «m» zur Kennzeichnung von MIME-Daten und das Flag «t» zur Trennung von Textdaten und Bin\u00e4rdaten (das Flag «t» wurde durch das Flag «u» f\u00fcr Text in UTF-8-Codierung ersetzt).\n
Die Entscheidung, den neuen Signaturformat Schutz f\u00fcr die Metadaten der signierten Datei nicht einzuschlie\u00dfen (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 Kollisionen mit einem festgelegten Pr\u00e4fix zu verst\u00e4rken. Der Wert mit Salz kann als nicht deaktivierbarer geheime Kanal zur \u00dcbertragung von 32 Byte Daten in der Signatur verwendet werden.\n
Verschiebung des Standards hin zu einer grundlegenden Nutzung f\u00fcr Online-Kommunikation, wobei die Bed\u00fcrfnisse f\u00fcr die langfristige Datenspeicherung ignoriert werden. <\/ul>\n
Bef\u00fcrworter von OpenPGP haben bereits eine Kritik der Kritik ver\u00f6ffentlicht. Letztendlich k\u00f6nnte ein Scheitern bei der Suche nach einem Kompromiss zu einer Zunahme von Inkompatibilit\u00e4ten in den Implementierungen von OpenPGP\/LibrePGP f\u00fchren. Teilweise um dieses Problem zu l\u00f6sen, haben die Entwickler von OpenPGP die f\u00fcnfte Version des Signaturformats in einer mit LibrePGP kompatiblen Form 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":"