問題描述
我需要生成加密性強的隨機數和字節數組.為此，我使用了 Java 的 SecureRandom 類.但我不確定根據加密強度選擇哪種 PRNG 算法.
I need to generate cryptographically strong random numbers and byte arrays. For this purpose, I'm using Java's SecureRandom class. But I'm not sure to choose which PRNG algorithm in terms of their cryptographic strength.
以下哪個實例會產生更不可預測的數字?或者他們是平等的?
Which of the following instances generates a more unpredictable numbers? Or are they equal?
SecureRandom nativePrng = SecureRandom.getInstance("NativePRNG")
SecureRandom sha1Prng = SecureRandom.getInstance("SHA1PRNG")
此外，我們可以使用SUN"提供程序生成這些實例(例如 SecureRandom.getInstance("SHA1PRNG", "SUN")).這有什么不同嗎?
Moreover, we are able to generate these instances with "SUN" provider (e.g. SecureRandom.getInstance("SHA1PRNG", "SUN")). Do this make a difference?
提前致謝.
推薦答案
TL;DR:使用 new SecureRandom() 當您不確定時，讓系統來解決.可能使用 SecureRandom.getInstanceStrong() 用于長期密鑰生成.
TL;DR: Use new SecureRandom() when you're not sure and let the system figure it out. Possibly use SecureRandom.getInstanceStrong() for long term key generation.
不要期望隨機數生成器在運行時應用程序中生成特定的輸出序列，即使您自己播種也是如此.
Do not expect a random number generator to generate a specific output sequence within a runtime application, not even if you seed it yourself.
對于隨機數生成器，總是很難說哪個是最好的.Linux 和大多數 Unix 都有一個經過深思熟慮的隨機數生成器，所以使用 /dev/random 或 /dev/urandom 也沒有什么壞處，即 "NativePRNG".使用 /dev/random 的問題是它會阻塞直到有足夠的熵可用.因此，除非您對密鑰生成有一些特殊要求，否則我建議您不要這樣做.
With random number generators it is always hard to say which is best. Linux and most Unixes have a pretty well thought out random number generator, so it doesn't hurt to use /dev/random or /dev/urandom, i.e. "NativePRNG". Problem with using /dev/random is that it blocks until enough entropy is available. So I would advice against it unless you've got some special requirements with regards to key generation.
"SHA1PRNG" 使用哈希函數和計數器以及種子.算法比較簡單，但是描述的不是很好.它通常被認為是安全的.由于它僅在啟動期間從其中一個系統生成器中播種，因此需要較少的內核調用，因此它可能會減少資源密集型 - 在我的系統上，它的運行速度大約是 "NativePRNG" 的 9 倍(配置為使用 /dev/urandom).兩者似乎都只對我的雙核 Ubuntu 筆記本電腦的一個核心征稅(一次，它經常從一個核心切換到另一個核心，這可能是內核調度的罪魁禍首).如果您需要高性能，請選擇這個，尤其是當 /dev/urandom 設備在特定系統配置上運行緩慢時.
"SHA1PRNG" uses a hash function and a counter, together with a seed. The algorithm is relatively simple, but it hasn't been described well. It is generally thought of to be secure. As it only seeds from one of the system generators during startup and therefore requires fewer calls to the kernel it is likely to be less resource intensive - on my system it runs about 9 times faster than the "NativePRNG" (which is configured to use /dev/urandom). Both seem to tax only one core of my dual core Ubuntu laptop (at a time, it frequently switched from one core to another, that's probably kernel scheduling that's which is to blame). If you need high performance, choose this one, especially if the /dev/urandom device is slow on the specific system configuration.
請注意，retired Apache Harmony 實現中的 "SHA1PRNG" 與 SUN 提供程序中的不同(Oracle 在標準 Java 中使用SE 實施).Jakarta 中的版本也用于舊版本的 Android.雖然我無法進行全面審查，但它看起來不是很安全.
Note that the "SHA1PRNG" present in the retired Apache Harmony implementation is different from the one in the SUN provider (used by Oracle in the standard Java SE implementation). The version within Jakarta was used in older versions of Android as well. Although I haven't been able to do a full review, it doesn't look to be very secure.
我并沒有錯，SHA1PRNG 已被證明不是偽隨機的版本 <4.2.2 及更多 這里.
and I wasn't half wrong about this, SHA1PRNG has been shown not to be pseudo-random for versions < 4.2.2 and more here.
請注意，"SHA1PRNG" 不是 Java SE 的實現要求.在大多數運行時它都會存在，但直接從代碼中引用它會降低您的代碼的可移植性.
Beware that "SHA1PRNG" is not an implementation requirement for Java SE. On most runtimes it will be present, but directly referencing it from code will make your code less portable.
現在(從 Java 9 開始)OpenJDK 和 Oracle JDK 還包含多個實現，簡稱為 "DRBG".這實現了 NIST 在 SP-108 中指定的動態隨機位生成器列表.這些也不是 Java 實現要求.但是，如果需要符合 FIPS 標準的隨機數生成器，則可以使用它們.
Nowadays (Java 9 onwards) the OpenJDK and Oracle JDK also contain multiple implementations that are simply called "DRBG". This implements a list of Dynamic Random Bit Generators specified by NIST in SP-108. These are not Java implementation requirements either. They could however be used if a FIPS compliant random number generator is required.
但是，他們并沒有改變這里的建議；如果開發人員認為這些比默認實現更好，那么他們只會將其設為默認實現.SecureRandom 的合約沒有改變:它只需要生成隨機數.過去已經對默認算法進行了更改.
However, they do not change the recommendations here; if the developers thought that these were better than the default implementation then they would simply have made it the default. The contract of SecureRandom doesn't change: it is simply required to generate random numbers. Changes to the default algorithm have already been made in the past.
一般來說，要求特定的提供者也不是一個好主意.指定提供者可能會損害互操作性；例如，并非每個 Java 運行時都可以訪問 SUN 提供程序——Android 肯定沒有.它還使您的應用程序在運行時的靈活性降低，即您不能將提供程序放在列表中更高的位置并使用它.
In general it's not a good idea to require a specific provider either. Specifying a provider may hurt interoperability; not every Java runtime may have access to the SUN provider for instance - Android certainly hasn't. It also makes your application less flexible at runtime, i.e. you cannot put a provider higher in the list and use that instead.
因此，僅當您依賴某個提供商提供的功能時，才需要指明該提供商.例如，如果您有生成隨機數的特定硬件設備或已通過 FIPS 認證的加密庫，您可能需要指定提供程序.如果您必須指定提供程序，最好將算法/提供程序作為您的應用程序的配置選項.
So only indicate a provider if you are dependent on one of the features that it supplies. For instance, you might want to specify a provider if you have a specific hardware device that generates the randoms, or a cryptographic library that has been FIPS certified. It's probably a good idea to make the algorithm/provider a configuration option for your application if you have to specify a provider.
這個Android 開發者安全博客.
因此，請盡量避免選擇任何特定的隨機生成器.相反，只需使用空參數構造函數:new SecureRandom() 讓系統選擇最佳的隨機數生成器.可以使用新的可配置
So try and refrain from choosing any specific random generator. Instead, simply go for the empty argument constructor: new SecureRandom() and let the system choose the best random number generator. It is possible to use the new configurable SecureRandom.getInstanceStrong() in Java 8 and higher if you have any specific requirements for e.g. long term key generation.
不要緩存 SecureRandom 的實例，只需讓它們最初自己播種并讓VM處理它們.我沒有看到操作上有明顯的不同.
Don't cache instances of SecureRandom, just let them seed themselves initially and let the VM handle them. I did not see a noticeable difference in operation.
什么時候根本不使用 SecureRandom:
作為一般警告，我強烈建議不要將隨機數生成器用于隨機數生成以外的任何事情.即使您可以自己播種，即使您選擇 Sun 的 SHA1PRNG，也不要指望能夠從隨機數生成器中提取相同的隨機數序列.所以不要將它用于從密碼中派生密鑰，僅舉一個例子.
As a general warning I strongly advice against using the random number generator for anything other than random number generation. Even if you can seed it yourself and even if you choose Sun's SHA1PRNG, don't count on being able to extract the same sequence of random numbers from the random number generator. So do not use it for key derivation from passwords, to name one example.
如果您確實需要重復序列，則使用流密碼并將種子信息用于密鑰和 IV.加密由零組成的明文以檢索偽隨機值的密鑰流.或者，您可以使用可擴展輸出函數 (XOF)，例如 SHAKE128 或 SHAKE256(如果可用).
If you do require a repeating sequence then use a stream cipher and use the seed information for the key and IV. Encrypt plaintext consisting of zeros to retrieve the key stream of pseudo random values. Alternatively you could use a extendable-output function (XOF) such as SHAKE128 or SHAKE256 (where available).
如果可用的 RNG 提供的性能不足并且安全不是問題，您可能需要考慮使用不同的非安全隨機數生成器來代替 SecureRandom.SecureRandom 實現不會像 Mersenne Twister 算法或 Random 類.這些已針對簡單性和速度而非安全性進行了優化.
You may want to consider a different, non-secure random number generator instead of SecureRandom if the available RNG's deliver insufficient performance and if security is not an issue. No SecureRandom implementation will be as fast as non secure random number generators such as the Mersenne Twister algorithm or the algorithm implemented by the Random class. Those have been optimized for simplicity and speed rather than security.
可以擴展 SecureRandom 類并將確定性的種子隨機實現插入到庫調用中.這樣，庫檢索具有明確定義輸出的偽隨機數生成器.然而應該注意，隨機數生成器可以由算法以不同的方式使用.例如.RSA 可能會切換到更好的優化方式來查找素數，并且 DES 密鑰可以通過調整或直接計算的奇偶校驗位生成.
It is possible to extend the SecureRandom class and insert a deterministic, seeded random implementation into a library call. That way the library retrieves a pseudo random number generator with well defined output. It should however be noted that the random number generator may be used in different ways by algorithms. E.g. RSA may switch to a better optimized way of finding primes and DES keys may be generated with adjusted or directly calculated parity bits.
這篇關于SecureRandom 與 NativePRNG 與 SHA1PRNG的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！