Frage:
Java SecureRandom blockiert nicht? Wie?
user1483512
2013-08-14 23:46:14 UTC
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!

Es gibt keinen Grund für ein CSPRNG, erneut zu blockieren, nachdem es einmal gesetzt wurde. Das Blockieren ist nach einem Neustart, Ruhezustand usw. nützlich, da Sie eine ausreichende anfängliche Entropie benötigen, aber "Entropie-Drain" in der Praxis keine Bedrohung darstellt.
Fünf antworten:
Gilles 'SO- stop being evil'
2013-08-15 00:02:19 UTC
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.

Einfach, beantwortet meine Frage, stützt seine Behauptungen. Danke und +1. (Das ist +1, wenn ich genug Ruf hatte, um zu stimmen ...)
Anscheinend hat SecureRandom auf Android eine andere Implementierung, die zu wiederholten Werten geführt hat: http://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets/
@WillSargent Nicht wahr. Das SecureRandom von Android liest auch aus "/ dev / urandom", so dass es konzeptionell das gleiche Geschäft ist. Es gab jedoch einen Fehler in der Art und Weise, wie Android "/ dev / urandom" initialisierte, was das Problem verursachte.
@DCKing Nein, stimmt. Die Implementierung ist unterschiedlich und hat zu wiederholten Werten geführt. Ich habe nie gesagt, dass es aus / dev / random gelesen wird. Siehe Quelle unter http://android-developers.blogspot.com.au/2013/08/some-securerandom- Thoughts.html
Ja, um dies zu verdeutlichen: Die Unterschiede bei der Implementierung von "SecureRandom" zwischen Java und Android waren nicht die Ursache. Es war der Unterschied in der Implementierung von `/ dev / urandom` auf Android und anderen * nixen, der die Ursache war.
diedthreetimes
2014-11-14 12:06:22 UTC
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); }}
Überschreibt dies `securerandom.source` in` $ JAVA_HOME / lib / security / java.security`? AFAIK, wenn `securerandom.source`` / dev / urandom` ist, wird niemals` / dev / random` verwendet
Wie ich das verstehe, hängt stark von Ihrer Version (und Implementierung) von Java ab. Nach meinen eigenen Experimenten mit Oracle JVM 7 besteht die einzige Möglichkeit, / dev / random vollständig zu ignorieren, darin, securerandom.source auf /dev/./urandom zu setzen. Andernfalls wird weiterhin / dev / random für die Samengenerierung verwendet.
Sie sagen "sollte blockieren", haben Sie es getestet?
Ich glaube nicht, dass ich es getan habe.
ozys
2016-01-28 23:20:18 UTC
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.)

Es wäre besser, wenn Sie eine Zusammenfassung des Java-Problems in Ihre Antwort aufnehmen würden.
Alastair McCormack
2014-03-10 00:01:48 UTC
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
Sie können Entropie jedoch nur dann sicher von random.org abrufen, wenn Sie über genügend Entropie verfügen, um eine sichere SSL-Verbindung herzustellen. Sie haben also ein Hühnerei-Problem.
V. guter Punkt! Zurück zum Zeichenbrett
Ich verwende Java 8 und die Standardkonfiguration lautet: securerandom.source = file: / dev / random
Paul Baclace
2015-10-01 02:54:49 UTC
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.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...