No, you should avoid the SecureRandom(byte[])
constructor. It is both unsafe and non-portable.
It is non-portable because it behaves differently on Windows vs. other operating systems.
On most OSes, the default algorithm is "NativePRNG", which obtains random data from the OS (usually "/dev/random"
) and ignores the seed you provide.
On Windows, the default algorithm is "SHA1PRNG", which combines your seed with a counter and computes a hash of the result.
This is bad news in your example, because the input (the current UTC time in milliseconds) has a relatively small range of possible values. For example if an attacker knows that the RNG was seeded in the last 48 hours, they can narrow the seed down to less than 228 possible values, i.e. you have only 27 bits of entropy.
If on the other hand you had used the default SecureRandom()
constructor on Windows, it would have called the native CryptoGenRandom
function to get a 128-bit seed. So by specifying your own seed you have weakened the security.
If you really want to override the default seed (e.g. for unit testing) you should also specify the algorithm. E.g.
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
sr.setSeed("abcdefghijklmnop".getBytes("us-ascii"));
See also How to solve performance problem with Java SecureRandom?
and this blog post: http://www.cigital.com/justice-league-blog/2009/08/14/proper-use-of-javas-securerandom/
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…