Please Review: required security algorithms for Java SE 7 implementations

Sean Mullan sean.mullan at oracle.com
Wed Dec 15 08:24:26 PST 2010


On 12/15/10 10:38 AM, Florian Weimer wrote:
> * Sean Mullan:
>
>> Please review the following list:
>> http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
>
> "SHA-1" or "SHA1"?  (Our code uses "SHA1" for some reason, perhaps for
> consistency with "HmacSHA1".)

"SHA-1" is the standard name, but Oracle's implementation (and probably most 
others) also accept "SHA1" as an alias.

> I think the TLSv1 cipher suite list is effectively much longer.
> Correct?

Yes, but only TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is mandatory. See section 9 of 
RFC 2246: http://www.ietf.org/rfc/rfc2246.txt

> There should also be some sort of factory to obtain the predefined
> algorithms.  Instantiation through the framework is quite slow.  For
> message digests, we currently rely on cloning a prototype object of
> the appropriate digest.

There aren't any plans to add something like this for JDK 7, but perhaps we can 
consider it for JDK 8. If you could sketch out a few more details of what you 
think the API would look like, that would help.

> 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.

Brad, would you like to comment on this?

Thanks for the comments.

--Sean





More information about the security-dev mailing list