Menu
I have been using SecureRandom with a seeded SHA1PRNG algorithm to create shared randomness between two processes. I recently learned that SHA1 is being deprecated according to NIST's standards, so we are making an effort to switch to SHA256. The problem I've discovered is that SecureRandom ONLY supports SHA1PRNG, at least according to Oracle's documentation. I was wondering if there's a way to use SecureRandom with SHA256, or probably better, what is a suitable alternative to using SecureRandom?
576
It is known that SecureRandom class provide strong cryptographic security for generated random number. java. util. Random is insecure for the situation which requires cryptographic security.
Therefore, it is not safe to use this class for tasks that require a high level of security, like creating a random password etc. Size: A Random class has only 48 bits whereas SecureRandom can have up to 128 bits. So the chances of repeating in SecureRandom are smaller.
public SecureRandom(byte[] seed) Constructs a secure random number generator (RNG) implementing the default random number algorithm. The SecureRandom instance is seeded with the specified seed bytes. This constructor traverses the list of registered security Providers, starting with the most preferred Provider.
SHA-256 is one of the most secure hashing functions on the market. The US government requires its agencies to protect certain sensitive information using SHA-256.
David, as I understand you are referring to this document: http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
May be, I am missing something. However, what it says:
From January 1, 2011 through December 31, 2013, the use of SHA-1 is deprecated
for digital signature generation. The user must accept risk when SHA-1 is used,
particularly when approaching the December 31, 2013 upper limit.
However, below it says
For all other hash function applications, the use of SHA-1 is acceptable. The
other applications include HMAC, Key Derivation Functions (KDFs), Random Number
Generation (RNGs and RBGs), and hash-only applications (e.g., hashing passwords
and using SHA-1 to compute a checksum, such as the approved integrity technique
specified in Section 4.6.1 of [FIPS 140-2]).
So, as I understand SHA1 is ok for random number generation.
173
I agree to Victor's statement overall. But as a further clarification, section 4 of NIST SP800-131a has a table that separates RNGs NOT using RBGs as mentioned in NIST SP800-90 or ANSI X9.62-2005 will time out in 2015.
25
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
