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
