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
$ gpg --edit-key <keyid>
gpg> showprefMit "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.
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:
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.
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.
