Hinzufügen einer "Zufallszahlenentropie" für GPG-Schlüssel?


10

Im folgenden Video: Linux-HOWTO: Sichern Sie Ihre Daten mit PGP, Teil 2 , wird gezeigt, wie Sie ein Schlüsselpaar mit erstellen gpg. Ungefähr 1:50sagt der Ausbilder Folgendes:

Während der Schlüsselgenerierung wird empfohlen , die Maus ein wenig zu bewegen, um die Zufallszahlenentropie für die Erstellung des Schlüsselpaars zu erhöhen.

Dies scheint mir ein Mythos zu sein, zumal Befehlszeilentools normalerweise nicht vom Cursor beeinflusst werden sollten. Andererseits habe ich keine Ahnung, wie der Zufallszahlengenerator von Linux funktioniert, ob er von der GUI gemeinsam genutzt wird oder von dieser unabhängig ist. Gibt es einen Bestand in dem, was er behauptet, oder ist dies ein Beispiel für die Programmierung von Frachtkult ?


Ist dies nebenbei die richtige Verwendung des "urbanen Mythos" oder gibt es einen ähnlichen Ausdruck für "Mythos im Computer"?
IQAndreas

1
Ich denke, der Satz ist eine urbane Legende . Ich habe noch nie von urbanen Mythen gehört . Siehe en.wikipedia.org/wiki/Urban_legend Beim Rechnen könnte der Ausdruck "Frachtkult" angemessen sein.
Derobert

Antworten:


8

Das ist ein Körnchen Wahrheit, tatsächlich mehr Wahrheit als Mythos, aber dennoch spiegelt die Aussage ein grundlegendes Missverständnis dessen wider, was vor sich geht. Ja, das Bewegen der Maus beim Generieren eines Schlüssels mit GPG kann eine gute Idee sein. Ja, das Bewegen der Maus trägt zu einer Entropie bei, die Zufallszahlen zufällig macht. Nein, durch Bewegen der Maus wird der Schlüssel nicht sicherer.

Alle guten Zufallsgeneratoren, die für die Kryptografie geeignet sind, und Linux-Generatoren in dieser Kategorie, bestehen aus zwei Komponenten:

  • Eine Entropiequelle , die nicht deterministisch ist. Der Zweck der Entropie besteht darin, den Zufallszahlengenerator mit unvorhersehbaren Daten zu booten. Die Entropiequelle darf nicht deterministisch sein. Andernfalls könnte ein Gegner dieselbe Berechnung reproduzieren.
  • Ein Pseudozufallszahlengenerator , der aus einem sich ändernden internen Zustand deterministisch unvorhersehbare Zufallszahlen erzeugt.

Die Entropie muss von einer Quelle stammen, die sich außerhalb des Computers befindet. Der Benutzer ist eine Entropiequelle. Was der Benutzer tut, ist meistens nicht zufällig, aber das feine Timing von Tastenanschlägen und Mausbewegungen ist so unvorhersehbar, dass es leicht zufällig ist - nicht sehr zufällig, aber nach und nach sammelt es sich an. Andere mögliche Entropiequellen sind das Timing von Netzwerkpaketen und weißem Rauschen von Kamera oder Mikrofon. Unterschiedliche Kernelversionen und -konfigurationen verwenden möglicherweise unterschiedliche Quellen. Einige Computer verfügen über dedizierte Hardware-RNG-Schaltkreise, die auf radioaktivem Zerfall oder weniger eindrucksvoll auf instabilen elektronischen Schaltkreisen basieren. Diese dedizierten Quellen sind besonders nützlich bei eingebetteten Geräten und Servern, die beim ersten Start ein ziemlich vorhersehbares Verhalten aufweisen können, ohne dass ein Benutzer seltsame Dinge tun muss.

Linux stellt Programmen Zufallszahlen über zwei Geräte zur Verfügung: /dev/randomund/dev/urandom . Das Lesen von beiden Geräten gibt eine kryptografische Qualität zurück. Beide Geräte verwenden denselben internen RNG-Status und denselben Algorithmus, um den Status zu transformieren und zufällige Bytes zu erzeugen. Sie haben besondere Einschränkungen, die keinen von ihnen zum richtigen machen:

  • /dev/urandom kann vorhersagbare Daten zurückgeben, wenn das System noch keine ausreichende Entropie angesammelt hat.
  • /dev/randomberechnet die Menge der verfügbaren Entropie und Blöcke, wenn nicht genug vorhanden ist. Dies hört sich gut an, außer dass die Berechnung auf theoretischen Überlegungen basiert, die dazu führen, dass die Menge der verfügbaren Entropie mit jedem Ausgangsbit linear abnimmt. Neigt daher /dev/randomdazu, sehr schnell zu blockieren.

Linux-Systeme speichern den internen RNG-Status auf der Festplatte und stellen ihn beim Start wieder her. Daher überträgt sich die Entropie von einem Schuh zum nächsten. Das einzige Mal, wenn einem Linux-System die Entropie fehlt, ist die Neuinstallation. Sobald das System eine ausreichende Entropie aufweist, nimmt die Entropie nicht ab. Nur die fehlerhafte Berechnung von Linux nimmt ab. Für weitere Erklärungen dieser Überlegung /dev/urandomeignet sich read zum Generieren eines kryptografischen Schlüssels durch einen professionellen Kryptographen. Siehe aso Can erklären Sie sich die Entropie Schätzung in random.c verwendet .

Durch Bewegen der Maus wird dem System mehr Entropie hinzugefügt. Aber gpg kann nur aus lesen /dev/random, nicht/dev/urandom (einem Weg , um dieses Problem zu lösen ist , um /dev/randomdas gleiche 1: 9 - Gerät wie /dev/urandom), so dass es nie in Gefahr Aufnahme nicht-zufall genug Zufallszahlen ist. Wenn Sie die Maus nicht bewegen, ist die Taste so zufällig wie möglich. aber was passieren kann ist, dass gpg in einem Lesevorgang blockiert wird/dev/random und darauf wartet, dass der Entropiezähler des Kernels steigt.


Mit Ausnahme der aktuellen Linux-Versionen werden Eingabegeräte zumindest nach meinen Tests nicht als Entropiequelle (oder zumindest als geschätzte Entropiequelle) verwendet. Ich bin mir ziemlich sicher, dass sie das geändert haben, weil sie theoretisch unter der Kontrolle eines Angreifers sein könnten.
Derobert

@derobert Ab 3.12 gibt es einen Aufruf von add_input_randomnessin drivers/input/input.c, aber ich weiß nicht, unter welchen Umständen es tatsächlich Entropie injiziert.
Gilles 'SO - hör auf böse zu sein'

Ich vermute, es fügt Entropie hinzu, aber mit einer Schätzung von 0 ... Ich habe sowohl eine USB-Maus als auch eine PS / 2-Tastatur ausprobiert, und beide schienen die Entropieschätzung nicht zu erhöhen. Ich bin mir nicht sicher warum, da ich den Aufruf von credit_entropy_bits im Code sehe.
Derobert

3

GPG verwendet den Linux (Kernel) Zufallszahlengenerator. Der Kernelgenerator erhält Entropie (Zufälligkeit) von allen Arten von Orten, darunter das Interrupt-Timing für bestimmte Interrupts. Durch Bewegen der Maus (und Tippen, Festplattenaktivität usw.) werden Interrupts generiert.

Das Bewegen der Maus wird also möglicherweise in den Zufallszahlengenerator eingespeist. Ob dies jedoch der Fall ist, hängt von der genauen verwendeten Kernelversion ab. Neuere Versionen verwenden (zumindest in meinen Tests) keine Tastatur- oder Maus-Interrupts für die Entropie. Die Festplattenaktivität ist jedoch aktiv (z. B. führt das Ausführen zu synceiner potenziell großen Menge an Entropie, je nachdem, wie viel gespült wird).

Kurz gesagt: Dies gilt nicht für aktuelle Linux-Versionen. Es war bei älteren.

Wenn dem Generator jedoch die Entropie ausgeht, sollte er einfach anhalten. Ihre Schlüsselgenerierung bleibt also hängen, bis eine gewisse Entropie generiert wird. Es wäre also ein ewiges Problem, kein Sicherheitsproblem.

Sie können sehen, wie viel Entropie von verfügbar ist cat /proc/sys/kernel/random/entropy_avail.


Beachten Sie auch, dass Sie Werkzeuge verwenden können rngd, um den Entropiepool künstlich zu versorgen.
Patrick

@Patrick in der Tat, und wenn Sie einen neuen Chip haben und der NSA vertrauen (oh, warte, ich meine, Intel), könnten Sie RDRAND verwenden.
Derobert

havegedEs ist ein weiteres gutes Werkzeug, um den Entropiepool künstlich zu versorgen.
Mavillan

Das ist nicht die ganze Geschichte - dem RNG geht nicht die Entropie aus, es geht ihm das interne Maß der Entropie aus. Ein wichtiger Teil des Puzzles ist auch, dass sich gpg nicht um die Maus kümmert, sondern um den Kernel.
Gilles 'SO - hör auf böse zu sein'

@ Gilles Ich habe klargestellt, dass gpg das Linux RNG verwendet. Und Fehler im Entropieschätzer scheinen den Rahmen zu sprengen.
Derobert

0

Tails hat eine extrem schnelle Schlüsselgenerierung, weil es havegedinstalliert hat:

sudo apt-get install haveged
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.