David,
I agree with Glen that there are (at least) two separate issues here,
and that bugs should be filed on both of them.
The first issue is (apparently) that PKCS#12 files created with JSS
that use an algorithm other than PBE_SHA1_DES3_CBC are unreadable by
OpenSSL. The bug should be filed against JSS. Please include code
and steps by which the problem can be reproduced.
JSS includes some SAMPLE code for creating PKCS#12 files. It's not
technically part of JSS (as I understand it) and it's known to have
several faults. So, odds are good that this is just a problem with
that JSS sample code.
If that problem turns out to NOT be JSS code, but is lower level,
then this is potentially an NSS-OpenSSL interoperability issue.
If we determine that it is, then we'll turn the bug into an NSS bug.
It might prove to be an OpenSSL issue rather than an NSS issue.
The second issue is some inconsistent results regarding PBE salt size.
The most we can say (based on the report quoted below) is that the
results disagree with each other. It's difficult to say which is wrong.
Again, this should be filed as a JSS bug, and it should include steps
and/or code to reproduce the problem.
Thanks.
Glen Beasley wrote:
> 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
>>
>
--
Nelson B
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
