Okay, now I'm really stuck.
I wrote my own class loader that loads the provider and the cipher classes from
the bc jar file. The bc implementation of Cipher.getInstance( String, Provider
) doesn't exist, rather it has the method getInstance( String, String ). I
figure the second argument is supposed to be the provider's name, e.g. 'BC'.
But I can't write
cipher = Cipher.getInstance( algo, provider.getName() );
because that won't compile, and if I do:
cipher = Cipher.getInstance( algo, provider );
then I still get that exception that started this whole thread:
java.lang.ClassCastException: com.ibm.crypto.provider.AESCipher
So here's what I did. I used my custom class loader to load bc's instance of
javax.crypto.Cipher. Then I did this:
Method method = clazz.getMethod( "getInstance", new Class[] { String.class,
String.class } );
instance._contextCipher = (Cipher) method.invoke( null, new Object[] {
jceAlgorithm, provider.getName() } );
Now, it must have invoked bc's Cipher class method because otherwise I would
have gotten a NoSuchMethodException or InvocationTargetException.
But I still got the same error:
java.lang.ClassCastException: com.ibm.crypto.provider.AESCipher
at
org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.java:65)
The dent in my wall, at head level, is getting deeper and deeper....
cheers,
md
> -----Original Message-----
> From: George Stanchev [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 6:26 PM
> To: Fred Dushin
> Cc: [email protected]
> Subject: RE: [dev-crypto] Bug in Cipher class?
>
>
> Hi Fred,
>
> I agree its hard to manage since all instantiations need to go
> through the custom provider and I agree most calls are in
> XML-Security.
>
> However it's a serious problem, and may be others can chime
> in on whats
> the best way to solve it.
>
> May be we can write a java.security.Security wrapper that instead of
> hitting the global JCE registry, hits our own registry. That
> wouldn't be
> too hard to implement. Then we load that implementation along with the
> BC provider and the classes within our context use us instead of the
> global Security object. If a transforamtion can be satisfied by the BC
> JCE provider
> then we pass along an implementation from it, otherwise we
> can delegate
> to the system registry and try to find a transformation there.
>
> Of course adding the BC to the /jre/lib/ext and properly
> registering it
> there would solve the problem but that really creates a
> strain on users.
>
> But you see the problem - if the thread context loader of WSS4J is
> different than
> the application loader (say a derivative) then there is a real chance
> of screwing up (especially since WSS4J tries to put the BC at slot 2!)
> by:
> 1. screwed up as Michael was when the javax.crypto.* classes try to
> instantiate
> a provider from a classloader they are not permitted (lower
> then them in
> the hierarchy) to see
> 2. Screw up other applications that try to do JCE
> transformationss that
> happen
> to stumble upon our provider.
>
> The real solutions are 2 - either we run BC JCE alongside the
> other JCE
> providers
> or run in isolation.
>
> Best Regards,
> George
>
> -----Original Message-----
> From: Fred Dushin [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 3:34 PM
> To: George Stanchev
> Cc: [email protected]
> Subject: Re: [dev-crypto] Bug in Cipher class?
>
> Hi George,
>
> Wouldn't this require that every call to XXX.getInstance(...) in WSS4J
> be modified to specify a provider?
>
> In general, I actually think that's a good idea (though probably very
> complex to manage!).
>
> But more to the point, I think many of these calls will not
> be found in
> WSS4J, but instead in Apache XML-Sec.
>
> Or am I missing something here?
>
> Thanks!
> Fred
>
>
> On Jul 18, 2007, at 12:39 PM, George Stanchev wrote:
>
> > 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.
>
>
> **********************************************************************
> 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]
