Java SecureRandom blockiert nicht? Wie?

Question

view on stackexchange narkive permalink

Ich weiß aus Erfahrung, dass das Lesen aus / dev / random-Blöcken, wenn dem Entropiepool des Linux-Kernels die Entropie ausgeht. Außerdem habe ich viele Artikel und Blogeinträge gesehen, die besagen, dass java.security.SecureRandom unter Linux / dev / random als Entropiequelle verwendet und somit blockiert, wenn dem Kernel-Entropie-Pool die Entropie ausgeht.

Ich kann jedoch kein Experiment erstellen, bei dem SecureRandom blockiert wird. Umgekehrt scheint es einfach zu sein, einen einfachen Bash-Einzeiler zu erhalten, der von / dev / random bis block liest.

Hier ist der Java-Code, den ich für diese Experimente verwende:

  import java.security.SecureRandom; öffentliche Klasse A {public static void main (String [] args) {SecureRandom sr = new SecureRandom (); int out = 0; für (int i = 0; i < 1<<20; i ++) {out ^ = sr.nextInt (); } System.out.println (out); }}  

Es werden etwas mehr als 1.000.000 zufällige 32-Bit-Ganzzahlen generiert. Das sollten 2 ^ (20 + log2 (32)) = 2 ^ 25 Bits oder 2 ^ 22 (etwas mehr als 4 Millionen) Byte Entropie sein, oder? Es blockiert jedoch nie. Es endet immer in ungefähr 1,2 Sekunden, egal ob ich mit der Maus wackle oder nicht.

Der von mir verwendete Bash-Einzeiler ist:

  head -c 100 / dev / zufällig | xxd  

Dies blockiert leicht. Solange ich meine Hand von Maus und Tastatur fern halte, bleibt sie einige Minuten lang stehen und tut nichts. Und ich bitte nur um 100 Byte Entropie.

Sicher fehlt mir hier etwas. Könnte jemand erklären, was los ist?

Danke!

Answer 1

view on stackexchange narkive permalink

Sowohl OpenJDK als auch Sun lesen von / dev / urandom , nicht von / dev / random , zumindest auf dem Computer, auf dem ich getestet habe (OpenJDK JRE 6b27 und Sun JRE 6.26) auf Debian Squeeze amd64). Aus irgendeinem Grund öffnen beide auch / dev / random , lesen aber nie daraus. Die Blog-Artikel, die Sie gelesen haben, waren entweder falsch oder wurden auf eine andere Version als meine (und anscheinend Ihre) angewendet.

Sie können überprüfen, ob Ihre von / dev / random liest oder / dev / urandom durch Verfolgung:

  strace -o a.strace -f -e Datei Java A  

und suchen Sie nach dem relevanten Teil der Ablaufverfolgung:

  21165 open ("/ dev / random", O_RDONLY) = 6… 21165 open ("/ dev / urandom", O_RDONLY) = 7… 21165 read (7, "\ 322 \ 223 \ 211 \ 262Zs \ 300 \ 345 \ 3264l \ 254 \ 354 [\ 6wS \ 326q @", 20) = 20…  

Don ' Keine Sorge, / dev / urandom ist für die Kryptografie vollkommen in Ordnung.

Answer 2

view on stackexchange narkive permalink

Javas SecureRandom verwendet / dev / random, jedoch nur kurz.

Insbesondere wird es nur beim Generieren von Startinformationen verwendet, entweder durch expliziten Aufruf von SecureRandom.generateSeed () oder beim ersten Aufruf von nextInt()

Um Ihr Bash-Beispiel zu wiederholen, können Sie Folgendes tun und es sollte blockieren.

  import java.security.SecureRandom; öffentliche Klasse A {public static void main (String [] args) {SecureRandom sr; int out = 0; für (int i = 0; i < 1<<20; i ++) {sr = new SecureRandom (); out ^ = sr.nextInt (); } System.out.println (out); }}  

Answer 3

view on stackexchange narkive permalink

Nicht nur, um einen alten Thread am Leben zu erhalten, sondern einige Leute haben möglicherweise einen wichtigen Teil der langen Geschichte dahinter übersehen ... Es handelt sich um einen bekannten berüchtigten und anhaltenden Fehler bei der Verwendung von / dev / urandom von Java Version 1.4 bis Versionen 1.7. Siehe die folgenden Links:

http://bugs.java.com/view_bug.do?bug_id=6202721

http : //bugs.java.com/view_bug.do? bug_id = 4705093

Soweit ich weiß, wurde dies in Java 8 endlich behoben, wie von Oracle angegeben: https: //docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html

SHA1PRNG und NativePRNG wurden behoben, um den SecureRandom-Startwert ordnungsgemäß zu respektieren Quelleneigenschaften in der Datei java.security. (Die obskure Problemumgehung mit file: /// dev / urandom und file: / dev /./ urandom ist nicht mehr erforderlich.)

Answer 4

view on stackexchange narkive permalink

$ JAVA_HOME / lib / security / java.security : Die Eigenschaft securerandom.source bestimmt, welches Gerät bei Verwendung von SecureRandom verwendet werden soll. Der Standardwert ist / dev / urandom , was bedeutet, dass Java niemals blockiert.

Für Neueinsteiger in das Thema ist / dev / urandom etwas Besonderes Version von / dev / random , die die wahre Entropie von / dev / random verwendet, wenn verfügbar, und dann pseudozufällige Daten, die die wahre Entropie säen, falls verfügbar.

In Headless-, VM- und Cloud-Umgebungen empfehle ich, Urandom von einer externen Quelle wie http://random.org

zu verwenden

Answer 5

view on stackexchange narkive permalink

Unter Linux der letzten Zeit (z. B. in den letzten 6 Jahren) ist der Rechenunterschied zwischen / dev / random (Blockierung) und / dev / urandom (Nichtblockierung) sehr gering. Die Rohentropie wird durch einen Zufallszahlengenerator gewaschen und beide Geräte verwenden die gleichen Bits. Der einzige Unterschied besteht darin, dass / dev / random einen Ratenbegrenzer hat, der verhindert, dass es zu lange läuft, ohne erneut zu säen. Die Ratenschätzung selbst ist ziemlich umstritten.

Dies wird in http://www.2uo.de/myths-about-urandom/ erläutert, das den Punkt nach Hause bringt, dass / dev / urandom reicht aus, um Ihre kryptografischen Algorithmen für Sitzungsschlüssel zu setzen. Wenn Sie es nicht zu häufig aufrufen, sollten beide von identischer oder nahezu identischer Qualität sein.

Ich habe beim Blockieren eines Webcrawlers, der mehr als 1000 gleichzeitige SSL-Verbindungen (Sitzungsschlüssel) herstellen musste, eine Blockierung über / dev / random gesehen, und ja, wir haben zu / dev / urandom gewechselt. Für die Massengenerierung von lang gehaltenen öffentlichen / privaten Schlüsselpaaren (eine seltene Situation) ist ein benutzerdefiniertes Entropiegerät am besten geeignet.