Der sichere GPG-Schlüssel

Absolut sicher ist wie immer nichts, jeder kann nur versuchen sich so weit wie möglich der Perfektion anzunähern. Nachdem nun bewiesen ist dass einige Organisationen keine Kosten und Mühen scheuen um selbst starke Verschlüsselungen zu brechen.... Ja, da kann man nur versuchen es ihnen so schwer und aufwendig wie nur irgendwie möglich zu machen. Wie? Na da schauen wir doch mal!

Es beginnt mit der Schlüssellänge, diese sollte länger 1024 sein. DSA Schlüssel müssen eine größe zwischen 512 und 1024 Bits haben. Damit sollte man schon mal keinen DSA Schlüssel nutzen, vor allem da DSA von einem ehemaligen NSA-Mitarbeiter entwickelt wurde. ElGamal-Schlüssel hingegen können unbegrenzt groß werden. DSA sowie auch ElGamal-Schlüssel haben ein großes Problem mit schlechten Zufallsgeneratoren. Wird zum Beispiel eine Signatur mit der Hilfe eines schlechten Zufallsgenerators erstellt, lässt sich unter Umständen der private Schlüssel daraus errechnen. Es gibt für RSA theoretische Angriffsszenarien. Für einen 1024 Bit-Schlüssel wäre es eine Maschine welche von Menschen zwar gebaut werden kann, für den Betrieb würde es aber im Moment mehr Energie benötigen als die USA liefen können. Die Jungs schlafen nicht und bei die Faktorisierungsalgorithmen werden immer weiter verbessert, also den Schlüssel aufbohren... Mit den heutigen Rechenleistungen sind 4096 Bit lange Schlüssel kein Problem mehr. Einigen wir uns also für heute auf einen RSA Schlüssel mit einer Länge von 4096 Bit. Für heute? Joar... Quantencomputer könnten in der Zukunft erfolgreiche Angriffe auf RSA Schlüssel fahren. Dazu müsste ein Quantencomputer aber einen Angriff auf den kompletten Schlüssel fahren. Derzeit sind wir bei ~ich glaube~ deutlich unter 10Bit. 

Nun ist der benutzte Algorithmus an der Reihe. Welche Verfahren von seiner GnuPG Version unterstützt werden, zeigt man sich am einfachsten an mit:

$ gpg --version

Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

 

MD5? War das nicht schon lange geknackt? Jappp... MD5 ist ein unsicherer Hashalgorithmus. SHA1 gilt zwar noch als sicher, wird aber auch bald gefressen werden. SHA2 wurde zwar von der NSA entwickelt, es haben aber inzwischen so viele Augen drüber geschaut dass man davon ausgehen kann; hier hat die NSA nichts versteckt! SHA3 ist aktuell noch nicht komplett fertig ~oder?~. Wie auch immer.... Glücklicherweise kann man nun in seinem Schlüssel einstellen was genutzt werden soll und in welcher Reihenfolge. Reihenfolge kann man nicht einfach den „sichersten“ als einzigen einstellen? Ja, kann man.... Jetzt müssten sich nur noch alle auf den vermeintlich sichersten einigen, das umsetzten und wenn etwas schief geht dieses schnell anpassen. Klingt nicht nur so als wenn es nicht klappen wird. Also stellt man mehrere Algorithmen ein die man selbst verwenden möchte. Angenommen ich möchte nun also den Schlüssel mit der ID 0x0F9874D8 (b.t.w.: die kurze ID ist auch nicht mehr sicher) ändern. Dann mache ich dieses mit:

gpg --edit-key 0x0F9874D8

 

Zuerst mal schauen was eingestellt ist:

gpg> showpref
[ uneing.] (1). Sebastian van de Meer (E-Mail Address) kernel-error @ kernel-error.com;
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify

 

Die gewünschten Algorithmen setzte ich mit:

gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB
Setze die Liste der Voreinstellungen auf:
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify
Die Voreinstellungen wirklich ändern? (j/N)

 

Jetzt noch das editieren beenden:

gpg> q
Änderungen speichern? (j/N) j
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 64/32768 bytes in 1 blocks

 

Fertig... Schon arbeitet der Schlüssel nur noch mit den Algorithmen, welchen ich vertrauen möchte.

Welchen Verfahren kann man nun eigentlich noch wirklich vertrauen? Dieses muss natürlich jeder für sich entscheiden.