在1990年代中期到後期，我是JScript的實現者之一，並且是ECMA委員會的成員，所以我可以在這裡提供一些歷史觀點。

JavaScript Math.random（）函數旨在返回0到1之間的浮點值。眾所周知（至少應該如此），該輸出不是密碼安全的

首先：許多RNG的設計API 很糟糕。 .NET Random類可以以多種方式微不足道地使用以產生相同數量的長序列的事實是可怕的。一種自然使用方式也是錯誤方式的API是“失敗之坑” API；我們希望我們的API是成功的秘訣，自然方法和正確方法是相同的。

我認為可以說，如果我們知道現在所知道的內容，那麼JS隨機API將會有所不同。甚至將名稱更改為“偽隨機”之類的簡單事情也將有所幫助，因為如您所述，在某些情況下，實現細節很重要。在體系結構級別，有充分的理由使您希望 random（）成為一個工廠，該工廠返回代表隨機或偽隨機序列的對象，而不是簡單地返回數字。等等。第二課，讓我們記住1990年代JS的基本設計目標是什麼。 在移動鼠標時使猴子跳舞。我們認為內聯表達式腳本是正常的，我們認為兩到十行腳本塊是常見的，有人可能在頁面上寫百行的想法確實非常不尋常。我記得我第一次看到一萬行的JS程序，而我的第一個問題是向我尋求幫助的人，因為與他們的C ++版本相比，它是如此之慢，是“您瘋了嗎？！10KLOC JS ?！ “

在JS中，任何人都需要加密隨機性的想法也很瘋狂。您需要猴子的動作來保證不可預測的加密強度嗎？

另外，請記住那是1990年代中期。如果您不打算這樣做，我可以告訴您，就加密而言，這是一個與今天截然不同的世界。請參閱加密的導出。

在沒有得到MSLegal團隊大量法律建議的情況下，我什至沒有考慮過[em> 將加密強度隨機性放入瀏覽器附帶的任何內容中。在這個被認為是向國家敵人出口彈藥的世界上，我不想用十英尺高的桿觸碰加密貨幣。從今天的角度來看，這聽起來很瘋狂，但是那就是那個世界。

為什麼瀏覽器不將其替換為CSPRNG？

瀏覽器作者不必提供不做任何更改的理由。改變會花費金錢，而且他們會從更好的改變中解脫出來。每項變更都會帶來巨大的機會成本。

相反，您不僅需要提供一個論據，不僅要進行更改是一個好主意，而且還應盡可能地利用這些時間。

我知道不能將其重新定義為CSPRNG，因為該標準明確不能保證適用於密碼使用，但無論如何似乎都沒有不利之處

不利之處在於，開發人員在無法可靠地確定其隨機性是否是加密強度的情況下仍然處於靜止狀態。否，甚至更容易陷入依賴標準無法保證的屬性的陷阱。提議的更改實際上並不能解決問題，這是設計問題。

因為實際上是 Math.random（）的一種加密安全替代方案：

window.crypto.getRandomValues（typedArray）

這使開發人員可以使用正確的工具來完成工作。如果要為遊戲生成漂亮的圖片或掉落物品，請使用快速的 Math.random（）。當您需要加密安全的隨機數時，請使用價格更高的 window.crypto 。

JavaScript（JS）於1995年發明。

1. 可能是非法的：加密技術在1995年仍受到嚴格的出口管制，因此，好的CSPRNG甚至可能沒有在瀏覽器中分發是合法的。
2. 性能：從歷史上看，CSPRNG（加密安全的偽隨機數生成器）比PRNG慢得多，那麼為什麼默認使用CSPRNG？
3. 沒有安全觀念： 1995年，剛剛發明了SSL。幾乎沒有服務器支持它，互聯網由電話線組成，並且被用於公共論壇（ BBS）和 MUD。加密對於情報機構來說是一種東西。
4. 不需要：由於只是發明了JavaScript，因此尚不存在Web應用程序。它被設計為一種解釋性（因而較慢）的語言，以幫助頁面更加動態。缺省情況下，對隨機函數使用慢速（幾乎不存在）的CSPRNG絕對是沒有道理的。
5. 如此之少，實際上，別無選擇：直到2013年12月，JavaScript甚至都沒有針對CSPRNG的受普遍支持的API，因此直到幾年前，幾乎不可能在Web應用程序中進行正確的加密。
6. 一致性：他們沒有將現有功能更改為具有不同的含義，而是使用不同的名稱創建了一個新功能。您現在可以通過 crypto.getRandomValues 訪問CSPRNG。
ol>

總而言之：既有傳統，又有速度和一致性。不安全的PRNG仍然要快得多，因為您不能假定所有硬件都支持AES，也不依賴於RDRAND的可用性或安全性。

就我個人而言，我認為是時候將所有隨機函數與CSPRNG交換掉，並將更快，不安全的函數重命名為 fast_insecure_random（）之類的東西了。只有科學家或其他需要大量隨機數進行模擬的人才需要使用它們，但是RNG的可預測性不是問題。但是對於具有二十年曆史的功能（現在只有四年（2018年）），我可以理解為什麼我們現在還沒有。

這個評論太長了。

我相信您的問題有一個錯誤的前提：

在現代（甚至不是那麼現代）的計算機上，使用ChaCha8或AES-CTR每秒輸出數百兆字節將是微不足道的。

我們生活在一個越來越以移動為先的世界中，儘管如今的移動設備功能強大，但它們有兩個重要的限制條件：熱量和電池壽命。與可以輕鬆達到100C的台式機處理器不同，您無法將手從智能手機用戶身上拉下來。手機電池通常只能容納手提電腦的1/3電量（如果幸運的話）。根本沒有充分的理由在不需要時增加額外的熱量產生/功耗。

更大的原因是 Math.random（）可以替代：請參見Philipp的答案。因此，無論誰需要強大的加密技術，都有可能使用，而那些不需要強大加密技術的人則可以節省時間和（電池）電量。開發人員是否不能以相同的方式更新Math.random（），即使random（）成為getRandomValues（）的派生產品-以便自動增強大量應用程序？ -那麼，我認為這真的沒有信心可以回答，除非是那些做出決定的開發人員（更新：按照Fate的意願，我們確實有這樣的答案）。

原則上-正如您已經說過-沒有充分的理由。

此外，大多數開發團隊都有大量積壓的工作要做;甚至像這樣的表面上很小的變化也需要測試，回歸，並違背黃金的“ 如果沒有破裂，請不要解決”規則，這是YAGNI準則的一種更強形式。 / p>

隨機數和密碼隨機位是完全不同的動物。它們甚至沒有用於相同的目的。如果要在0到42之間均勻分配一個隨機數，則需要一個沒有明顯模式的均勻分佈。請注意，如果將較大的數字修改為較小的數字，則分配的分佈不完全均勻。對於以mod 27為0到31的隨機數，該示例很容易看到。0到4的出現頻率是5到31的兩倍。甚至沒有討論過。一點點的熵會使搜索空間加倍以猜測數字（對於數字的預期用戶）。

當您請求加密隨機位時，您正在尋找N位熵。擁有非顯而易見的模式還不夠好，因為如果發現了生成該函數的函數（無論其卷積如何），那麼從知道該函數的人的角度來看，實際上熵為0位。

一個很好的例子是類似Fortuna的偽隨機數生成器。您使用第一個隨機數的密鑰（其中密碼塊是大數）對數字1進行加密，然後使用第二個隨機數的密鑰對數字2進行加密，依此類推。對於不知道密碼密鑰（K位密鑰）的用戶，一個完美的N位密碼塊將具有該塊的N位熵。

如果從中擴展到一百萬比特的偽隨機數據，那麼如果您繼續使用相同的密鑰K，那麼您仍然只有K比特的熵。換句話說：如果您有一個您知道的一百萬個比特的書是用K下的單個密碼生成的，因此不要嘗試猜測所有密碼流比特。只需堅持猜測密鑰並從中生成密碼流即可。

因此，隨機數生成器通常是一種密碼，可以不斷獲得重新播種，並且具有更大的隨機性。相比之下，一個簡單的[0,1]隨機數生成器的熵不能超過該數中的位數。並且通常具有的奇數分佈也不完全是您想要的。當浮點數僅為32或64位時，加密需要數百位，並且算法本身帶走了很多熵..假設您希望從[0..1]中均勻分佈某些內容，而不是說由隨機位組成的浮點表示。我什至不知道那會有什麼分佈。

您已經親自回答了這個問題：

該標準明確不保證密碼使用的適用性

因此，與其更改實現，

鑑於此，以及更改常用功能的實現的技術開銷以及存在以下事實，即應該著重於教育開發人員選擇“適合工作的工具”。已經有針對該問題的具體解決方案（請參見@Philipps答案），沒有令人信服的理由進行更改。

編程語言設計需要考慮很多事情。瀏覽器功能非常強大，如今可以優化很多JavaScript。但是，當考慮嵌入式系統時，可能沒有任何好的隨機性來源。例如，有些微控制器在nodeJS（類似）環境中運行。因此，您將需要連接一些可以向引腳提供隨機輸入的設備，以便能夠實現為隨機數提供有力保證的編程語言。而且，您將需要相當多的知識來構建具有足夠隨機性的設備，並以適當的方式處理來自設備的輸入。

像其他人一樣，我要指出， Math.random（）也不是密碼安全的，因為通常不需要它。但是我會進一步爭論說，除非您有充分的理由，否則將密碼安全算法寫入規範中是不明智的。

密碼安全意味著什麼？好吧，總是有一個無聊的定義：“還沒有人知道如何破解它。”但是，當有人破壞它時會發生什麼呢？如果您指定了CSPRNG，則還必須包括一種查詢正在使用哪種算法的方法，或者以其他方式進行查詢，以便最終用戶可以確定所獲得的結果。

導致需要能夠支持多個生成器，以便用戶可以選擇他們信任的生成器。這增加了極大的複雜性。 API中的1行功能突然變成了套件。

此外，當您開始談論加密時，您開始談論嘗試在生成器中確保安全。您提到使用AES生成隨機數：您的AES實現是否需要不受旁通道攻擊的影響？當您編寫一個專門用於提供加密保證的庫時，問這個問題並不是所有不合理的事情。對於一個規範，這可能是非常不合理的。用規範語言來表達對旁通道攻擊的免疫力是非常的措辭。

通過將其放入規格中，您做了什麼？大多數PRNG用戶根本不需要加密保證，因此您只是在浪費CPU週期。那些希望獲得密碼保證的人可能會尋求一個圖書館，該圖書館支持需要具備這種密碼學知識的全套功能，因此他們無論如何都不會信任 Math.random（）。剩下的就是您提到的人口統計信息：犯過錯而在不應該使用時使用了工具的人。好吧，我可以從經驗中告訴您，主要的編程語言不是查找錯誤不能錯誤使用的API的地方。他們充滿了“如果執行此操作，這是您自己的錯”的措辭。

此外，請考慮以下問題：如果您使用 Math.random（）並假設有加密保證，您將在算法中的某個地方犯另一個致命的加密錯誤的機率是多少？ CSPRNG Math.random（）可能會提供錯誤的安全感，並且我們可能會發現更多錯誤！

每個人似乎都在這裡遺漏了一些細微差別：密碼算法要求數字在算法的所有執行過程中在數學和統計上都是隨機的。這意味著，例如在遊戲或動畫中，您可以使用偽隨機數序列，這對於“種類隨機”的數將是完美的。

但是可以操縱或預測，例如種子隨機數（這是Windows隨機函數的默認行為），則該種子實際上是可預測的。如果我可以操縱您的應用程序以重新啟動，然後使用帶種子的隨機數，則可以預測您會選擇哪種“隨機”數。如果有可能，則可以取消加密。第二個關注點可能是某些算法要求在頻譜上保證數字的分佈，而某些偽隨機數生成器無法保證。

密碼隨機數生成器具有大量輸入來創建熵，例如測量麥克風輸入產生的噪聲，一天中的時間滴答聲，內存寄存器的校驗和，序列號等。如果不是不可能的話，盡可能多的輸入將使操作和預測變得異常困難。從密碼學的角度來看，性能不是目標，而是“真正”的隨機性。

因此，根據您的用例，您可能希望對隨機數進行合理的，隨機的，高性能的實現，但是如果要進行複雜處理-hellman密鑰交換，您需要一種加密安全的算法。

我沒有看到任何人提及（或我只是忽略了）的另一個考慮因素是， Math.random（）函數的某些用途實際上與種子相同時依賴於可重複性。時間。現在更改它會破壞這些用途。