To main content

GnuPG für Paranoide

Veröffentlicht von Benjamin Marwell am
GnuPG Logo ohne Text
GnuPG-Logo

RSA/DSA ist nicht sicher genug? Viel Bits alleine helfen viel? Von wegen! Falsche Einstellungen können Kommunikation unmöglich und Signaturen nicht verifizierbar machen. Wie man unnötige Stärke aus beidem herausholt, soll dieser Artikel anreißen. Er richtet sich an fortgeschrittene PGP-Nutzer, die mit Subkeys, Schlüsselpaaren und -größen, sowie Signaturen und Linux sicher umgehen können.

Vorweg: Die folgenden Einstellungen sind überheblich und auch etwas blödsinnig. Wer sich einen Standardschlüssel  erstellt, dürfte wohl auch die nächsten fünf bis zehn Jahre noch sicher kommunizieren können. Zumindest geht heute kaum jemand von so gravierenden Schwächen in den von GnuPG verwendeten Algorithmen aus, dass sich das ändern könnte.

Gute Schlüssel sind stark, schnell berechnet und überall lesbar. Das man diesen Spagat hinbekommt, wird im folgenden gezeigt.

Die Präferenzen

Der Befehl setpref  setzt bei GnuPG vorzugsweise zu verwendende Einstellungen. Diese werden praktischer Weise in dem Schlüssel gespeichert. Damit lässt sich also ein fremdes Programm anweisen, dass es einen bestimmten Hash - falls verfügbar - bevorzugen soll, oder halt einen bestimmten Algorithmus bzw. ein bestimmtes Kompressionsverfahren. Zusätzlich kann man mit --s2k-(digest|cipher)-algo  noch bestimmen, mit welchen Algorithmen der Schlüssel erstellt werden soll. Damit wird die Verwendung des angerissenen SHA-1 auf ein Minimum reduziert, auch wird jetzt AES-256 genutzt. SHA-1 wird wie gesagt somit nur auf ein Minimum reduziert. Niemand kann verhindern, dass man doch noch eine verschlüsselte Mail mit SHA-1-Hash bekommt. Das liegt vor allem an der Abwärtskompatiblität. Dazu müsste die Gegenstelle aber ein sehr altes Programm nutzen.

Das signierende Schlüsselpaar

RSA oder DSA oder das erweiterte DSA (alias DSA2)?

Das normale DSA basiert auf SHA-1-Hashes. Diese gelten als geknackt - wenn auch noch nicht für falsche Signaturen geeignet. Außerdem scheinen 1024Bit (die Obergrenze) recht wenig, trotz der Stärke des Algorithmus. DSA2 ist leider noch zu neu, so dass es eventuell nicht überall unterstützt wird. Dafür bietet es auch modernere Hashes wie SHA-256 an. Der neue DSA-Algorithmus unterstützt auch bis zu 3072Bit Keylänge. Leider werden die genutzten Hashes nicht mitsigniert, wie bei RSA. Das macht ihn - wenn auch nur theoretisch - verwundbarer. Geringe Verbreitung und die fehlende "Hash-Firewall", wie das Mitsignieren des Algorithmus heißt, sprechen leicht gegen ihn.

RSA ist in Stein gemeißelt, könnte man meinen. Schon lange auf dem Markt, dafür aber auch gut getestet. RSA unterstützt diverse Hashes, implementiert die oben genannte Hash-Firewall und kann auf 4096bit aufgeblasen werden. Wer will, kann RSA gleich zum Verschlüsseln mitnutzen, was aber als "bad habbit" gilt. Zum Signieren ist er aber derzeit wohl besser als DSA geeignet.

Als Hash könnte SHA-384 in betracht kommen. 512Bit sind sicherlich oversized, 256 beschneiden aber wiederum die Sicherheit ein wenig. An sich ist auch ein 384er etwas zu viel, aber lieber zu viel als zu wenig. Es geht ja um Paranoia ;-)

Und so erstellt man es mit starkem Hash:
$ gpg --gen-key --expert --digest-algo SHA384 --cipher-algo AES256 --s2k-cipher-algo AES256 --digest-algo SHA384
gnupg> (5) RSA (nur signieren)
gnupg> 4096bit Schlüssellänge
gnupg> gpg --edit-key --expert --digest-algo SHA512 --cipher-algo AES256 --s2k-cipher-algo AES256 --digest-algo SHA384
gnupg> setpref AES256 AES192 AES CAST5 3DES SHA384 SHA256 RIPEMD160 SHA1 BZIP2 ZLIB ZIP
gnupg> save

Das verschlüsselnde Schlüsselpaar

Es wird ein zweites Schlüsselpaar erstellt, der so genannte "Subkey". Dieser wird entweder wieder ein RSA-Key oder ein ElGamal. Nun, ich entscheide mich für ElGamal. Ihm wird nachgesagt, mehr Sicherheit pro Bit zu bieten. Da sowohl RSA und ElGamal derzeit Größen von bis zu 4096Bit annehmen können, fällt die Entscheidung hier etwas einfacher.

Lesend werden übrigens auch größere Schlüssel erlaubt. Um diese freizuschalten, muss man GnuPG aber neu kompilieren. Außerdem bringt es nichts - naja doch, man kann seine CPU beim Verschlüsseln als Heizplatte verwenden. ;-)

Und so erstellt man den Unterschlüssel:
$ gpg --edit-key --expert --digest-algo SHA512 --cipher-algo AES256 --s2k-cipher-algo AES256 --digest-algo SHA384
gnupg> (4) Elgamal (nur verschlüsseln)
gnupg> 4096bit Schlüssellänge
gnupg> save
Damit ist der sichere Schlüssel erstellt. Kann es losgehen? Fast!

Konfiguration anpassen

Jetzt noch schnell folgende Datei editiert: ~/.gnupg/gpg.conf . Dort tragen wir ein:
personal-digest-preferences SHA384
personal-cipher-preferences AES256

Auf gar keinen Fall darf hier das "personal" vergessen werden! Sonst erstellt man nämlich für JEDEN signierenden Schlüssel SHA-384-gehashte Signaturen. Und das führt bei DSA mit 1024Bit zu ungültigen Signaturen, da SHA-384 bei DSA laut OpenPGP-Standard nicht vorgesehen ist.

Der Vergleich

Ich habe just einen Schlüssel wie oben genannt erstellt und eine Datei signiert. Ob es geklappt hat, erkennt man mit gnupg --verify -v .

Am Beispiel wird hier das aktuelle Ubuntu-Image mit meinem persönlichen Key (1024Bit DSA, SHA1-Hash) und dem eben erstellen (4096Bit RSA, SHA384-Hash) signiert und verglichen.

Der Befehl zum Erstellen der Signatur lautete:
$ /usr/bin/time -p gpg -u [d|r]sa_user -sba --personal-digest-preferences SHA384 -o ubuntu-9.04-desktop-i386.iso.[d|r]sa_user.asc ubuntu-9.04-desktop-i386.iso
Zum Verifizieren gilt Analog:
$ /usr/bin/time -p gpg --verify -v ubuntu-9.04-desktop-i386.iso.[d|r]sa_user.asc
Die Tests wurden durchgeführt auf einem AMD Athlon(tm) 64 3200+, Kernel 2.6.28-12-generic, Ubuntu 9.04 Jaunty.
Aktion/AlgorithmusDSA 1024BitRSA 4096Bit
Benutzer HashSHA-1SHA-384
Dauer des Signierens6,55 s9,91 s
Dauer des Verifizierens8,38 s10,95 s
Größe der Signatur197 Byte835 Byte
Es gilt: Je größer der RSA-Schlüssel, desto großer die Signatur. Das gilt bei DSA nicht: Dort ist die Signatur stärker vom Verwendeten Hash abhängig.

Fazit

RSA-Schlüssel bringen ein großes Sicherheitsplus auf Kosten der Signaturgröße und der Rechenzeit. Auch wenn hier der Unterschied gering aussieht, so handelt es sich doch immerhin um die 1,3- bis 1,5-fache Rechenzeit, sowie um mehr als viermal so große Signaturen. Das kann ein Problem werden, wenn Daten auf einem Blackberry oder PDA signiert oder geprüft werden sollen. Der Einsatz von DSA/ElGamal-Schlüsseln mit einer Größe von 1024/2048Bit ist derzeit noch absolut ausreichend und wird es auch noch lange bleiben.

RSA vs. ElGamal habe ich hier nicht verglichen, das wird vielleicht noch nachgereicht. Da es aber derzeit keine großen Sicherheitsbedenken zu ElGamal oder RSA gibt, ist dieser Punkt sowieso nicht zu interessant. Nicht ohne Grund ist der Standard noch bei 1024/2048 - es genügt einfach für über 90% der Nutzer. Wer irgendwann sichere Schlüssel braucht, kann immer noch umsteigen. Der Sinn und Zweck wird aber für schätzungsweise mindestens fünf - wenn nicht sogar zehn Jahre nicht gegeben sein. Zwar möchte ich meine Hand hier nicht ins Feuer legen, aber selbst ein als "geknackt" bezeichneter Algorithmus ist immer noch weit davon entfernt, für falsche Signaturen verwendet werden zu können.

Aus firmentauglicher Sicht besteht somit kein Grund zum Wechsel. Besteht einer, wrid es groß durch die Medien gehen, außerdem werden die GnuPG-Entwickler bei --gen-key den Standard entsprechend ändern. Eventuell wird demnächst auf RSA-Keys gewechselt, aber das blebit noch abzuwarten. In der aktuellen Version 1.4.9 wird zumindest noch auf DSA/ElGamal gesetzt.

Weiterlesen

Wer Interesse hat sich weiter zu informieren, kann dieses bei folgenden Anlaufstellen tun: