SecureRandom not so secure!?
Correct me if I'm wrong (and give an explanation of why), but it seems to me the the SecureRandom class that can be used for cryptography is, by it's design, insecure. The problem lies is the seed. Now being able to seed your random number generator is great, and very useful. However, it only takes up to a 48-bit seed, which means that it can only produce a maximun of 2^48 possible sequences of digits, or bytes for a key. This is a major problem, because it is no better then having a 48-bit encryption key in the first place! Even if you were to generate a 100MB key from this "secure" random number generator the resulting sequence would be no more secure than it's 48-bit seed.
Cracking a 48-bit key is child's play for a major corporation (one with the funding) that may be trying to break into your company's database. C'mon now, a 48-bit key in cryptography may as well be no key at all!
-Jeff L.
I checked a bit at the Bug database, I didn't see anything filed about it. Maybe you should file a bug on this, it makes sense to me. http://developer.java.sun.com/developer/bugParade/index.jshtml
Hi,
If you look at the SecureRandom class, the setSeed() method updates the internal state of the pseudo random number generator (PRNG) instead of replacing it. This means that calling setSeed() never decreases the entropy of the PRNG's state.
Because the PRNG is based on 160-bit SHA-1 hash algorithm, I suspect the internal state of the PRNG is at least 160-bit (which is sufficient for secure cryptographic operations).
I don't know the implementation details of the SecureRandom PRNG. Is there someone who knows how SecureRandom is implemented or has the source code of its implementation?
Regards,
Ronald Maas
I believe the following happens for SecureRandom.
A thread, "sleeper", is created and sleeps for a certain period of time. Another thread, "waiter" is created and calls Thread.yield(). A count is kept of the number of times "waiter" called yield, while "sleeper" was sleeping. This count is then used to provide a seed to a PRNG. The lower order bits of this count are used.
I think you got the "only uses 48-bits" from java.util.Random. It says however that an overriding method may use all 64 bits. Also, I cannot find anywhere in the SecureRandom source where it limits the number of bytes for a seed to either 48 or 64-bits. SecureRandom does take a byte[] as a seed.
These bits are used to seed a PRNG. If you are using the default it is SHA-1, which produces a 160-bit hash from any given number of input bits. All subsequent bits are derived from the PRNG. What this means is if you know the original seed, you can reproduce the entire sequence of bits. That's why the seed should be as random as possible.
If the seed where on 48-bits, and you could find it out (brute force or otherwise), then you would still have to figure out how many bits into the series you are before you could use that PRNG.
I have not read anything on how secure this method of seeding is, if you are on Unix try looking for /dev/random or dev/audio..
