Ich war Mitte bis Ende der neunziger Jahre einer der Implementierer von JScript und Mitglied des ECMA-Ausschusses, daher kann ich hier eine historische Perspektive bieten.

Die JavaScript-Funktion Math.random () ist so konzipiert, dass ein Gleitkommawert zwischen 0 und 1 zurückgegeben wird. Es ist allgemein bekannt (oder sollte es zumindest sein), dass die Ausgabe nicht kryptografisch sicher ist.

Zunächst einmal: das Design vieler RNG APIs sind schrecklich . Die Tatsache, dass die .NET Random-Klasse auf verschiedene Weise trivial missbraucht werden kann, um lange Sequenzen derselben Nummer zu erzeugen, ist schrecklich. Eine API, bei der die natürliche Verwendung auch die falsche ist, ist eine "Pit of Failure" -API. Wir möchten, dass unsere APIs Erfolgsgruben sind, in denen der natürliche und der richtige Weg gleich sind.

Ich denke, es ist fair zu sagen, dass die JS-Zufalls-API anders wäre, wenn wir damals wüssten, was wir jetzt wissen. Selbst einfache Dinge wie das Ändern des Namens in "Pseudozufall" würden helfen, da, wie Sie bemerken, in einigen Fällen die Implementierungsdetails von Bedeutung sind. Auf architektonischer Ebene gibt es gute Gründe, warum Sie möchten, dass random () eine Factory ist, die ein Objekt zurückgibt, das eine zufällige oder pseudozufällige Sequenz darstellt, anstatt einfach Zahlen zurückzugeben. Und so weiter. Lektionen gelernt.

Zweitens wollen wir uns daran erinnern, was der grundlegende Entwurfszweck von JS in den 1990er Jahren war. Lassen Sie den Affen tanzen, wenn Sie die Maus bewegen . Wir haben Inline-Ausdrucksskripte als normal angesehen, wir haben zwei- bis zehnzeilige Skriptblöcke als üblich angesehen, und die Vorstellung, dass jemand hundert Zeilen Skript auf eine Seite schreiben könnte, war wirklich sehr ungewöhnlich. Ich erinnere mich an das erste Mal, als ich ein JS-Programm mit zehntausend Zeilen sah, und meine erste Frage an die Leute, die mich um Hilfe baten, weil es im Vergleich zu ihrer C ++ - Version so langsam war, war eine Version von "Bist du verrückt?! 10KLOC JS?!" "

Die Vorstellung, dass jeder Krypto-Zufälligkeit in JS benötigen würde, war ähnlich verrückt. Sie brauchen Ihre Affenbewegungen, um eine unvorhersehbare Kryptostärke zu haben? Unwahrscheinlich.

Denken Sie auch daran, dass es Mitte der 90er Jahre war. Wenn Sie nicht dafür da waren, kann ich Ihnen sagen, dass es in Bezug auf Krypto eine ganz andere Welt als heute war ... Siehe Export von Kryptografie.

Ich hätte nicht einmal in Betracht gezogen, die Zufälligkeit der Kryptostärke in irgendetwas zu stecken, das mit dem Browser geliefert wird, ohne eine große Menge an Rechtsberatung vom MSLegal-Team zu erhalten. Ich wollte Krypto nicht mit einer zehn Fuß langen Stange in einer Welt berühren, in der der Versandcode als Export von Munition an Staatsfeinde angesehen wurde. Das klingt aus heutiger Sicht verrückt, aber das war die Welt, die war.

Warum ersetzen Browser es nicht durch ein CSPRNG?

Browserautoren müssen keinen Grund angeben, KEINE Änderung vorzunehmen. Änderungen kosten Geld und nehmen den Aufwand für bessere Änderungen weg. Jede Änderung hat enorme Opportunitätskosten .

Vielmehr müssen Sie nicht nur argumentieren, warum die Änderung eine gute Idee ist, sondern auch, warum sie ihre Zeit bestmöglich nutzt. Dies ist eine kleine Änderung.

Ich verstehe, dass sie nicht als CSPRNG neu definiert werden konnte, da der Standard ausdrücklich keine Garantie für die Eignung für die kryptografische Verwendung gibt. Es scheint jedoch keinen Nachteil zu geben,

Der Nachteil ist, dass Entwickler immer noch in einer Situation sind, in der sie nicht zuverlässig wissen können, ob ihre Zufälligkeit Kryptostärke ist oder nicht, und kann noch leichter in die Falle tappen, sich auf eine Eigenschaft zu verlassen, die nicht durch den Standard garantiert wird. Die vorgeschlagene Änderung behebt das Problem nicht, bei dem es sich um ein Entwurfsproblem handelt.

Weil es tatsächlich eine kryptografisch sichere Alternative zu Math.random():

window.crypto.getRandomValues ​​(typedArray) gibt

Dadurch kann der Entwickler das richtige Tool für den Job verwenden. Wenn Sie hübsche Bilder oder Beutetropfen für Ihr Spiel generieren möchten, verwenden Sie den schnellen Math.random () . Wenn Sie kryptografisch sichere Zufallszahlen benötigen, verwenden Sie das teurere Fenster window.crypto .

JavaScript (JS) wurde 1995 erfunden.

1. Potenziell illegal: Kryptografie war 1995 noch unter strenger Exportkontrolle, sodass ein gutes CSPRNG möglicherweise nicht einmal über eine solche verfügt Die Verteilung in einem Browser war legal.
2. Leistung: In der Vergangenheit sind CSPRNGs (kryptografisch sichere Pseudozufallszahlengeneratoren) viel langsamer als PRNGs. Warum also standardmäßig ein CSPRNG verwenden?
Keine Sicherheitsphilosophie: 1995 wurde SSL gerade erfunden. Es wurden praktisch keine Server unterstützt, das Internet bestand aus Telefonleitungen und wurde für öffentliche Foren ( BBSes) und MUDs verwendet. Verschlüsselung war etwas für Geheimdienste.
3. Keine Notwendigkeit: Webanwendungen existierten noch nicht, da JavaScript gerade erfunden wurde. Es wurde als interpretierte (also langsame) Sprache entwickelt, um Seiten dynamischer zu machen. Es wäre niemandem in den Sinn gekommen, standardmäßig ein langsames (und kaum vorhandenes) CSPRNG für eine Zufallsfunktion zu verwenden.
4. Tatsächlich gab es so wenig Bedarf, dass es keine Alternative gab: JavaScript hatte bis Dezember 2013 nicht einmal eine allgemein unterstützte API für ein CSPRNG, sodass eine ordnungsgemäße Kryptografie in Webanwendungen bis vor einigen Jahren kaum möglich war.
5. Konsistenz: Anstatt eine vorhandene Funktion in eine andere Bedeutung zu ändern, haben sie eine neue Funktion mit einem anderen Namen erstellt. Sie können jetzt über crypto.getRandomValues ​​ auf das CSPRNG zugreifen.
ol>

Zusammenfassend: Legacy, aber auch Geschwindigkeit und Konsistenz . Unsichere PRNGs sind immer noch viel schneller, da Sie nicht davon ausgehen können, dass die gesamte Hardware AES-Unterstützung bietet, und auch nicht von der Verfügbarkeit oder Sicherheit von RDRAND abhängen.

Ich persönlich denke, es ist Zeit, alle zufälligen Funktionen gegen CSPRNGs auszutauschen und die schnelleren, unsicheren Funktionen in fast_insecure_random () umzubenennen. Sie sollten nur von Wissenschaftlern oder anderen Personen benötigt werden, die Simulationen durchführen, die viele Zufallszahlen benötigen, bei denen die Vorhersagbarkeit des RNG jedoch keine Rolle spielt. Aber für eine Funktion mit zwei Jahrzehnten Geschichte, in der es erst seit vier Jahren (2018) eine Alternative gibt, kann ich verstehen, warum wir uns noch nicht an diesem Punkt befinden.

Dies ist zu lang für einen Kommentar.

Ich glaube, Ihre Frage enthält eine fehlerhafte Prämisse:

auf modernen (und sogar nicht so modernen) Computern, Es wäre trivial, mit ChaCha8 oder AES-CTR Hunderte von Megabyte pro Sekunde auszugeben.

Sie denken an einen Desktop-Browser auf einem mit Wechselstrom verbundenen Computer oder einem Laptop mit einem großen 10-Ah-Akku von Honkin.

Wir leben in einer zunehmend mobilen Welt, und obwohl mobile Geräte heutzutage recht leistungsfähig sind, gibt es zwei wichtige Einschränkungen: Wärme und Akkulaufzeit. Im Gegensatz zu einem Desktop-Prozessor, der leicht 100 ° C erreichen kann, können Sie dem Smartphone-Benutzer nicht die Hand abbrennen. Und Telefonbatterien halten normalerweise nur vielleicht 1/3 so viel wie ein Laptop (wenn Sie Glück haben). Es gibt einfach keinen guten Grund, die zusätzliche Wärmeerzeugung / den zusätzlichen Stromverbrauch hinzuzufügen, wenn Sie sie nicht benötigen.

Der größere Grund ist, dass es eine Alternative zu Math.random () gibt: siehe Philipps Antwort . Wer also eine starke Krypto benötigt, kann sie haben, und diejenigen, die keine Zeit und (Batterie-) Energie sparen können.

Aber angenommen, Sie hätten gefragt: "Warum, auch wenn es eine stärkere Alternative gibt, haben Sie die Entwickler aktualisieren Math.random () nicht trotzdem - dh haben random () zu einer Ableitung von getRandomValues ​​() gemacht -, um automatisch viele Apps zu stärken? " - dann denke ich nicht, dass dies wirklich mit Sicherheit beantwortet werden kann, außer von den Entwicklern, die die Entscheidung getroffen haben (Update: und wie das Schicksal es haben würde, haben wir eine solche Antwort).

Grundsätzlich gibt es - wie Sie bereits sagten - keinen starken Grund .

Darüber hinaus haben die meisten Entwicklungsteams einen erheblichen Rückstand an Dingen, die dringender sind ;; und selbst eine scheinbar kleine Änderung wie diese erfordert Testen, Regression und einen Verstoß gegen die goldene Regel " Wenn sie nicht gebrochen ist, beheben Sie sie nicht ", eine stärkere Form des YAGNI-Kriteriums.

Zufallszahlen und Kryptozufallsbits sind völlig unterschiedliche Tiere. Sie werden nicht einmal für den gleichen Zweck verwendet. Wenn Sie eine Zufallszahl möchten, die gleichmäßig zwischen 0 und 42 verteilt ist, möchten Sie eine gleichmäßige Verteilung ohne offensichtliches Muster. Beachten Sie, dass es keine gerade Verteilung ist, wenn Sie eine größere Zahl mit einer kleineren modifizieren. Dieses Beispiel ist leicht zu erkennen für eine Zufallszahl von 0 bis 31 aus Mod 27. 0 bis 4 werden doppelt so oft wie 5 bis 31 angezeigt.

Bis Sie über Kryptozufall sprechen, ist der Begriff der Entropie nicht ' Ich habe nicht einmal darüber gesprochen. Ein bisschen Entropie verdoppelt den Suchraum, um die Zahl zu erraten (für den beabsichtigten Benutzer der Zahlen).

Wenn Sie nach Kryptozufallsbits fragen, fragen Sie nach N Entropiebits. Es ist nicht gut genug, ein nicht offensichtliches Muster zu haben, denn wenn eine Funktion entdeckt wird, die es erzeugt (egal wie verworren), dann gibt es tatsächlich 0 Entropiebits aus der Sicht desjenigen, der diese Funktion kennt.

Ein gutes Beispiel hierfür ist ein Fortuna-ähnlicher Pseudozufallszahlengenerator. Sie verschlüsseln eine Nummer 1 mit einem Schlüssel für die erste Zufallszahl (wobei der Verschlüsselungsblock eine große Zahl ist), verschlüsseln dann Nummer 2 mit einem Schlüssel für die zweite Zufallszahl und so weiter. In Bezug auf den Benutzer, der den Schlüssel (von K Bits) zur Verschlüsselung nicht kennt, weist ein perfekter N-Bit-Verschlüsselungsblock N Entropiebits für diesen Block auf.

Wenn Sie eine Million Bits pseudozufälliger Daten daraus erweitern, haben Sie immer noch nur K Entropiebits, wenn Sie mit demselben Schlüssel K weitermachen. Mit anderen Worten: Wenn Sie eine hatten Buch mit 1 Million Bits, von denen Sie wissen, dass sie mit einer einzelnen Verschlüsselung unter K generiert wurden. Versuchen Sie dann nicht, alle Verschlüsselungsdatenbits zu erraten. Halten Sie sich einfach an das Erraten des Schlüssels und generieren Sie den Chiffrestream daraus.

Ein Zufallszahlengenerator ist also oft eine Chiffre, die immer wieder mit mehr Zufälligkeit neu ausgesät wird, wie es möglich ist. Im Vergleich dazu kann ein einfacher [0,1] Zufallszahlengenerator nicht mehr Entropie haben als die Anzahl der Bits in der Zahl. und hat normalerweise eine ungerade Verteilung, die nicht genau das ist, was Sie auch wollen. Krypto benötigt Hunderte von Bits, wenn Gleitkommazahlen nur 32 oder 64 Bit sind, und der Algorithmus selbst nimmt einen Großteil der Entropie weg ... vorausgesetzt, Sie möchten etwas, das gleichmäßig von [0..1] verteilt ist, anstatt a zu sagen Gleitkomma-Darstellung aus zufälligen Bits. Ich weiß nicht einmal, welche Verteilung das überhaupt haben würde.

Sie haben die Frage irgendwie selbst beantwortet:

Der Standard gibt ausdrücklich keine Garantie für die Eignung für die kryptografische Verwendung.

Anstatt die Implementierung zu ändern, Der Schwerpunkt sollte auf der Schulung der Entwickler zur Auswahl des „richtigen Tools für den Job“ ™ liegen.

Angesichts dessen und des technischen Aufwands bei der Änderung der Implementierung einer häufig verwendeten Funktion sowie der Tatsache, dass es solche gibt Es gibt bereits zwingende Lösungen für dieses Problem (siehe Antwort von @Philipps). Es gibt keinen zwingenden Grund, die Änderung vorzunehmen.

Das Design von Programmiersprachen muss viele Dinge berücksichtigen. Browser sind sehr leistungsfähig und optimieren Javascript heute sehr. Wenn Sie jedoch eingebettete Systeme in Betracht ziehen, haben Sie möglicherweise keine gute Zufallsquelle. Zum Beispiel gibt es Mikrocontroller, die eine NodeJS (ähnliche) Umgebung ausführen.

Ein solcher Mikrocontroller verfügt nicht über zufällige Quellen, die kryptografisch sichere Zufallszahlen garantieren. Sie müssten also ein Gerät anschließen, das eine zufällige Eingabe an einen Pin liefern kann, um eine Programmiersprache implementieren zu können, die starke Garantien für Zufallszahlen bietet. Und Sie benötigen einige Kenntnisse, um ein Gerät zu erstellen, das genügend Zufälligkeit bietet, und um die Eingaben vom Gerät auf geeignete Weise zu verarbeiten.

Wie andere möchte ich darauf hinweisen, dass Math.random () nicht kryptografisch sicher ist, da es normalerweise nicht benötigt wird. Aber ich würde noch weiter gehen und argumentieren, dass es nicht ratsam ist, einen kryptografisch sicheren Algorithmus in eine Spezifikation zu schreiben, es sei denn, Sie haben einen sehr guten Grund.

Was bedeutet es, kryptografisch sicher zu sein? Nun, es gibt immer die langweilige Definition von "Niemand weiß, wie man es noch bricht". Aber was passiert, wenn jemand es kaputt macht? Wenn Sie ein CSPRNG angegeben haben, müssen Sie auch eine Möglichkeit angeben, um abzufragen, welcher Algorithmus verwendet wird, oder auf andere Weise festlegen, dass der Endbenutzer sicher sein kann, was er erhält.

Dies ist ebenfalls wahrscheinlich Dies führt dazu, dass mehrere Generatoren unterstützt werden müssen, damit der Benutzer einen auswählen kann, dem er vertraut. Dies erhöht die Komplexität erheblich. Plötzlich wurde eine 1-Zeilen-Funktion in einer API zu einer Suite.

Wenn Sie anfangen, über Krypto zu sprechen, sprechen Sie auch über den Versuch, im Generator sicher zu sein. Sie erwähnen die Verwendung von AES zur Generierung von Zufallszahlen: Muss Ihre AES-Implementierung gegen Seitenkanalangriffe immun sein? Wenn Sie eine Bibliothek mit dem speziellen Zweck schreiben, kryptografische Garantien bereitzustellen, ist es nicht allzu unvernünftig, diese Frage stellen zu müssen. Für eine Spezifikation könnte es schrecklich unvernünftig sein. Die Immunität gegen Seitenkanalangriffe ist in der Sprache der Spezifikationen sehr schwer zu formulieren.

Und was haben Sie erreicht, indem Sie es in eine Spezifikation aufgenommen haben? Die meisten Benutzer von PRNGs benötigen überhaupt keine kryptografischen Garantien, sodass Sie nur CPU-Zyklen für sie verschwendet haben. Diejenigen, die kryptografische Garantien wünschen, werden wahrscheinlich eine Bibliothek suchen, die die gesamte Funktionalität unterstützt, die erforderlich ist, um mit einer solchen Kryptografie vertraut zu sein, sodass sie Math.random () sowieso nicht vertrauen. Alles, was übrig bleibt, ist die von Ihnen erwähnte Bevölkerungsgruppe: Menschen, die einen Fehler gemacht und ein Werkzeug verwendet haben, wenn sie es nicht sollten. Nun, ich kann Ihnen aus Erfahrung sagen, dass wichtige Programmiersprachen kein Ort sind, um nach einer API zu suchen, die Sie nicht versehentlich falsch verwenden können. Sie sind voll von Formulierungen "Wenn Sie dies tun, ist es Ihre eigene Schuld".

Beachten Sie auch Folgendes: Wenn Sie Math.random () verwenden und kryptografische Garantien übernehmen, Wie hoch ist die Wahrscheinlichkeit, dass Sie irgendwo in Ihrem Algorithmus einen weiteren schwerwiegenden Kryptofehler machen? Ein CSPRNG Math.random () kann ein falsches Sicherheitsgefühl vermitteln, und wir finden möglicherweise noch mehr Fehler!

Jeder scheint hier eine Nuance übersehen zu haben: Kryptografische Algorithmen erfordern, dass eine Zahl über alle Ausführungen des Algorithmus mathematisch und statistisch zufällig ist. Dies bedeutet zum Beispiel während eines Spiels oder einer Animation, dass Sie eine pseudozufällige Folge von Zahlen verwenden könnten, und dies wäre für eine "Art von Zufallszahl" vollkommen in Ordnung.

Wenn diese Zahl jedoch manipuliert werden könnte oder vorhergesagt, zum Beispiel eine gesetzte Zufallszahl (was das Standardverhalten der Windows-Zufallsfunktionen ist), dann ist dieser Start tatsächlich vorhersehbar. Wenn ich Ihre Anwendung manipulieren kann, um neu zu starten und dann eine gesetzte Zufallszahl zu verwenden, kann ich vorhersagen, welche "Zufallszahl" Sie wählen werden. Wenn dies möglich ist, kann die Kryptographie besiegt werden. Ein sekundäres Problem kann auch sein, dass einige Algorithmen eine garantierte Verteilung von Zahlen über das Spektrum erfordern, die bestimmte Pseudozufallsgeneratoren nicht garantieren können.

Kryptografisch zufällige Zahlengeneratoren verfügen über eine große Anzahl von Eingaben, um Entropie zu erzeugen, beispielsweise zum Messen Schussgeräusche vom Mikrofoneingang, Tageszeit-Ticks, Prüfsumme der RAM-Register, Seriennummern usw. So viele Eingänge wie möglich, um es unmöglich zu machen, dann unglaublich schwer zu manipulieren und vorherzusagen. In einem kryptografischen Sinne ist Leistung nicht das Ziel, sondern "wahre" Zufälligkeit.

Abhängig von Ihrem Anwendungsfall möchten Sie möglicherweise eine einigermaßen zufällige, performante Implementierung einer Zufallszahl, aber wenn Sie einen Unterschied machen -Hellman-Schlüsselaustausch Sie benötigen einen kryptografisch sicheren Algorithmus.

Eine weitere Überlegung, die ich nicht erwähnt habe (oder die ich einfach übersehen habe), ist, dass einige Verwendungen der Funktion Math.random () tatsächlich von der Wiederholbarkeit abhängen, wenn sie wie zuvor gesetzt wurden Zeit. Wenn Sie es jetzt ändern, werden diese Verwendungen unterbrochen.