Please Review: required security algorithms for Java SE 7 implementations

Brad Wetmore bradford.wetmore at oracle.com
Thu Dec 16 19:35:07 PST 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