Ich weiß sehr wenig über Ruby, also bitte vergib mir, wenn die Antwort darauf offensichtlich ist. Ich bemerkte bei Ссылка , dass Ruby die PID und die aktuelle verwendet Zeit, OpenSSL :: Random zu säen, wenn ein Aufruf von random_bytes gemacht wird. Wenn nichts anderes unter den Deckeln passiert, ist das nicht der Kern, den Netscape Mitte der 90er Jahre bei der ersten SSL-Implementierung verwendet hat? Ссылка
Sicherlich hat Ruby einen 18 Jahre alten Käfer nicht wiederbelebt. Was fehlt mir hier?
Bearbeiten: Hier ist die Quelle für random_bytes. Beachten Sie die erste Überprüfung, um zu sehen, ob Ruby mit OpenSSL kompiliert wurde. In diesem Fall wird es mit der PID und der aktuellen Zeit versehen.
%Vor%Es hängt von der Konfiguration von Ruby ab, welcher RNG verwendet wird:
Sichere Zufallszahlengenerator-Schnittstelle.
Diese Bibliothek ist eine Schnittstelle für einen sicheren Zufallszahlengenerator eignet sich zum Generieren eines Sitzungsschlüssels in HTTP - Cookies usw.
Es unterstützt folgende sichere Zufallszahlengeneratoren.
openssl
/dev/urandomWin32
Alle drei oben genannten Punkte gelten im Allgemeinen als sicher. Es hängt jedoch von der Implementierung der Klasse SecureRandom ab, wenn sie tatsächlich sicher ist. Die einzige Möglichkeit, dies zu erkennen, ist eine umfassende Untersuchung der Implementierungen.
Wenn wir uns den Code in der Frage ansehen, wird klar, dass Ruby direkt die von OpenSSL erzeugten Bytes verwendet, nach < strong> zusätzlich Seeding die PID:
Wenn Seed-Daten hinzugefügt werden, werden sie wie folgt in den 'Status' eingefügt:
Die Eingabe wird in Einheiten von 20 Bytes (oder weniger für die letzten) zerlegt Block). Jeder dieser Blöcke wird als Hash-Funktion ausgeführt folgt: Die an die Hash-Funktion übergebenen Daten sind das aktuelle 'md', das gleiche Anzahl von Bytes aus dem 'Zustand' (der durch in inkrementierter Schleifenindex) als der aktuelle 'Block', die neuen Schlüsseldaten "Blockieren" und "Zählen" (wird nach jeder Verwendung erhöht). Das Ergebnis davon wird in "md" gehalten und gleichzeitig in den "state" xoriert Orte, die als Eingabe in die Hash-Funktion verwendet wurden. Ich glaube Dieses System adressiert Punkte 1 (Hash-Funktion; derzeit SHA-1), 3 (der 'Zustand'), 4 (über 'md'), 5 (durch Verwendung einer Hash - Funktion und xor).
Der in SecureRandom verwendete Startwert verhindert vorhersagbare Zufallszahlen, die immer dann auftreten, wenn PIDs recycelt werden. Ohne den Fix in SecureRandom erzeugt der OpenSSL-Zufallszahlengenerator genau die gleichen Werte in verschiedenen Prozessen, die die gleiche PID besitzen.
# 4579 beschreibt, wie dies passieren kann, und entsprechenden Eintrag auf OpenSSL Mailing-Liste sagt uns mehr oder weniger, dass dies in Client-Code behandelt werden muss. Aus diesem Grund wurde dieser Keim in Ruby gewählt, um eine Sicherheitsbedrohung zu verhindern. Wenn Sie nicht überzeugt sind, führen Sie das Skript von Eric Wong aus, das an eine Ruby-Version angehängt wurde, bevor Sie dieses Update sehen worum es ging.
Wenn man zu Owlsteads Erklärung kommt, gefährdet der Einsatz von OpenSSLs RNG die Sicherheit nicht, da ein nicht initialisierter Zufallsgenerator immer zuerst RAND_poll aufruft, was genug Entropie sammelt, unabhängig davon, ob zuvor Werte gesetzt / hinzugefügt wurden oder nicht .
Da jedoch die Startwerte in SecureRandom eindeutig vorhersagbar sind, sollten wir nicht davon ausgehen, dass sie irgendeine Entropie hinzufügen. Das interne Verhalten von OpenSSL könnte sich irgendwann ändern, und es könnte die anfängliche Entropieerfassung übersprungen werden, wenn die bereits gesetzten Werte als genügend Entropie betrachtet werden.
Ich öffnete daher # 6928 , was einen defensiveren Ansatz wählte, keine Entropie für die hinzugefügten Werte anzunehmen zu dem Entropie-Pool, die verschiedene Prozesse unterscheiden - dies würde OpenSSL zwingen, in allen Fällen zuverlässig genug Entropie zu sammeln.
Zusammenfassend ist festzustellen, dass die Wahl der Werte (PID und Zeit) eine vernünftige war, sie trägt sogar zur allgemeinen Sicherheit bei (indem sie den "recycelten PID-Angriff" verhindert), anstatt sie zu verringern.
Ein Kollege von mir hat dies untersucht und festgestellt, dass die Wahl des Samens als Antwort auf diesen Fehler eingeführt wurde:
Glücklicherweise sät OpenSSL sich mit 256 Bits Entropie aus / dev / urandom (falls verfügbar) oder dem egd ('entropy summing daemon' - eine Vorstufe von / dev / urandom), abhängig von der Art, wie es kompiliert wurde. Das Seeding erfolgt automatisch beim ersten Aufruf von RAND_status () oder RAND_bytes () und wird nicht unterdrückt, wenn RAND_seed () explizit aufgerufen wird. Ein großes Lob an die OpenSSL-Leute für diese Entscheidung. Hier ist ein Link zu dem spezifischen OpenSSL-Code:
Die interessanten Dateien sind md_rand.c, rand_lib.c und rand_unix.c.
Tags und Links ruby security cryptography prng