PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GnuPG und SHA-1



O'rallY
18.01.08, 12:24
Hi,

ich habe meinen Schlüssel so konfiguriert, dass als bevorzugter Hash-Algorithmus SHA512 eingestellt ist. Wenn ich nun aber eine Email mittels Enigmail in Thunderbird signiere, sieht eine solche Nachricht in etwa so aus:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bla bla bla
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

{Signatur}
-----END PGP SIGNATURE-----

Mich irrietiert nun die zweite Zeile Hash: SHA1. Wie kommt es, dass trotzdem der unsichere SHA1 zum Signieren verwendet wird, obwohl mein Schlüssel anders konfiguriert ist.

Auch die Ausgabe von pgpdump weist auf eine irgendwie geartete Fehlkonfiguration hin:


pgpdump pubkey.asc
{...}
Pub alg - RSA Encrypt or Sign(pub 1) {Dies stimmt im übrigen auch nicht. Der RSA-Schlüssel wurd ausschließlich zum signieren verwendet.}
Hash alg - SHA1(hash 2)
{...}


Kann jemand Klarheit in diese Sache bringen?

Danke und Grüße

/dev/null_Peter
18.01.08, 15:21
Hi O'rallY,

ich befasse mich zwar nicht mehr näher mit GnuPG, aber trotzdem einige Bemerkungen dazu:

Der bei der Generierung des Schlüssels bevorzugter Hash-Algorithmus hat imho sehr wenig mit der tatsächlich durch den Mailclient (!) vorgenommenen Signatur zu tun. So lange nicht gewährleistet ist, dass weltweit alle gängigen Clients in der Lage sind, eine Signaturprüfung mit SHA521 oder anderen "moderneren" Algorithmen durchzuführen, muss man sich auf den kleinsten gemeinsamen Nenner einigen. Und das ist eben ggw. noch SHA1. Ich kann jetzt nicht sagen, ob man das bei GnuPG (unter evtl. Inkaufnahme, dass die Gegenstelle die Signatur nicht prüfen kann!) in einer Konfigurationsdatei anders einstellen kann. Bei den durch uns genutzen Plugins für höherwertigere Signaturen ist das sehr wohl der Fall.

Zum Algorithmus SHA1:
Selbstverständlich sind mir die Informationen über erfolgreiche Angriffe auf SHA1 bekannt. Man sollte sich aber klar machen, was hier überhaupt als "erfolgreicher Angriff" bezeichnet wird. Der Nachweis, dass es möglich ist die Zahl der notwendigen Operationen um 2 oder 3 Schritte zu verringern um eine so genannte Kollision (gleiche Hashwerte) zu erzeugen, gilt eben als erfolgreich.
Dieser "erfolgreiche Angriff" hat noch lange nichts damit zu tun, dass es jemandem gelungen ist, in zumutbarer Zeit eine sinnvolle und lesbare Datei mit gleichem Haswert zu erzeugen.

Und es ist auch gut und richtig, dass Weltweit Forschungsinstitute (auch bei uns ...) daran arbeiten, um diese Schwachstellen zu finden.
Aus diesem Grund findet regelmäßig bei der Bundesnetzagentur eine Expertenanhörung über Algorithmen für qualifizierte (!!) Signaturen statt.
Siehe auch hier: http://www.bsi.bund.de/esig/kryptoalg.htm
Bei der letzten Beratung am 26.10.07 in Mainz wurde die Empfehlung ausgesprochen, SHA1 für Neuentwicklungen und ab März (?) 2008 für qualifizierte Signaturen nicht mehr zu verwenden.

Ich betone hier, dass es sich um qualifizierte Signaturen nach SigG/SigV dreht. So genannte "Sichere Signaturerstellungseinheiten" (=> Prozessorchipkarten) und nach SigG zugelassene Anwendungen zur Signaturerstellung und -Prüfung sind hier die Themen. Es geht um elektronische Signaturen, welche laut Gesetz der menschlichen Unterschrift weitestgehend gleichgestellt sind ... .

Bei der so genannten "Fortgeschrittenen Signatur" - die wegen der imho äußerst hohen Anforderungen des SigG wesentlich weiter verbreitet ist - gibt es ggw. derartige Forderungen zur Ablösung von SHA1 überhaupt nicht. (Natürlich wird auch dort nachgezogen.) Gleiches trifft zu für die Fortgeschrittene Mailsignatur. Es wird nie eine qualifizierte Mailsignatur geben (=> Client der Gegenstelle ...)

Und von GnuPG spricht hier überhaupt niemand ... .


Ich habe das deswegen so ausführlich beschrieben, weil imho ggw. keinerlei Ursache besteht, bei der durch GnuPG durchgeführten einfachen Signatur SHA1 nicht mehr zu verwenden. Wie gesagt - es kann sogar dazu führen dass die Gegenstelle überhaupt keine Signaturprüfung durchführen kann.

MfG Peter
(der sich voll bewusst ist, damit die "GnuPG-Fraktion" zur Diskussion provoziert zu haben :-) )

O'rallY
18.01.08, 22:22
Danke für die ausführliche und aufschlussreiche Stellungname.

Im Großen und Ganzen stimme ich deinen Ansichten zu. Dieser Artikel (http://www.heise.de/security/artikel/56555) von der c't stützen ebenfalls deine Behauptungen. ;)

Allerdings würde ich sensible Informationen nur ungern einem Hash-Algorithmus überantworten, bei dem bereits 2005 eine Möglichkeit gefunden wurde, die notwendigen Operationen (um eine Kollision per Brute-Force zu ermitteln), um 2^11 zu verringern. Ich nehme an, dass gerade Nachrichtendienste nicht daran interessiert sind, weitere erfolgreiche Kryptoanalysen publik zu machen.

Wofür sind dann die Schlüsselpräfernezen gut, wenn nicht zur Signatur? Wo werden denn noch Hashes bei GnuPG eingesetzt?

lg

/dev/null_Peter
19.01.08, 13:53
Ich möchte jetzt keine Diskussion über "sensible Informationen" anfangen.
Einen "Vollschutz" bekommst du nicht. Nirgendwo. Und so lange du keinen "Zone 0-Rechner" benutzt (Abstrahlsicherheit => Wikipedia!) brauchst du dir auch keine SINA-Box zur Verschlüsselung hinstellen (zugelassen für alle nationalen Geheimhaltungsgrade => Quelle: BSI).
Also kehren wir wieder auf den privaten Bereich zurück ... .

Du musst sauber trennen zwischen Verschlüsselung und elektronischer Signatur.
Zur hybriden Verschlüsselung (Analogien GnuPG und S/MIME) muss ich ja wohl nichts sagen, oder?
Die Signatur (hier eben mit sha1) macht doch nichts anderes, als dass sie dir einen "Echtheitssiegel" auf deine Nachricht drückt. Dabei spielt es überhaupt keine Rolle, ob diese Nachricht in Klartext (also nur signiert) oder verschlüsselt gesendet wurde. Die Signatur bestätigt lediglich zweierlei: dass die Nachricht vom Empfänger stammt und dass selbige nach dem Absenden nicht mehr verändert wurde.

Ob ein Angreifer deine "sensible Information" lesen kann oder nicht, hängt also überhaupt nicht von der Signatur, sondern lediglich von der Verschlüsselung ab. Du musst ja nicht mal signieren, kannst doch auch nur verschlüsselt senden.

Die Qualität der Verschlüsselung hängt ab:
- von den beiden verwendeten Algorithmen (dem asymmetrischen und dem symmetrischen)
- von der sachgerechten Implementierung dieser Alg. in das Anwendungsprogramm
- von der Schlüssellänge
- von der Qualität des Zufallszahlengenerators.

Die Algorithmen unterliegen einer ständigen Kontrolle. Und zwar bei veröffentlichten Algorithmen nicht nur von "offizieller Seite", sondern auch durch die Öffentlichkeit. Hier kannst du recht sicher sein, dass Schwachstellen bekannt werden.
Die Schlüssellänge kannst du bei der Erzeugung des Schlüsselpaares selbst festlegen. Es hindert dich niemand, 4K zu nehmen, auch wenn das imho zur Zeit "jenseits von gut und böse" ist.

Die beiden nennenswerten Schwachstellen sind unsachgemäße Implementierungen (egal ob verursacht zu zu geringes Fachwissen oder Vorsatz ...) und auch der so genannte Zufallszahlengenerator des Betriebssystems - der in Wirklichkeit nur ein Pseudozufallszahlengenerator ist. Auf einem Rechner gibt es nämlich keine Zufälle!
Ein echter Zufallszahlengenerator ist nämlich eine "Wissenschaft für sich". Aber das ist hier kein Thema ... .

MfG Peter

Ergänzung:
Habe mir gerade noch einmal deinen Beitrag durchgelesen.
Auch wenn ich nicht der GnuPG-Experte bin ...: Mit dieser Hashfunktion wird der Hash deiner Passphrase im Anhang des private-key gespeichert. Du kannst ja nicht die Passphrase direkt speichern. Also wird der Hash gespeichert und bei Eingabe derselben dessen Hash mit dem gespeicherten verglichen. Das hat nichts mit der Verschlüsselung der Nachricht zu tun, der Angreifer müsste also zuerst deinen private-Key haben, um dann (in einer sehr langwierigen Prozedur) deine Passphrase erraten zu können ... .

O'rallY
20.01.08, 16:20
Also kehren wir wieder auf den privaten Bereich zurück ... .


Ja, ich bitte darum ;).


Die Signatur bestätigt lediglich zweierlei: dass die Nachricht vom Empfänger stammt und dass selbige nach dem Absenden nicht mehr verändert wurde.

Genau dies ist doch das essentielle bei PGP. Eine verschlüsselte Nachricht kann mir jeder schicken. Viel wichtiger ist es doch zu wissen, von wem diese Nachricht kommt und das sie authentisch ist.
Und dort ist die Schwachstelle der benutzte Hashalgorithmus.

Ich hab allerdings mal ein bisschen recherchiert.
Bezogen auf die aktuelle Thematik ist offenbar nur ein Preimage-Angriff relevant (und das logischerweise auch nur, wenn eine Nachricht nicht chiffriert wird). Ein Kollisionsangriff, also das finden zweier Nachrichten, die den gleichen Hash haben, ist ja eigentlich nicht durchzuführen, außer der Angreifer gelangt an den privaten Signierschlüssel.
IMHO wurde durch die Schwachstelle im SHA1 die Anzahl nötiger Operationen, um eine Kollision zu erhalten auf ca. 2^63 gedrückt.
Das bedeutet, das für einen erfolgreichen Preimage-Angriff immer noch ca. 2^126 Operationen von Nöten sind (außer der Angreifer hat außerordentliches Glück ;) ).
Okay, und das ist immer noch verdammt viel. Es erscheint mir doch äußerst unwahrscheinlich, dass ein solcher Angriff realistisch ist, zumal eine gefundene Kollision mit einem gegeben Hash auch aus einem Text resultieren kann, der absolut sinnlos ist.

Ich bin beruhigt. ;) Ich gehe mal davon aus, dass die GnuPG-Entwickler wissen, was sie tun (hoffentlich).

Trotzallem würde mich interessieren, ob man den Signierhash umstellen kann. Und wie wird eigentlich der Private Schlüssel verschlüsselt?

Und wie leicht ist auszunutzen, dass es sich lediglich um einen Pseudozufall handelt?

Fragen über Fragen ;)

lg

/dev/null_Peter
20.01.08, 20:59
Ich bin beruhigt. ;)
<freu>


Trotzallem würde mich interessieren, ob man den Signierhash umstellen kann.
Schau dir mal die Doku genau an. Kann mir nicht vorstellen, dass man das nicht per Schalter einstellen kann.
Wie schon gesagt, bei professionellen Programmen geht das.
Aber denke daran - die Gegenstelle muss es auch können ... .


Und wie wird eigentlich der Private Schlüssel verschlüsselt?
Hier muss dir schon jemand von der "GnuPG-Fraktion" antwortern ... .


Und wie leicht ist auszunutzen, dass es sich lediglich um einen Pseudozufall handelt?
Es hat niemand von "leicht" gesprochen - aber es vereinfacht die Sache ungemein.

Und denke bitte daran: Es gibt Unterschiede zwischen "machbar" und "praktisch handhabbar". JEDE Verschlüsselung (außer dem "one time pad") ist irgendwann einmal zu brechen. Dauert nur ein wenig ... . Und Zeit ist Geld.
Und schon sind wir wieder beim "Zone O-Rechner" ... .

Aber nun ist Schluss ... .

MfG Peter

O'rallY
22.01.08, 17:10
Ich habe die Option gefunden, die das ermöglicht, was ich erreichen möchte: Es wird der erste Hash-Algorithmus gefunden, auf den sich Sender und Empfänger einigen können.

Der Empfänger hinterlegt seine Vorlieben in seinem öffentlichen Schlüssel in den Schlüssel-Preferences. Also z.B.:


gpg --edit-key foo
>setpref {Cipher-Algos} RIPEMD160 SHA256 SHA1 {Kompressionsalgos}
>save


Der Sender hinterlegt allerdings seine Vorlieben beim Senden nicht in seinem Schlüssel. Die dort definierte Reihenfolge gilt für den Schlüsselempfang! Sondern er legt sie in der Einstellungsdatei von gpg ~/.gnupg/gpg.conf fest. Beispiel:


{...}
personal-digest-preferences SHA512 SHA256 RIPEMD160
{...}


In diesem Fall würde der Schlüssel mit SHA256 signiert werden.

Das gleiche gilt übrigens für die Wahl des symmetrischen Verschlüsselungs- und Kompressionsalgorithmusses. Hierführ ist auf der Senderseite die Option personal-cipher-preferences bzw. personal-compress-preferences verantwortlich.


Und wie wird eigentlich der Private Schlüssel verschlüsselt?


--s2k-cipher-algo name
Use name as the cipher algorithm used to protect secret keys. The default cipher is CAST5. This cipher is also used for conventional encryption if --personal-cipher-preferences and --cipher-algo is not given.
--s2k-digest-algo name
Use name as the digest algorithm used to mangle the passphrases. The default algorithm is SHA-1.


Siehe http://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html

thx für die Unterhaltung und Grüße