Entropy for Nonce創建

在OAuth中，Nonce用於防止重播攻擊。除了nonce之外，還使用時間戳（並且可以認爲是第二次隨機數，因爲在嚴格遵守規範時，沒有時間限制請求被認爲有效 - 服務器可以，而不是必須限制該範圍）。Entropy for Nonce創建

實現OAuth-Client時，我腦海中浮現的問題是：DoInnces必須是加密安全的嗎？

有兩點重要的是我在這裏：

它是確定系統是否熵不足時很少有時間都創造了很多的隨機數使用/dev/urandom而不是/dev/random和風險預測的值？（對於那些不熟悉random/urandom的人來說：這在性能上會有優勢，因爲/dev/urandom在以安全爲代價的小熵可用時不會阻止調用，因爲當然值不那麼隨機）。
由於隨機數必須被編碼才能被髮送，如果它們包含非ASCII字符，那麼最簡單的方法就是隻能使用可以原樣發送的ASCII字符來創建它們（[0-9A-Za -z _- +〜] AFAIR）。當然，這又限制了熵，所以隨機性不再是同樣強大的。在你的看法中，nonce的合理長度是什麼，只包含那些字符，是否值得不必編碼的優勢？

2014-02-08 Johannes H.

「Nonce」代表「使用次數」。通常，隨機數不必是隨機的或不可預測的，而只能是唯一的。隨機生成它們只是使它們唯一的最簡單的方法（除非發生碰撞，但概率微乎其微）。雖然我不熟悉OAuth，但我不能說OAuth。 – ntoskrnl

@ntoskrnl感謝您的評論。基本上這就是我的想法，非常感謝您的確認。碰撞並不是一個真正的問題，我正在將微秒附加到隨機數，有可能仍然有碰撞幾乎爲零。（BUt追加它們使得最後6個字符是可預測的，所以如果它必須是不可預知的，這將是另一個問題） –

由於創建了許多隨機數，所以系統不能在熵上運行不足。它只能跑低，因爲它還沒有播種*但*。一個安全的PRNG不會因爲你讀了很多東西而變得脆弱。 – CodesInChaos

通常使用/dev/random代替/dev/urandom幾乎不會有用。如果您不想讓這些PRNG依賴/dev/urandom，您可以使用它來播種其他PRNG。對於隨機數，你當然應該使用/dev/urandom。或者您可以使用在您的應用程序或庫中實施的良好播種的線程本地加密安全PRNG。

如果要通過ASCII發送隨機數（或大多數二進制數據），則可以使用hexadecimals或base 64。爲了使數值本身具有最好的可讀性，請使用hex來提高base64的效率。現在，默認情況下，base 64使用數字，大寫和小寫字母以及字符+，/和=，但如果您想使用其他值，則可以始終對base64進行URL編碼，替換不需要的字符或使用one of the variants。

來源

2014-02-09 01:09:00

至於編碼，OAuth允許不同於默認URLEncode的字符，=不允許未編碼 - 而URLencoding是隻是另一個不必要的步因此，base64不是一種替代方案。此刻，我只是有一個數組，可以發送未編碼的字符，並從每個字符中隨機選擇。 –

你需要有兩個冪來轉換位數組。雖然可以使用更多的字符，但是很可能您的結果不會完全隨機。簡單地生成一個特定大小的真隨機數組並更換'？'和'='字符（如果不允許的話）會更好。 –

這又一次取決於我真正需要的隨機性水平，這是一個完美的問題。如果力量是重要的，比是的，你是對的（我從來沒有想過這個，謝謝！）。如果我不這樣做，它仍然是正確的，但無關緊要;） –

Entropy for Nonce創建

回答

相關問題