1. Startseite
  2. Nachrichten
  3. Herunterladen
    1. Thunderbird Release-Version
    2. Thunderbird 128 ESR
    3. Thunderbird 115 ESR
    4. Thunderbird Beta-Version
    5. Sprachpaket (Benutzeroberfläche)
    6. Wörterbücher (Rechtschreibprüfung)
  4. Hilfe & Lexikon
    1. Anleitungen zu Thunderbird
    2. Fragen & Antworten (FAQ) zu Thunderbird
    3. Hilfe zu dieser Webseite
  5. Forum
    1. Unerledigte Themen
    2. Letzte Beiträge
    3. Themen der letzten 24 Stunden
  • Deutsch
  • Anmelden
  • Registrieren
  • 
  • Suche
Dieses Thema
  1. Thunderbird Mail DE
  2. Forum
  3. Hilfe zu Verschlüsselung & elektronische Signatur
  4. OpenPGP Verschlüsselung & Unterschrift
  5. Enigmail OpenPGP in Thunderbird-Versionen bis 68.*

Enigmail/GnuPG auf SHA-2 umstellen

  • SusiTux
  • 26. Februar 2017 um 19:34
  • Geschlossen
  • Erledigt
  • SusiTux
    Gast
    • 26. Februar 2017 um 19:34
    • #1

    Hallo,

    unter dem Titel: "Todesstoß: Forscher zerschmettern SHA-1" veröffentlichte Heise in der letzten Woche einen Artikel, der darüber informiert, dass es Forscher von der CWI Amsterdam und Google gelungen ist, eine erfolgreiche Kollision gegen SHA-1 zu fahren.
    Konkret ist es gelungen, zwei inhaltlich identische PDF-Dokumente zu erzeugen, die dennoch denselben SHA-1-Hash haben.

    Das kann klingt zunächst einmal sehr besorgniserregend, vor allem bei einer Überschrift, wie man sie sonst eher von anderen Verlagen kennt. Bei uns in der Firma hat das bei einigen prompt zur Verunsicherung und entsprechenden Nachfragen geführt. Ich möchte deshalb ein paar Hinweise zu GnuPG geben.

    GnuPG und somit auch Enigmail verwenden standardmäßig SHA-1, obwohl es "bessere" Hash-Algorithmen beherrscht. (Zumindest ist das in der GnuPG 2.0.22 noch so.) Die Präferenzen lassen sich durch eine Änderung in der gnupg.conf ändern. Ich empfehle, folgenden Zeilen hinzuzufügen:

    # Standardpräferenzen für Chiffre, Hash und Kompression, geändert durch ... am ...
    personal-cipher-preferences AES256 TWOFISH AES192 AES
    personal-digest-preferences SHA512 SHA384 SHA256
    personal-compress-preferences ZLIB BZIP2 ZIP

    Die erfolgreiche Umstellungen kann danach folgendermaßen getestet werden:

    Sendet euch selbst eine unverschlüsselte aber signierte E-Mail. Wenn ihr dann in der empfangenen E-Mail an der Stelle, an der Enigmail die korrekt Unterschrift anzeigt auf Details -> Enigmail-Sicherheitsinfo klickt, dann sollte dort RSA und SHA512 stehen.
    Im Quelltext der Mail sollte ebenfalls SHA512 stehen.

    Der Angriff ist ohne Frage beeindruckend. Dennoch möchte ich ein paar Punkte erwähnen, denn man sollte die Kirche schon im Dorf lassen:

    • Für diese eine Kollision waren laut des Artikels 6500 CPU-Jahre und 100 GPU-Jahre an Rechenzeit erforderlich.
    • Die Kollision erfolgte, indem man die Overhead-Daten des PDF sehr geschickt veränderte. In einem reinen Textfile wäre das ungleich schwieriger, denn das hat keinen solche Overhead.
      Einen nackten Text so abzuändern, dass er nicht nur denselben Hash ergibt sondern auch noch den gewünschten, falschen Inhalt, ist nach wie vor nahezu ausgeschlossen. Gleiches gilt für Programmdateien, denen man einen funktionsfähigen Schädling beigeben möchte. Das ist ohne eine Veränderung des Hash-Wertes nicht hinzubekommen.
    • SHA-1 ist ein Hash-Algorithmus. Das hat mit der Verschlüsselung von Inhalten nichts zu tun. Die Verschlüsselung durch GnuPG ist daher nicht betroffen.
      Wohl aber die digitale Unterschrift und das Komprimieren.

    Ich empfehle dennoch ebenfalls auf ein sichereres Hash-Verfahren umzustellen - schon aus Prinzip. Ein Grund zur Panik oder gar zu einer solchen Wortwahl, zu der Heise in der Überschrift gegriffen hat, kann ich aber beim besten Willen nicht erkennen.

    Gruß

    Susanne

  • generalsync
    Senior-Mitglied
    Reaktionen
    48
    Beiträge
    550
    Mitglied seit
    29. Aug. 2016
    Hilfreiche Antwort
    1
    • 26. Februar 2017 um 23:15
    • #2

    Bei der Gelegenheit kann man auch noch erwähnen, dass jeder öffentliche PGP-Key die Information zu unterstützten Hash-Verfahren enthält. Es ist zumindest empfehlenswert, diese für die eigenen Schlüssel anzusehen und ggf. anzupassen. So würde ich z.B. entgegen der langjährigen Standardeinstellung spätestens jetzt auch längere SHA2-Hashes gegenüber SHA1 bevorzugen (in der Praxis spielt dies jedoch vor allem bei älteren Keys eine Rolle, die nur SHA1 unterstützen). Die aktuellen Einstellungen eines Keys findet man in der Konsole über

    Code
    $ gpg --edit-key <keyid>
    gpg> showpref

    Mit "setpref" lässt sich die Reihenfolge und Auswahl anpassen. Achtung: man gibt hierbei eine Liste aller Algorithmen (incl. Cipher und Kompression) an, in absteigender Priorität – z.B.

    Code
    gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 TWOFISH CAMELLIA256 BLOWFISH AES192 CAMELLIA192 AES CAMELLIA128 CAST5 ZLIB BZIP2 ZIP Uncompressed

    – die Standard-Algorithmen wie SHA1 und 3DES werden dann automatisch mit geringster Priorität hinzugefügt. Anschließend muss der Key ggf. erneut auf Keyserver hochgeladen werden.

    Mit einem entsprechend eingerichteten Key verwenden die meisten Clients standardmäßig den erstgenannten Algorithmus einer Kategorie, wenn Nachrichten für diesen Key erzeugt werden. Man auf diese Weise also anpassen, welche Hashverfahren von anderen Nutzern verwendet werden sollen, wenn man selbst der Empfänger der Nachricht ist (im Gegensatz zur Einstellung für eigene Nachrichten die Susanne oben ja bereits genannt hat).

    Als schwarzmalerische Ergänzung vielleicht noch:

    Zitat von SusiTux

    Gleiches gilt für Programmdateien, denen man einen funktionsfähigen Schädling beigeben möchte.

    Es wäre aber einfacher als für Textdateien. Zumindest in der veränderten Version kann man schließlich beliebigen Overhead einbauen. Das Problem ist natürlich, dass man nun nicht eine beliebige Kollision sucht, sondern eine Kollision mit einem bestimmten Wert (dem der originalen Datei ohne Schädling). Das ist normalerweise ungleich schwerer, wobei ich die Mathematik hinter dem aktuellen Angriff nicht nachvollzogen habe.

    Zitat von SusiTux

    Ein Grund zur Panik oder gar zu einer solchen Wortwahl, zu der Heise in der Überschrift gegriffen hat, kann ich aber beim besten Willen nicht erkennen.

    Grund zur Panik besteht sicherlich nicht, aber es ist ein weiterer Sargnagel für SHA1: eine der zentralen Eigenschaften einer sicheren Hashfunktion (Kollisionsresistenz) ist erwiesenermaßen nicht erfüllt. Kann man von mir aus auch als Todesstoß bezeichnen, heise hatte da schon reißerischere Überschriften...
    Die Verwendung von SHA1 sollte daher eingestellt werden – dieser Vorgang hat ja auch bereits vor einigen Jahren begonnen, als die theoretischen Grundlagen für diesen Angriff gefunden wurden.

    Ich entwickle unter anderem Synchronisationssoftware für Kalender und Adressbücher – ohne Cloud oder Server.

    Einmal editiert, zuletzt von generalsync (26. Februar 2017 um 23:26)

  • SusiTux
    Gast
    • 27. Februar 2017 um 12:44
    • #3
    Zitat von generalsync

    Bei der Gelegenheit kann man auch noch erwähnen, dass jeder öffentliche PGP-Key die Information zu unterstützten Hash-Verfahren enthält.

    Oh ja, das ist ein guter Hinweis. An die ganz alten Schlüssel hatte ich gar nicht mehr gedacht. Alle mir bekannten stammen aus der Version 1.4 oder neuer. Die haben schon

    Digest: SHA256, SHA1, SHA384, SHA512, SHA224

    Also ja, das Überprüfen lohnt sich. Wer weiß, wie viele ältere Schlüsselpaare noch in Gebrauch sind. Bei der Gelegenheit biete es sich an, einmal darüber nachzudenken, alte Schlüsselpaare zu widerrufen und durch neue zu ersetzen.

    Zitat von generalsync

    Es wäre aber einfacher als für Textdateien. Zumindest in der veränderten Version kann man schließlich beliebigen Overhead einbauen

    Das ist prinzipiell richtig, würde aber auffallen. Denn zu einer Prüfung der Integrität einer Datei gehört neben dem Hash immer auch die Dateigröße. Das sollte überhaupt die erste Überprüfung sein, denn wenn die Dateigröße nicht stimmt, kann dann die Datei nicht original sein. Den Hash-Wert braucht man dann gar nicht erst zu kontrollieren.
    Schadcode hinzuzufügen ohne die Dateigröße und den Hash zu verändern, halte ich für ausgeschlossen.


    Zitat von generalsync

    eine der zentralen Eigenschaften einer sicheren Hashfunktion (Kollisionsresistenz) ist erwiesenermaßen nicht erfüllt.

    Zu jedem Hash-Verfahren gibt es Kollisionen. Das liegt in der Natur der Sache, denn der Hash ist ja stets kleiner als die Datei, deren Hash man berechnet.

    Ein Beispiel:

    Ein Hash mit 256 Bit kann 2^256 = 1,2*10^77 verschiedene Werte annehmen. Das ist zwar eine sehr große Zahl mit 77 Nullen, aber bereits eine sehr kleine Datei von nur einem KB enthält 1024 BIts. Es gibt somit 2^1024 mögliche verschiedene 1-KB-Dateien, also bereits bei einer so kleinen Datei wesentlich mehr mögliche Dateien als es Hashes geben kann.

    Die Frage ist also nicht die, ob Kollisionen möglich sind, sondern welcher Aufwand getrieben werden muss, eine zu erzeugen. SHA-1 hat prinzipielle Schwächen, die einen solche Angriff für Supercomputer in den Bereich des Möglichen rücken. Die Kollision auf ein einziges PDF benötigte 6500 CPU-Jahre. Selbst ein Supercomputer mit 6500 CPUs hätte daran also immer noch ein Jahr zu rechnen. Da können wir Privatleute ganz entspannt bleiben.


    Zitat von generalsync

    Die Verwendung von SHA1 sollte daher eingestellt werden

    Ohne Frage, ja! Allerdings ohne die Benutzer zuvor so unnötig zu verunsichern, wie Heise das erreicht hat. Wir haben bereits Anfragen von Kunden erhalten, die von uns eine ISO- und ITIL-konforme Bestätigung haben möchten, dass unsere Produkte kein SHA-1 verwenden.
    Das klinkt zunächst banal, ist es aber nicht, weil wir Komponenten von Zuliefern verwenden, über die wir keine Aussage treffen können. Wenn nun ein Kunde eine rechtswirksame Aussage verlangt, dass wir den Gebrauch von SHA-1 absolut ausschließen können, dann ist das ein echtes Problem und bedarf juristischer Unterstützung.
    Zum Glück haben wir (noch) keine Anfrage in solch einer Absolutheit. Die Kunden haben einen gesunden Menschenverstand. Aufwand erzeugt das Thema aber jetzt bereits.

  • generalsync
    Senior-Mitglied
    Reaktionen
    48
    Beiträge
    550
    Mitglied seit
    29. Aug. 2016
    Hilfreiche Antwort
    1
    • 27. Februar 2017 um 17:08
    • #4
    Zitat von SusiTux

    Das ist prinzipiell richtig, würde aber auffallen. Denn zu einer Prüfung der Integrität einer Datei gehört neben dem Hash immer auch die Dateigröße.

    In der Praxis wird die Dateigröße jedoch nicht immer geprüft, beispielsweise bei Add-on-Updates für Thunderbird: die Dateigröße eines Updates wird in der update.rdf nicht abgelegt (siehe MDN-Artikel zu Add-on Updates). In der Praxis nutzen viele Anbieter hier ohnehin zusätzlich HTTPS, aber ein Update via HTTP mit SHA1-Hashes ist technisch zulässig.

    Zitat von SusiTux

    Zu jedem Hash-Verfahren gibt es Kollisionen.

    Das ist klar, ich sprach ja auch von (starker) Kollisionsresistenz.

    Ich entwickle unter anderem Synchronisationssoftware für Kalender und Adressbücher – ohne Cloud oder Server.

  • SusiTux
    Gast
    • 27. Februar 2017 um 19:39
    • #5
    Zitat von generalsync

    In der Praxis wird die Dateigröße jedoch nicht immer geprüft,

    Das ist sicher richtig. In der Praxis werden bei Downloads aber auch Hashwerte oft nicht geprüft. Schlimmer noch: Viele Benutzer klicken auf alle möglichen Downloadlinks und laden sich Maleware. Das ist schon ein komisches Argument.

    Zitat von generalsync

    Das ist klar, ich sprach ja auch von (starker) Kollisionsresistenz.

    Nun, wie Du Deinem Link entnehmen kannst, bedeutet selbst schwache Kollisionsresistenz, dass es praktisch undurchführbar ist, zu einem gegebenen Dokument ein zweites Dokument das mit diesem kollidiert. Die erwähnten 6500 CPU-Jahre sind nach meinem Dafürhalten für uns normale Bürger praktisch genug.

  • Thunder 30. August 2020 um 14:37

    Hat das Thema aus dem Forum OpenPGP Verschlüsselung & Unterschrift nach OpenPGP & Enigmail in Thunderbird-Versionen bis 68.* verschoben.
  • Susi to visit
    Senior-Mitglied
    Reaktionen
    501
    Beiträge
    2.827
    Mitglied seit
    19. Sep. 2020
    Hilfreiche Antworten
    29
    • 16. April 2022 um 10:44
    • #6

    Kaum sind 5 Jahre rum, fällt mir doch beim erneuten Lesen ein kleiner, aber doch wichtiger Fehler auf. Ich hatte ein "nicht" vergessen:

    Zitat von SusiTux

    Konkret ist es gelungen, zwei inhaltlich identische PDF-Dokumente zu erzeugen, die dennoch denselben SHA-1-Hash haben.

    Das muss natürlich heißen "zwei inhaltlich nicht identische PDF-Dokumente ...". Sonst würde das alles ja gar keinen Sinn ergeben. Dass das niemandem aufgefallen ist!

    Sagen wir mal, es haben schon richtig verstanden, wollten aber so nett sein und nicht jeden offensichtlichen Fehler anmeckern. ;)

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Community-Bot 3. September 2024 um 20:30

    Hat das Thema geschlossen.

Aktuelle Programmversion

  • Thunderbird 138.0.2 veröffentlicht

    Thunder 20. Mai 2025 um 16:44

Aktuelle ESR-Version

  • Thunderbird 128.10.2 ESR veröffentlicht

    Thunder 20. Mai 2025 um 20:27

Keine Werbung

Hier wird auf Werbeanzeigen verzichtet. Vielleicht geben Sie dem Website-Betreiber (Alexander Ihrig - aka "Thunder") stattdessen etwas aus, um diese Seiten auf Dauer finanzieren zu können. Vielen Dank!

Vielen Dank für die Unterstützung!

Kaffee ausgeben für:

3,00 €
1
Per Paypal unterstützen*

*Weiterleitung zu PayPal.Me

Thunderbird Mail DE
  1. Impressum & Kontakt
  2. Datenschutzerklärung
    1. Einsatz von Cookies
  3. Nutzungsbedingungen
  4. Spendenaufruf für Thunderbird
Hilfe zu dieser Webseite
  • Übersicht der Hilfe zur Webseite
  • Die Suchfunktion benutzen
  • Foren-Benutzerkonto - Erstellen (Neu registrieren)
  • Foren-Thema erstellen und bearbeiten
  • Passwort vergessen - neues Passwort festlegen
Copyright © 2003-2025 Thunderbird Mail DE

Sie befinden sich NICHT auf einer offiziellen Seite der Mozilla Foundation. Mozilla®, mozilla.org®, Firefox®, Thunderbird™, Bugzilla™, Sunbird®, XUL™ und das Thunderbird-Logo sind (neben anderen) eingetragene Markenzeichen der Mozilla Foundation.

Community-Software: WoltLab Suite™
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Forum
  • Lexikon
  • Artikel
  • Seiten
  • Erweiterte Suche
  • Deutsch
  • English
Zitat speichern