[EMAIL PROTECTED] wrote:
Very helpful information guys, thanx...
I am using bouncycastle, which should handle ISO10126 padding even in
1.4 though, right?
Yes, I believe so, although I haven't tried it. But that's the whole
point of the extensible security provider framework.
The issue then becomes, why isn't it finding the bouncycastle provider
under 1.4 like it does under 1.5.
I dump the providers and it is there, it just isn't being select (by
Cipher?) like it is under 1.5.
[2008-08-11 16:22:33,367] DEBUG: Provider=IBMJCE version
1.2:PBEWithSHA-1And128BitRC4
...
[2008-08-11 16:22:33,368] DEBUG: Provider=IBMJCE version 1.2:AES
...
[2008-08-11 16:22:33,372] DEBUG: Provider=BC version
1.4:RSA//ISO9796-1PADDING
...
[2008-08-11 16:22:33,374] DEBUG: Provider=BC version 1.4:AES <<<<
target, based on sucessful trace
...
[2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:DES
[2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version
1.42:PBEWithMD5AndTripleDES
[2008-08-11 16:22:33,382] DEBUG: Provider=SunJCE version 1.42:AES
...
I'm not sure. Assuming you're loading the providers in the same
relative order in 1.4 and 1.5: Maybe the provider lookup behavior in
java.security.Security is different in 1.4 vs. 1.5? Maybe Sean knows.
Where are you loading the BC provider in the provider list relative to
the IBMJCE one? If you're loading it after the IBM one, maybe the
lookup behavior is such that it resolves the
java.security.Provider.Service (type=Cipher) based only on the algorithm
(AES) or possibly algorithm + mode (CBC). Then the IBM provider service
impl gets resolved first, but then doesn't support the padding.
The real test would be if you get different behavior from this:
Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding", "BC");
versus this:
Cipher xmlEncCiperAES = Cipher.getInstance("AES/CBC/ISO10126Padding");
If the first works, but the latter doesn't (throws NoSuchPadding or
NoSuchAlgorithm exceptions), then that answers the question.
If that proves to be the case: Note that you can specify a particular
security provider to use in xmlsec for encryption/decryption with the
XMLCipher#getProviderInstance variants instead of the usual
XMLCipher#getInstance. That will let you get around whatever preferred
order lookup behavior might be going on.
--Brent
