Re: [GNU Crypto] How to replace Sun JCE+BouncyCastle with GNU JCE+BouncyCastle?

[Casey Marshall]

>>>>> "Kevin" == Kevin Smith <address@hidden> writes:

Kevin> Casey Marshall wrote:
>> Out of curiosity, what algorithms are we missing, in particular?

Kevin> SHA1WithRSA for signing.

Gotcha.

>> That might not work; you have to prepend those Jar files to the
>> bootclasspath, not your normal classpath.

Kevin> Hm. I've never dealt with bootclasspath before. I'm in eclipse
Kevin> at the moment, and eventually would also have to know the magic
Kevin> that would allow this to work on raw Linux, Mac, and Windows
Kevin> environments. Let's postpone going down that path while we
Kevin> explore the other possible cause(s) and solutions.

It is, I think, a fairly portable option. On the Linux JRE, you
prepend to the bootclasspath with

  -Xbootclasspath/p:<jars-and-dirs>

Presumably Win and Mac JRE's behave similarly.

AFAIK, overriding the bootclasspath is the only way to override the
standard library classes (java.* and javax.*) on Sun's JRE, except for
perhaps deleting Sun's jce.jar.

>> But also; why do you want to do this? Sun's JCE should be compatible
>> with the one we provide, and our algorithms should work under it,
>> provided that the jar file is signed first.

Kevin> Our app is intended to be installed and used by computer
Kevin> novices around the world. Requiring them to download and
Kevin> install the unlimited strength crypto policy file is
Kevin> unacceptable. Distributing the file ourself would apparently
Kevin> violate Sun's copyrights, so that's also unacceptable. We are
Kevin> faced with rewriting our code using the BouncyCastle
Kevin> lightweight API to bypass JCE, or to find a JCE that doesn't
Kevin> enforce those restrictions, like gnu-crypto.

That makes sense.

Kevin> I think we are indifferent about using BouncyCastle's JCE
Kevin> provider or the gnu-crypto JCE provider, as long as it is
Kevin> compatible with our existing data (including SHA1WithRSA
Kevin> signatures).

>> our javax-crypto.jar contains some BC code, including
>> some classes in the 'org.bouncycastle' namespace. It is likely that
>> one class is being loaded from our javax-crypto.jar, and another from
>> the BC jar. I rewrote the JCE from scratch, which is in our CVS
>> sources, and is also now a part of the GNU Classpath project.

Kevin> Ok. That makes sense, I think. How stable is your new JCE?

I couldn't say; it hasn't had enough testing. I personally think it is
cleaner code and a little more well architected, but that doesn't
imply that it is bug-free. BC's JCE implementation has a number of
bugs, too.

I do know that the only real problems are with CipherInputStream and
CipherOutputStream. The rest of the JCE API is fairly simple.

There are, however, a couple of things you can try:

  - Strip out the org.bouncycastle package from
    javax-crypto.jar. Since you are using BC anyway the jar with the
    BC provider should give you the classes you need, unless the
    versions of these classes are wildly different.

  - Strip out the signatures from the BC jar. This will certainly
    prevent the signature verification error you are currently seeing,
    but might still cause versioning problems if some classes have
    changed in a way that is not binary compatible.

Then again, this might Just Work if you properly install a clean room
javax.crypto. It is Sun's JCE that is checking jar signatures.

Kevin> Do you think it will be production quality and released soon?
Kevin> Or, will the gnu-crypto provider support SHA1WithRSA soon (or
Kevin> does it already and it just isn't documented)?

No, GNU Crypto doesn't support SHA1withRSA (we support RSA, but don't
implement the standard ASN.1 coding). I believe this is implemented in
CVS, along with the whole X.509 ball of mud.

That code, too, has been merged into GNU Classpath (since it necessary
for Classpath to have those algorithms). You could use the version in
Classpath without too much trouble, just copy the
'gnu/java/security/provider' package and maybe a few other classes.

I keep mentioning Classpath because that is where a lot more
development energy is focused right now. It does not currently support
the same diversity of crypto algorithms as GNU Crypto, but work is
underway to change that.

Kevin> I suppose the third option would be for me to try to rename
Kevin> packages or strip out parts of the existing gnu-crypto,
Kevin> bouncy-castle-based JCE to try to get it to work with the
Kevin> BouncyCastle provider.

Renaming classes is your best hope, if nothing else works (and if you
don't feel like cobbling together disparate pieces of other GNU
packages).

-- 
Casey Marshall || address@hidden