[security-dev 00330]: Re: Cleaning up crypto support

Mark Wielaard mark at klomp.org
Thu Sep 25 11:56:48 PDT 2008


Hi,

On Thu, 2008-08-28 at 15:44 +0200, Mark Wielaard wrote:
> There is still a lot of cruft in the codebase for preventing the usage
> of certain crypto algorithms or key-sizes. And we were actually shipping
> restricted policies preventing people from using unlimted crypto. Oops.
> 
> So if you saw: "java.securityInvalidKeyException: Illegal key size or
> default parameters" that was caused by wrongly installed security policy
> files. The code was actually there, just not properly activated.
> 
> This patch cleans up the crypto code so it doesn't go out of its way to
> prevent usage of "restricted crypto" and makes sure no restricted crypto
> security policies are installed.

I cleaned it up a bit more. It now removes all the unneeded classes like
JarVerifier (that didn't actually do anything) and JceSecurityManager
(that did all the unnecessary tricky class loader stack walking stuff)
and reduces the JceSecurity class to just the method getInstance() and
the static field RANDOM for the shared SecureRandom instance.

For now I also kept the canUseProvider() method, that can now just
return true. This last one was kept because the SecretKeyFactory,
KeyGenerator, Mac and KeyAgreement classes still call it. It could be
removed completely but I wanted to keep something that in principle
could be easily used for some closed proprietary version that still
insists on this "restricted crypto" thing.

I believe this version is pretty clean. And it should be simple to
verify that it works correctly now since all unnecessary code is just
thrown out. Of course I threw all the crypto and security tests at it
that I could find and all happily passed. I did alter the TestUtil class
so that it always checks all algorithms and full keys.

It would be nice to push this in OpenJDK proper so there is less
divergence and so the GPLed version always has full crypto support
enabled.

If you still want to support a ClosedJDK with restricted crypto support
then all you have to do it provide your own Cipher and JceSecurity
class, plus any of the now removed auxiliary classes JarVerfifier and
JceSecurityManager. Everything else can be the same between the free
openjdk and proprietary closedjdk.

Please let me know if you would need any help integrating this.
I did already push it into icedtea6.

Thanks,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-clean-crypto.patch
Type: text/x-patch
Size: 41904 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20080925/dc0d181c/icedtea-clean-crypto.patch 


More information about the security-dev mailing list