Woher kommt die Entropie/seed bei ssh-keygen?



  • Wenn ich

    ssh-keygen -b 4096

    aufrufe, woher kommt dann die Entropie für den Schlüssel? Basiert das "nur" auf der Systemzeit?



  • Das ist an sich eine gute Frage. Ich hoffe, ich kann sie einigermaßen gut beantworten:

    Die Qualität der tatsächlichen Entropie ist sehr wichtig bei Zufallszahlen in der Kryptografie. Auch wenn es sehr schwierig ist, die "tatsächliche" Entropie z. B. in einem 128-bit Zufallswert zu bestimmen (bestenfalls wären es wirklich 128 Bit), die Systemzeit erfüllt definitiv nicht solche Anforderungen.

    Sollte es einem Angreifer gelingen, vorherzusagen bzw. zu erraten, welche Systemzeit als Seedwert vorhanden war, und mit welchen PRNG / Verfahren daraus der Schlüssel generiert wurde, könnte diese/r theoretisch den Schlüssel rekonstruieren, zumindest um ein vielfaches einfacher, als es normalerweise von einem 4096-Bit RSA Schlüssel zu erwarten wäre.

    Es ist auch wichtig zu verstehen, dass die typischen Zufallszahlengeneratoren wie std::rand, std::mt19937 usw. (z. B. Mersenne Twister) nicht kryptografischen Anforderungen standhalten, auch wenn ihre Verteilung an sich evtl. recht gut ist (es soll auch sichergestellt sein, dass man aus beobachteter Ausgabe/Zustand eines Generators nicht einfach auf vorherige oder nachfolgende [Pseudo-]Zufallsbits Rückschlüsse ziehen kann).

    Auf Windows bietet sich vermutlich BCryptGenRandom an. Unter GNU/Linux normalerweise /dev/urandom. Manchmal gibt es auch HW-basierte Befehle wie Intel RDRAND. Wenn ich aber jemals an den Punkt komme, wo ich selbst im Code sowas eintippe, muss ich mal Pause machen und ganz scharf nachdenken, ob das wirklich eine gute Idee ist (i. d. R. nicht).

    OpenSSH scheint hier im Hintergrund über sshkey.c usw. OpenSSL zu verwenden (z. B. RSA_generate_key_ex für RSA Schlüssel).
    Es ist für mich etwas schwierig, das im Quellcode nachzuverfolgen, da es auch verschiedene "deprecated" Funktionen, Versionen, etc. gibt.
    OpenSSL ist schon ein Beast... aber:

    NOTES
    By default, the OpenSSL CSPRNG supports a security level of 256 bits, provided it was able to seed itself from a trusted entropy source. On all major platforms supported by OpenSSL (including the Unix-like platforms and Windows), OpenSSL is configured to automatically seed the CSPRNG on first use using the operating systems's random generator.

    EVP_RAND_generate() produces random bytes from the RAND ctx with the additional input addin of length addin_len. The bytes produced will meet the security strength. If prediction_resistance is specified, fresh entropy from a live source will be sought. This call operates as per NIST SP 800-90A and SP 800-90C.

    Unterm Strich wird OpenSSL versuchen, die bestmögliche Entropiequelle auf dem System zu benutzen, und es sollte auch Fehler geben, falls nicht ausreichend Entropie erhalten wurde.

    `*Vielleicht noch ergänzend: Woher nimmt dann ein Betriebssystem seine Entropiequelle, wenn nicht die Systemzeit? Bestenfalls viele verschiedene Größen, welche auch aus der physischen/analogen Umgebung kommen.

    • Temperatur(en)
    • Akustische Signale (Lärm)
    • Elektrisches oder sonstiges Rauschen
    • Luftverwirbelungen

    Solche "physisch"-basierten Entropiequellen sind aber nicht immer einfach verfügbar bzw. einfach auszuwerten. Daher nimmt man oft noch weitere Größen aus dem Betriebssystem, z. B.:

    • Daten angeschlossener Sensoren
    • Ein- und Ausgabegeräte
    • Netzwerk- und/oder Laufwerkaktivität
    • System Logs
    • Laufende Prozesse
    • Nutzeraktivität wie Bedienung der Tastatur und Maus
    • Bzw. übergreifend: Interrupts und Zeiten dazwischen.

    Das ist natürlich auch nicht 100% failsafe. Einige solcher Parameter lassen sich evtl. auch beeinflussen. Ganz extrem sind auch Ansätze, die aber in einem herkömmlichen Computer vermutlich nicht realistisch anwendbar sind, z. B.:

    • Radioaktiver Zerfall
    • Irgendwelche Quantenfluktuationen
    • Polarisation von Photonen

    Da es also gar nicht so leicht ist, große Mengen verlässlichen "Zufall" oder "Entropie" zu bekommen, verwendet man in der Praxis eine Kombination aus solchen "echten" Zufallsquellen und speziell für kryptografische Anwendungen konzipierte Pseudo-Zufallsgeneratoren, welche diese teils unzuverlässigen wenigen Bits ein eine viel längere und hochwertige Sequenz von Pseudo-Zufallsbits erweitern.

    S. beispielsweise auch:



  • Herzlichen Dank für Deine/Ihre Antwort. 🙂 Es wurden schon alle Fälle beantwortet, zu denen ich evtl. noch Fragen gehabt hätte.

    Ich glaube, am sub-optimalsten bzw. "dämlichsten" (bzw. am optimalsten für einen Angreifer) wäre es, wenn das System, welches den Schlüssel generieren möchte, den Zeitpunkt oder weitere Parameter "mitloggen" würde.

    Manche Programme zeigen auch so ein Sichtfeld an, wobei Entropie für den Schlüssel über Mausbewegungen gesammelt wird (bei veracrypt zum Beispiel) ... bei ssh-keygen(.exe) ist dies aber nicht so.



  • @Fragender sagte in Woher kommt die Entropie/seed bei ssh-keygen?:

    Ich glaube, am sub-optimalsten bzw. "dämlichsten" (bzw. am optimalsten für einen Angreifer) wäre es, wenn das System, welches den Schlüssel generieren möchte, den Zeitpunkt oder weitere Parameter "mitloggen" würde.

    Das braucht man gar nicht.

    Nehmen wir mal an, ein 128 BIt Schlüssel wird mit srand(time()) generiert. Und die damit verschlüsselte Nachricht wurde abgefangen.

    Da Security through obscurity meistens sehr schlecht funktioniert, weis der Angreifer folgendes:

    • Der Schlüssel wurde mit srand(time()) generiert
    • Der Schlüssel ist vermutlich nicht älter als 2 Tage

    2 Tage heißt 2 * 24 h * 60 min / h * 60 s / min = 172800 s . Und da time() Sekunden zurückliefert, zählt man halt alle 172800 vergangene Kombinationen für den aktuellen time() auf, generiert damit einen 128 Bit Schlüssel und versucht damit die Nachricht zu entschlüsseln.

    172800 sind nicht viele Kombinationen.

    Im schlimmsten Fall muss man 21282^{128} BIt Kombinationen = 340282300000000000000000000000000000000 Kombinationen ausprobieren.

    340282300000000000000000000000000000000 Kombinationen zu
                                     172800 Kombinationen
    

    das ist der Unterschied.



  • @Fragender Man kann auch die Zeiten zwischen den Anschlägen bei der Eingabe der Passphrase benutzen.



  • @Quiche-Lorraine sagte in Woher kommt die Entropie/seed bei ssh-keygen?:

    Das braucht man gar nicht.

    wahr.

    @DirkB sagte in Woher kommt die Entropie/seed bei ssh-keygen?:

    Man kann auch die Zeiten zwischen den Anschlägen bei der Eingabe der Passphrase benutzen.

    Das könnte man ... aber zumindest ich vergebe nie eine Passphrase, weil ich die dann ja immer wieder eintippen muss ... etwas Bequemlichkeit ...


Anmelden zum Antworten