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
