Hi Florian,
SecureRandom is still underspecified. Most applications want an
algorithm which cannot block and will not wait for true, physical
randomness to arrive. If such applications accidentally use a
blocking generator (such as /dev/random on Linux without special
hardware support), then things don't work at all, and perhaps
developers will use java.util.Random instead.
Sadly, the SecureRandom code in the underlying "Sun" Provider
implementation (NativePRNG/SHA1PRNG) needs work.
We have one defined algorithm in the Standard Algorithm Name
documentation (SHA1PRNG). The algorithm is not standardized, and there
is no discussion about quality or blocking issues, just some Sun
implementation details that affect how the implementation seeds.
I'm hoping to clean this up some for JDK 7, possibly by creating new
algorithm names that require certain properties. Those names will then
be required. Something like:
NonBlocking - Implementations may not block when
obtaining nextBytes/seeds (appropriate for
shorter-term secrets and keys)
HighQuality - Implementations return the highest-quality
random numbers available (appropriate for important
or long-lived secrets and keys). May block.
They would roughly correspond to /dev/random and /dev/urandom in the
Unix World, and would probably be based on the current NativePRNG.
Until we get this straightened out, we were just planning to say:
[1] No specific SecureRandom algorithm is required; however, an
implementation-specific default must be provided.
Brad
