Thanks once again! > So to sum it up I see 3 ways to try to fix this: > 1. Follow david's advice and try to have BC loaded alongside with the > IBM JCE. The WSS4J > will see its already loaded and not try to reaload it
I tried that. It seems to break other websphere stuff. > 2. Try somehow to force usage of the BC implementation of > javax.crypto.* > instead of IBM's - > this will prevent cross-classloader issues. I'm trying to figure out a way to do that. > 3. Overload your thread classloader - and implement protection of some > classes via the > loadClass(String) method and try to manually load the BC JCE > in the JCE > classloader. I'll try that if I can't do #2. cheers, md > -----Original Message----- > From: George Stanchev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 1:44 PM > To: Davis, Michael; [EMAIL PROTECTED] > Cc: [email protected]; [EMAIL PROTECTED] > Subject: RE: [dev-crypto] Bug in Cipher class? > > > > Michael, > > Unfortunately (or at least that's how I understand it) > in your case you don't have control over the classloader that > is running > WSS4J to > do delegate the loading to the system classloader. In my case, I have > implemented > my own isolating classloader and I haveoverloaded the > loadClass() method > to "protect" > some classes - if they are on the protection list, their loading is > delegated to the parent > classloader. > > I am not familiar with > websphere but does it load the IBM JCE in a separate, higher > classloader > then your > Thread.getCurrentThread().getContextClassloader()? And why is your > javax.crypto.Cipher > picked up from the websphere classloader instead of the BC's provided > javax.crypto.Cipher (they do provide an implementation withing their > JCE)? > If you can make your app to load javax.crypto.Cipher from the > BC JCE in > the > application CL, I think woould fix your problem. > > Best Regards, > George > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 10:53 AM > To: [EMAIL PROTECTED] > Cc: [email protected]; [EMAIL PROTECTED] > Subject: RE: [dev-crypto] Bug in Cipher class? > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
