Very helpful information guys, thanx... I am using bouncycastle, which should handle ISO10126 padding even in 1.4 though, right? 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 ... This list is the same in 1.4 and 1.5 traces. Edward Thompson Sean Mullan <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/11/2008 04:27 PM Please respond to security-dev@xml.apache.org To security-dev@xml.apache.org cc Subject Re: JCEID to Service mapping Brent Putman wrote: > The JCEID algorithm identifier gets looked up by the relevant security > provider class (e.g. Cipher), and is based on all 3 parameters: the > cipher, mode and padding. > > This is highly platform vendor and version specific but as far as I > remember, support for the ISO10126 padding for XML Encryption was only > available in later versions of the default provider stacks that ships > with the Java runtimes. With Sun's, for example, I believe 1.4 did > *not* include support for that padding. This is correct. It is available in JDK 1.5 and up. > 1.5 does now, although not sure > about the initial patch revs. I seem to remember we had an issue in > our project with someone using IBM's 1.5 JRE about a year and a half > ago, and at that time they did not support that padding in the > then-current rev of 1.5. Not sure about now. In their 1.4 I'm guessing > most likely not supported either. I believe that is also correct (1.5 and up). BTW, I believe if you encode (or maybe its the other way around, I can't remember for sure) with PKCS5Padding and decode with ISO10126Padding, it is ok. It is only the other way around that you get problems. This might work if the application that encrypts cannot be upgraded (encode with JDK 1.4 and PKCS5Padding and decode with JDK 1.5 and ISO10126Padding), although you would have to tweak the algorithm URI mappings in config.xml to use PKCS5Padding instead. --Sean > If you can use recent Bouncy Castle security provider, that should get > you support for that padding (and larger AES encryption keys) for any of > the runtime platforms. FYI, depending on what other crypto things > you're doing, you may have to fiddle with the registered order of the > providers in order to get everything to work as expected. > > --Brent > > > [EMAIL PROTECTED] wrote: >> >> This isn't technically an XML Security issue, I know, but any help >> appreciated. >> >> Under Java 1.5 when I try to create a, XMLCipher, XMLCipher.AES_128 is >> mapped to a JCEID of AES/CBC/ISO10126Padding , whihc is then mapped to >> a bouncycastle service of AES. All is well. >> >> Under Java 1.4, XMLCipher.AES_128 is mapped to a JCEID of >> AES/CBC/ISO10126Padding, but no service provider can be found with >> trhat JCEID, even though I can dump the service providers and see 3 >> AES providers. >> >> When I say under 1.5/1.4, its actually Websphere 6.0 (which uses 1.4) >> and 6.1 (whihc uses 1.5). I am going to try to isolate the code >> outside of websphere to see if the behavior chnages, but trying to >> understand what maps AES/CBC/ISO10126Padding to a service... >> >> Ed Thompson >> >>
