Thanks very much, George. First I'll try your solution to see if I can get it to work. If I understand correctly, I need to do this:
ClassLoader cl = java.security.Security.class.getClassLoader(); Class bcClass = cl.loadClass( "org.bouncycastle.jce.provider.BouncyCastleProvider" ); But I'm not sure how to do the next step: "and then restricting the javax.crypto.* and org.bouncycastle.* packages to be always loaded from the parent classloader." I also tried doing: Cipher cipher = Cipher.getInstance( algo, new BouncyCastleProvider() ); but it didn't work for the reasons you explain below. cheers, md > -----Original Message----- > From: George Stanchev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 12:40 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [dev-crypto] Bug in Cipher class? > > > I ran into similar problem with the BC provider supplied with axis2 > since > my app is running in an isolating classloader. For me, I was > able to fix > it by loading the BC JCE provider in the > java.security.Security.class.getClassLoader() > classloader and then restricting the javax.crypto.* and > org.bouncycastle.* packages > to be always loaded from the parent classloader. Of course if the > security restrictions > forbid me of getting a hold of the JCE classloader I am screwed and my > users need to > add the jars manually to the jre/lib/ext directory as David indicated > below. > > If WSS4J is relying on BC, then it should assure the proper > classloader > picks up the > package. > > An alternative solution would be to not go via the > java.security.Security JCE registry > and use the JCE provider directly via XXX.getInstance(String > transformation, Provider prov) > calls. But for some reason (and here the WSS4J developers can > chime in) > WSS4J relies on > the Java 1.3 JCE interfaces which lack those methods and need > to go via > the security registry. > > WSS4J devs, is there a reason to stay with the 1.3 BC provider or you > can switch to the BC's JDK 1.4 > provider? > > Michael, I think its worth submitting a JIRA against that issue. > > Best Regards, > George > > -----Original Message----- > From: David Hook [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 5:00 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [email protected] > Subject: RE: [dev-crypto] Bug in Cipher class? > > > Try putting the provider jar in jre/lib/ext and add BC to the > java.security file as well. > > Regards, > > David > > On Tue, 2007-07-17 at 11:03 -0400, [EMAIL PROTECTED] > wrote: > > Thanks very much for your reply, David. Now I have something to work > with. > > > > I tried removing the BouncyCastle jar from my project, but it looks > > like wss4j requires it. When I remove it, I get an error > saying that > > Cipher can't find a provider supporting the algorithm. I > tried it with > > > the algorithms defined in wss4j, namely > > > > AES/CBC/ISO10126Padding and DESede/CBC/ISO10126Padding. > > > > this happens both on Sun's java with providers SUN, SunJSSE, > SunRsaSign, SunJCE and SunJGSS, and on IBM's java with > providers IBMJCE, > IBMJSSE, IBMJGSSProvider, IBMCertPath and IBMPKCS11. (I get those by > printing out what's returned by Security.getProviders() ). > > > > I tried setting the algorithm to "AES" to see if that > works, but that > causes a null pointer exception in wss4j, so I figure I need > to use the > ones that are defined in wss4j. > > > > So I'm stuck. With IBM's java, I get the class loader issue if I > supply the BouncyCastle jar, and I get an > UnsupportedAlgorithm exception > if I don't. > > > > Any hints would be very gratefully appreciated! > > > > cheers, > > Michael Davis > > > > > > > -----Original Message----- > > > From: David Hook [mailto:[EMAIL PROTECTED] > > > Sent: Monday, July 16, 2007 8:35 PM > > > To: Davis, Michael > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: [dev-crypto] Bug in Cipher class? > > > > > > > > > > > > It's a class loader issue - ciphers need to be loaded by > the system > > > class loader as the JCE is loaded by it. If the provider jar gets > > > loaded by another untrusted class loader the > getInstance() call on > > > Cipher will fail with either ClassNotFoundException if no other > > > class loader can return the class, or ClassCastException if the > > > class is returned by a class loader but isn't properly annotated. > > > > > > You need to make sure the same class loader is picking up the > > > provider jars as is picking up the JCE classes. > > > > > > Regards, > > > > > > David > > > On Mon, 2007-07-16 at 15:08 -0400, > [EMAIL PROTECTED] > > > wrote: > > > > Hi, > > > > > > > > I've asked this question on the Apache xml security mailing > > > list, but I got no answer. I figure you folks must be experts on > > > this stuff, so... > > > > > > > > I'm developing a web service using Axis2. I'm using its > > > WS-Security framework to encrypt the xml messages. This framework > > > ultimately uses the Apache XML Security library, which > has this line > > > > of code: > > > > > > > > instance._contextCipher = Cipher.getInstance(jceAlgorithm); > > > > > > > > This works fine using the Sun jdk1.4, which uses Sun's > > > jce.jar and sunjce_provider.jar. It also works fine using the > > > BouncyCastle classes - Sun's Cipher class finds and returns the > > > appropriate BC class. > > > > > > > > However, when I try to run the app on WebSphere 5.1, I get > > > this error: > > > > > > > > java.lang.ClassCastException: > com.ibm.crypto.provider.AESCipher at > > > > > javax.crypto.Cipher.getInstance(Unknown Source) > > > > > > > > This is getting thrown by IBM's javax.crypto.Cipher class > > > in ibmjcefw.jar. > > > > > > > > This happens even if I manipuate the providers to load the > > > BC classes first - in that case the class causing the > > > ClassCastException is > > > org.bouncycastle.jce.provider.JCEBlockCipher$AES. > > > > > > > > Have any of you ever seen this problem before? > > > > > > > > Many thanks, > > > > Michael Davis > > > > Ottawa > > > > > > > > > > > > > > > > > > > > > > > > > ********************************************************************** > This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity > to whom they are addressed. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > ********************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
