hi David,
you should file two bugs:
JSS has different Salt size than NSS for PBE
NSS appears to only handle PBE_SHA1_DES3_CBC for PKCS12
I will try to work on the bugs shortly.
thanks,
glen
David Stutzman wrote:
> David Stutzman wrote:
>
>> I'm generating keys in the softoken and then exporting them to PKCS12
>> files with their freshly issued certs. I get the private key using the
>> getEncryptedPrivateKeyInfo method of CryptoStore.
>>
>> This epki is reporting a 16 byte salt but when I ask the algorithm for
>> its salt size, I get 20.
>>
>> When I try to unwrap the key I get:
>> javax.crypto.BadPaddingException: Given final block not properly padded
>>
>> Using PBEAlgorithm pbeAlgorithm = PBEAlgorithm.PBE_SHA1_DES3_CBC;
>> pbeAlgorithm.getSaltLength() = 20
>>
>> Encrypted private key info's salt: 0x6d469a0e62d57c5482e589562eeb2236
>>
>> I've tried some of the other algorithms and it appears the
>> getEncryptedPrivateKeyInfo (which is one of the native methods of JSS)
>> *always* returns an EPKI with 16 bytes of salt and it's confusing other
>> applications/APIs that are expecting more or less (8 and 20 seem to be
>> the most popular).
>>
>> Dave
>>
>
> If it matters...The reason I need to decrypt the key first is that if I
> just take the EPKI structure and pass it right into the PKCS12, then it
> can only be read by MS-CAPI and java's keytool. OpenSSL will not be
> able to read the resulting PKCS12 file.
> I am also constrained to using PBE_SHA1_DES3_CBC as the other algorithms
> result in PKCS12 files that are unreadable by anything but NSS itself.
> That's not a huge issue as that is the algorithm I would like to use
> anyway, just mentioning it for the compatibility angle.
>
> If I use keytool -list -keystore foo.p12 -storetype PKCS12 then Java can
> read the resulting PKCS12 even though I can't seem to decrypt the EPKI
> myself programatically. keytool reports that it is using the SunJSSE
> provider for the KeyStore implementation.
>
> When I re-encrypt the key using the SafeBag.createEncryptedPrivateKeyBag
> method I end up with algorithm parameters that make sense. The method
> calls PBEAlgorithm .getSaltLength() and ends up with a 20 byte salt and
> uses "DEFAULT_ITERATIONS" of 1. These structures can be handled by all
> other toolkits I've tested with:
> 100 25: . . . . . . . . . . . . . SEQUENCE {
> <04 14>
> 102 20: . . . . . . . . . . . . . . OCTET STRING
> : . . . . . . . . . 11 37 D3 96 E3 DB 55 24 .7....U$
> : . . . . . . . . . B4 EA 64 7E 15 B0 CB D6 ..d~....
> : . . . . . . . . . 8C F3 38 2E ..8.
> <02 01>
> 124 1: . . . . . . . . . . . . . . INTEGER 1
> : . . . . . . . . . . . . . . }
>
> I'm open to tweaking the NSS code, if necessary. I *think* I see where
> the salt/iteration count are being obtained in
> http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11pbe.c#409
>
> Would I be barking up the wrong tree if I was looking in there for
> changing the size of the salt?
>
> I guess another question, why does NSS use a different salt size for the
> same algorithm than JSS?
>
> Thanks,
> Dave
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
