JuiCE - some ideas and a proposed draft "roadmap"

[Werner Dittmann <We...@t-online.de>]

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

Re: JuiCE - some ideas and a proposed draft "roadmap"

[Walter Hoehn <wa...@memphis.edu>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: juice-dev-help@xml.apache.org

Re: JuiCE - some ideas and a proposed draft "roadmap"

[Walter Hoehn <wa...@memphis.edu>]

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

RE: JuiCE - some ideas and a proposed draft "roadmap"

[Scott Cantor <ca...@osu.edu>]

> 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.

The JuiCE idea came from some early work that was done by some developers on
the Shibboleth (and OpenSAML) projects because early versions of xmlsec were
extremely slow. At the time, something like JuiCE seemed like a worthwhile
project and some people involved with WSS4J asked if we'd donate the
project, so we did.

Shortly after that, Raul (bless him) got involved with the xmlsec code and
did a serious number on it that basically tripled the performance overnight.
Needless to say, the impetus for JuiCE lost its, umm, juice.

There's certainly no objection on our part to somebody reviving it if
there's interest and effort there.

I think one small issue left for JuiCE was to make it properly thread safe.

> 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

I think that's only required for certain things, but I don't really remember
anymore. I know it was tested a bit by us without doing that.

> Btw: I havn't checked it - but who has write access to the JuiCE
> SVN repos? Or can grant write access to it?

I don't know if it's SVN, actually. I know of some of the Shib folks that
had write access, they can chime in, but I think we'd be happy to see others
take the lead on it.

-- Scott