Thought we might move this discussion over the juice-dev....
On Nov 8, 2005, at 1:51 PM, Werner Dittmann wrote:
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.
Right you are, nothing has been added for a long time. The mailing lists were created and have been used on rare occasion. I'm quite amazed, though, that every few months I hear mention of somebody using this code in a production shibboleth deployment.
After looking at the JuiCE stuff I think we can enhance it a bit. 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.
Right. This sort of thing is only useful if you can plug it in just like any other JCE implementation. The early work was focused on implementing the specific algorithms that we needed for the Shibboleth project.
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".
Agreed.
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.
Right.
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).
If you are hoping to actively evolve the code, I'm certain that nobody would object to these sorts of changes. If I remember correctly, some amount of care was taken to add gnu autotools support. It would be nice if you built on this.
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
This is need by some algorithms, but not by all. I can't remember the breakdown, but it would certainly be nice to have the cert...
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?
I think the committers are: Walter Hoehn Noah Levitt Berin Lautenbach Lautenbach
Comments? Ideas?
The two main work items that were outstanding when the project was last discussed were implementing the openssl threading callbacks and investigating the adding of support for openssl-engine. At the time, it seemed that more hardware crypto devices worked (or worked reliably) with openssl than with the JCE.
-Walter
