Please Review: required security algorithms for Java SE 7 implementations

Sean Mullan sean.mullan at
Thu Dec 16 10:26:24 PST 2010

On 12/16/2010 11:30 AM, Florian Weimer wrote:
> * Sean Mullan:
>> On 12/15/10 10:38 AM, Florian Weimer wrote:
>>> * Sean Mullan:
>>>> Please review the following list:
>>> "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.
> Oh, and I just realized that MD5 and HmacMD5 are missing.  These
> algorithms are still heavily used (and HmacMD5 is not really broken,
> it's only guilty by association).

Yes, MD5 is still in use, but I think it is decreasing in use 
significantly. Can you give more rationale, for example data that would 
suggest that not making these algorithms a requirement would affect a 
significant number of Java applications or where SHA-1/HmacSHA1 would 
not be an adequate alternative?

Also, just FYI but we have no plans to remove support for MD5 and 
HmacMD5 from OpenJDK.

>>> 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:
> I think it's prudent to require TLS_RSA_WITH_AES_128_CBC_SHA as well
> (which is mandatory per RFC 5246).  And RFC 5746 support should be
> required, too (which includes TLS_EMPTY_RENEGOTIATION_INFO_SCSV).

TLS_RSA_WITH_AES_128_CBC_SHA is not listed because we did not specify 
that TLS 1.1 or TLS 1.2 should be requirements. TLS 1.1 and 1.2 are new 
features of JDK 7 and AFAIU are not as widely used as TLS 1.0 yet.

Brad, can you comment on the RFC 5746 support? Do you think we should 
make the TLS_EMPTY_RENEGOTIATION_INFO_SCSV CipherSuite a requirement of 
all Java 7 TLS 1.0 implementations?

>>> 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.
> Basically, I'd like to have a class which provides reasonable default
> implementations for common mandatory algorithms, without having to go
> through SPIs etc.  That is, a class which implements an interface like
> this:
> interface DefaultMessageDigests {
>    MessageDigest newMD5();
>    MessageDigest newSHA1();
>    MessageDigest newSHA256();
> }
> For other types of primitives, this may make less sense because they
> generally have tweakable parameters.

Maybe we could do something like that, although I would also like to 
understand the SPI issues better and see if we could look at ways of 
reducing that overhead without coming with new APIs.


More information about the security-dev mailing list