Please Review: required security algorithms for Java SE 7 implementations
Brad Wetmore
bradford.wetmore at oracle.com
Fri Dec 17 03:35:07 UTC 2010
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
More information about the security-dev
mailing list