All,
while working on some performance improvements for WSS4J I
implemented a first draft of an openSSL binding for
BouncyCastle. It proved to give some good results.
Dims pointed me to the Apache JuiCE project (incubator)
that has a similar goal - providing a JCE security provider
that uses openSSL as underlying crypto implementation.
Well, JuiCE seems to be dormant since about 1 1/2 year. The
homepage still says the mailing lists need to be created - thus
I'm sending this info to WSS4J and security-dev to get some
info and feedback to the proposals/ideas listed below.
After looking at the JuiCE stuff I think we can enhance
it a bit.
Status:
======
As of now I have several ciphers up and running (DES, 3DES,
AES, all in several cipher modes), RSA.
Signatures are SHA-1/DSA, SHA-1/RSA, MD5/RSA, RIPEMD160/RSA,
maybe others can be build such as ECDSA.
Hashes are MD{2,4,5}, RIPEMD160, SHA-1. If the other variants
of SHA (up to SHA512) are compiled into openSSL libcrypt they
can be used too, also in Signatures.
The current implementation works together with BC. Feeding the
implemetation completely into BC would require to synchronize
the work with the knights of BouncyCastle because of all this
fuzz to have the JCE provider jars signed with a Sun approved
certificate etc.
Ideas, proposed JuiCE functionality:
===================================
Well, IMO JuiCE should concentrate its efforts to bind to
openSSL libcrypt, use it where it makes sense, and build
up a small provider for just the algorithms openSSL supports.
Then we have some quite fast algos at hand. One major
goal must be to stay JCE compliant and behave as a normal
JCE provider for some selected alorithms.
Other functions, such as keystore handling, x.509 certificate
handling (creation and such) should stay with Sun or BC (or
others) because these are not time critical and it would be
a waste of time and effort to "reinvent the wheel".
Because of the lookup mechanisms provided by Cipher
and other security classes a user may register JuiCE as
appropriate and use it instead of Sun's or the BC implementation.
Proposed next steps:
====================
I'll move over the code from my BC testbed (including
the unit tests) into JuiCE which may take some in-depth
modifications of existing JuiCE code, directory structure, etc,
copying and resue some BC code where appropriate (the BC
license is ok for this).
This code should then be ready to be used in WSS4J or similar
projects to speed up security processing. Because xml-sec also
provides ways to specify a specific provider for encryption and/or
signatures it can use JuiCE it as well.
There is one missing link: to use JuiCE we need a certificate signed
by Sun (Sun acting as a certificate authority in this case). There
is (somewhere in the latest doc about JCE provider)
a description how to get such a certificate - I can check it
and provide the necessary info. This certificate must be used to
sign the JuiCE jar
IMO it would be great if Apache as an organisation can get
this necessary certificate. This would enable us to build
and sign a JCE provider that works with every Sun JVM (I'm not
familiar how this works out for other JVMs).
After we got this important first step we can then do some
further enhancements to exploit the openSSL libcrypt, e.g.
looking at Diffie-Helman, Elliptic Curve, etc which may take
some time.
Btw: I havn't checked it - but who has write access to the JuiCE
SVN repos? Or can grant write access to it?
Comments? Ideas?
Regards,
Werner
