random_source 文件的大小是否重要?
一些 GNU coreutils 實用程序喜歡
sort
並shuf
使用文件作為有效地服務於種子的東西。文件大小重要嗎?推薦的方式https://www.gnu.org/software/coreutils/manual/html_node/Random-sources.html使用基於 openssl 的方法,需要相當長的時間。
如果我只使用如下 6 個字母的單詞怎麼辦?這是否會影響所述實用程序創建偽隨機性的能力?
shuf -i1-10 --random-source=<(echo durian)
如果您提供一個固定字元串作為隨機源,那麼它每次都會以相同的方式“隨機化” 。為了證明這一點,讓我們測試一下。
$ printf '%s\n' a b c | shuf --random-source=<(echo durian) b c a
在我的系統上,每次執行上述命令時輸出都是相同的。(我懷疑它可能會因實現而有所不同,但每次都應該相同。)根據此 XKCD,您正在對隨機性進行硬編碼:
這不是真正隨機的。它只是每次都產生相同的輸出。固定字元串源的大小無關緊要。它仍然是固定的。
您提供的連結中有與隨機源的隨機質量相關的相關資訊:
/dev/urandom
對於大多數實際用途來說已經足夠了,但是需要對私有數據進行高價值或長期保護的應用程序可能需要備用數據源,例如/dev/random
或/dev/arandom
.後兩個選項比第一個選項“更隨機”。這意味著源越隨機,改組越隨機。因此,固定字元串不是特別健壯。
具體來說,
shuf
固定字元串的長度是相關的。例如,以下失敗。shuf -i1-19 --random-source=<(echo durian)
但是,如果將輸出限制為
-n16
,它可以工作,但會-n17
失敗。我測試了幾個不同的單詞和排列,當我減少源中的字元數時,最大值-n
會下降。source length max -n 7 16 6 13 5 10 4 8 3 5 2 3 1 1 0 0
我不確定直接關係,但大概額外的排序項目(在
-n
)需要更多的源字元作為種子。然而,shuf
至少,一旦你通過了這個最小門檻值,每個額外的字元對隨機性本身沒有任何影響。在上面的範例中,如果您更改第 50 個字元,則輸出仍然相同。