[Erledigt] PGP-Schlüssel-Erstellung unterschiedlich.

[ottonormal]

Hallo,

ich habe zu Testzwecken ein PGP-Schlüsselpaar zwei mal erstellt, einmal mit Seahorse und einmal mit dem Firefox Add-on Mailvelope. Bei beiden habe ich die gleichen Daten (Name, E-Mail, Größe, Passwort usw.) benutzt.
Die Erstellung dauerte mit Mailvelope ca. 12 Sekunden, mit Seahorse aber ca. 10 Minuten, also erheblich länger. Ich habe dann von beiden die Schlüssel exportiert und verglichen. Der private Schlüssel von Mailvelope hat 6501 Zeichen, der private Schlüssel von Seahorse hat 6505 Zeichen, also beide so gut wie gleich.
Was ist also an den Schlüsseln anders, warum dauert die Erstellung soo unterschiedlich lange, ist der schnellerstellte Schlüssel von Mailvelope weniger sicher?

Kann mich jemand aufklären?

Gruß, ottonormal

[DeletedUserReAsG]

PGP kenne ich nun nicht, aber mit GnuPG kannst du dir Eigenschaften der Schlüssel anzeigen lassen. Wenn da alles gleich ist, mag es an der Entropie gelegen haben. Wenn du beide Schlüssel nacheinander erstellt hast, könntest du beim ersten Mal den Pool geleert haben, so das es beim zweiten Mal auf Zufall warten musste. Abhilfe würde in dem Fall sowas wie haveged schaffen, das Entropie aus verschiedenen Quellen organisiert.

[ottonormal]

PGP kenne ich nun nicht...

Naja, wenn ich in Seahorse auf "Neu" gehe, wird mir unter anderem die Erstellung eines "PGP"-Schlüssels zur Auswahl angeboten. Auch in dieser Anleitung: https://wiki.piratenpartei.de/HowTo_PGP ist die Rede von PGP-Schlüsseln obwohl unter Linux die Erstellung mit

Code: Alles auswählen

gpg --gen-key

gestartet wird. Es sind auch beide Schlüssel unabhängig voneinander, den schnellen Schlüssel in Mailvelope habe ich zuerst erstellt, der wird auch nur in Mailvelope im Firefoxordner gespeichert. Der langsame Seahose-Schlüssel befindet sich in /home/nutzername/.gnupg

[wanne]

Ja. Und Openssl braucht 0.2s

Code: Alles auswählen

time openssl genrsa 4096

real    0m0.285s                                                                                                                      
user    0m0.280s                                                                                                                      
sys     0m0.000s

Prinzipiell kann es da ein paar Gründe geben:

• Zuerstmal was sind das für Schlüssel. Typischerweise wird heute RSA-4096 genutzt. gpg2 nutzt per default aber noch RSA-2084. Einige nutzen auch RSA-1024 Was um einen Bruchteil so rechenaufwendig ist. oder Elgamal. openssl braucht für RSA-4096 typischerweise über 10 mal so lange wie für RSA-2048. Aber dann handelt es sich immer im Bereich von unter zwei Sekunden. Du kannst mal mit pgpdump gucken, was du da nutzt. Gleiche Dateilänge spricht aber für gleichen algorithmus
• Zum zweiten wird da mit sehr großen Zahlen gearbeitet. Sowas kann ein Rechner nicht per default muss man erst selber programmieren. Und gerade bei Primzahltests kann man viel optimieren. Da wurde einfach oft Unterscheidlich stark optimiert. Die setzen alle probabilistische Tests wild auf irgend welche ungeraden Zahlen ein. Einige testen zuerst ob durch 7 (Quersummenregel) teilbar. Und sorgen ab der 2. dass keine vielfachen von 3 (relativ wahrscheinnlich)erwischt werden. Bessere brechen ab, wenn die Wahrscheinlichkeit, die eines Rechenfehlers der CPU übersteigt. andere machen noch eine weile Weiter. Wenn ich da was schreiben würde wäre man da wahrscheinlich eher bei (ein paar?) 10 Sekunden für RSA-4096 statt bei unter einer von openssl und auch nur wenn ich die gmp nutzen darf. Wenn man da Webentwickler da was mit JS machen sind da bestimmt auch ein paar Minuten drin, wenn die nicht die Primitiva im Browser nutzen.)
• Manchmal Läufts auch einfach dumm und einem will einfach keine Primzahl finden. Da ist auch nochmal ein faktor 4 oder so gerne drin.
• Vor allem aber ist da der Zufallsgenerator. Schnellere Programme nutzen einfach /dev/urandom, wo Linux kryptografisch sichere pseudo-Zufallszahlen bereitstellt. Dümmere versuchen das sich selbst irgend wie zusammenzufuseln indem sie pids/uhrzeiten abstände zwischen Tastendrücken und anderem zusammensuchen. Das dauert dann extrem lange ist unsicherer funktioniert dafür auch unter windows. Andere alla gpg sind super paranoid und versuchen wirklich nur Zufall in den eigenen pseudo-Zufallsgenerator zu seeden. Das wird dann über irgend welche Hacks mt /dev/random versucht

[ottonormal]

Danke für die Antworten.
Ich habe mal 3 Bilder von den Schlüsseleigenschaften gemacht:

http://www.pic-upload.de/view-31755072/1.png.html
http://www.pic-upload.de/view-31755074/2.png.html
http://www.pic-upload.de/view-31755073/3.png.html

In jedem Bild ist das obere Fenster vom Mailvelope-Schlüssel, der untere Teil ist vom Seahorse-Schlüssel. Der einzige Unterschied den ich erkennen kann, ist auf Bild Nr. 1. Da heißt es bei "Gültigkeit" und bei "Sie verlassen sich auf Zertifizierungen": "unbekannt".
In den Schlüsseldetails von Mailvelope steht aber unter Status "gültig". Diese Unterschiede kommen aber wohl dadurch, dass ich den Schlüssel aus Mailvelope exportiert und in Enigmail (Thunderbird) importiert habe. Von da sind dann die Bilder der Schlüsseleigenschaften gemacht worden.

Es ist ja so, dass beide Schlüssel funktionieren, ich habe auch schon mehrere Schlüssel mit Mailvelope und Seahorse bzw. mit dem Terminal erstellt. Immer war es so, dass die Zeitunterschiede so gravierend waren wie oben beschrieben. Im Prinzip stört mich das auch nicht weiter, ich habe nur irgendwie das Gefühl, dass ein Schlüssel der nur ein paar Sekunden zur Erstellung braucht, qualitativ nicht so gut und sicher sein kann wie bei einem Schlüssel der dazu auf gleichem Rechner gut 10 Minuten braucht.

[wanne]

Ja. Jedes mal RSA-4096.
Ich sehe da das genaue Gegenteil: Der Schlüssel der im Sekundenbereich generiert wird und schnell läuft, dürfte /dev/urandom bzw. die C-Funktion getrandom() seit Kernel Version 3.17 sein.
Das Ding ist einer der bekanntesten kryptografisch sicheren PRNG, und dürfte wohl sehr gut untersucht und sicher sein. Er wird in Linux von vorne herein mit allen zufälligen Ereignissen, die die Linux-Hardware so her gibt seit dem Systemstart gefüttert. (Je nach Konfiguration speichert er sich sogar einige von der letzten Sitzung.)
Was lange dauert nutzt sein eigenes Zeug (die frage ist dann ob man dem Linux Kernel oder Software eher zutraut einen sauberen PRNG zu bauen) und muss sich seinen Zufall erst mal zusammensuchen. Was natürlich typischerweise deutlich weniger ist, als das was seit dem Systemstart angefallen ist.

Problematisch ist die /dev/urandom-Methode nur, wenn sie direkt nach dem Systemstart ausgeführt wird und die Entropie nicht über mehrere boots gespeichert wird. (Unter debian ist der Dienst urandom aus initscripts dafür zuständig. Der lässt sich nicht deinstallieren und ist per default an.) Deswegen nutzen einige Programme /dev/random, dass Zufallszahlen absichtlich so langsam herausgibt, dass jederzeit genug Zufall einfließt. Das ist dann langsam. Einige suchen sich den Zufall auch irgend wie zusammen.

[DeletedUserReAsG]

Was lange dauert nutzt sein eigenes Zeug (die frage ist dann ob man dem Linux Kernel oder Software eher zutraut einen sauberen PRNG zu bauen) und muss sich seinen Zufall erst mal zusammensuchen.

Oder nutzt halt /dev/random – das ist ohne entsprechende Maßnahmen ziemlich langsam. Wenn’s wirklich interessiert, könnte man testweise haveged installieren und starten und schauen, ob die vormals lange Schlüsselerzeugung dann schneller abläuft. Wenn ja, wurde wohl /dev/random genutzt.

[wanne]

Oder nutzt halt /dev/random – das ist ohne entsprechende Maßnahmen ziemlich langsam. Wenn’s wirklich interessiert, könnte man testweise haveged installieren und starten und schauen, ob die vormals lange Schlüsselerzeugung dann schneller abläuft. Wenn ja, wurde wohl /dev/random genutzt.

So habe mir mal beide Programme auf Wikipedia angeguckt. Seahorse nutzt im Hintergrund gpg von Werner Koch. Der Typ ist hochgradig paranoid was seine Software angeht und so gestaltet sich wohl auch sein Zufallsgenerartor. Der CSPRNG ist wohl Eigenbau, nach einem wissenschaftilch anerkanntem Algorithmus, weil man dem OS nicht traut. (alternativ lässt sich der vom NIST nutzen, das mach aber niemand bei Verstand. <ironie>Die sind bekannt für ihre guten Zufallszahlen.</ironie>)
Füttern tut sich das ganze so aus allem möglichen. /dev/random; /dev/urandom und alles an was das Ding sonst noch so rankommt. Weil einem anderen Vertrauen will man ja lieber nicht.

Sourcecode gibt es da: https://github.com/Chronic-Dev/libgcryp ... m-csprng.c

Mailvelope ist dagegen eine Browserextention und kann entsprechend nur den Random nehmen der im der jeweilige Browser gibt. (macht er auch https://github.com/openpgpjs/openpgpjs/ ... /random.js ) Wie gut die sind musst du die Browserhersteller fragen. Kp. und habe auch kein Bock mich durch deren Müllhalden zu wühlen. Auf der anderen Seite dürften auch die ziemlich bulletproofed sein. Da haben ja garantiert schon mehr rumprobiert. Ist ja so garantiert eines von den beliebtesten Angriffszielen. Auf der anderen Seite traue ich denen nicht so richtig über den weg. Da ändert sich einfach pro tag viel zu viel, als dass da noch einer den Überblick über die Sicherheit haben könnte.

Mailvelope sourcen gibts da: https://github.com/openpgpjs/openpgpjs https://openpgpjs.org/ Kannst ja mal im debuger gucken, was da so lange braucht. Die eigentliche Rechnerei geschieht da: https://github.com/openpgpjs/openpgpjs/ ... key/rsa.js
Zufall kommt daher: https://github.com/openpgpjs/openpgpjs/ ... /random.js

[wanne]

So habe gerade mal versucht im Chrome zu debugen. Finde da irgend wie wenig übereinstimmung mit dem Source auf github . Blicks vorne und hinten nicht. Habe aber auch keine Ahnung von JS. Sollte einfach die Finger lassen von zeug, das man nicht kapiert.

[ottonormal]

O Mann, wat'n komplizierten Kram. Also einerseits lese ich daraus, dass man den schnellen Mailvelope-Schlüssel bedenkenlos nutzen kann, andererseits auch wieder lieber nicht. Wenn man also etwas paranoider ist, lieber doch der langsamen Methode den Vorzug geben? Ich glaub, so werde ich es dann in Zukunft machen, sicher ist sicher. Der langsame Schlüssel lässt sich ja dann problemlos in Mailvelope importieren.

Danke also noch einmal für die Erklärungen (auch wenn ich nicht alles davon verstehe ).