I did a lot of playing around yesterday. I added a note to the bug
showing where the 16 byte salt is set as a #define and used no matter
what algorithm is passed in from JSS. Unfortunately that didn't help
out with decrypting the key.
What I have determined is that if JSS creates an EPKI structure, it is
readable elsewhere whereas the NSS EPKI is mostly only readable by NSS.
2 things I'd like to point out:
- The password converter. I need to pass one into the EPKI.decrypt
method in JSS. The *only* way I can decrypt an NSS EPKI is with the
following:
class PWConverter implements KeyGenerator.CharToByteConverter {
public byte[] convert(char[] chars) {
try {
String s = new String(chars);
byte[] raw = s.getBytes("UTF-8");
byte[] cooked = new byte[raw.length + 1];
System.arraycopy(raw, 0, cooked, 0, raw.length);
// Hex hex = new Hex();
// System.out.println("password bytes : " + new
String(hex.encode(cooked), "UTF-8"));
return cooked;
}
catch (Exception e) {
return null;
}
}
}
SafeBag.createEncryptedPrivateKeyBag
(http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/pkcs12/SafeBag.java#307)
creates an EPKI internally from the PrivateKeyInfo (PKI) you pass in.
When it creates the EPKI it passes in a
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/pkcs12/PasswordConverter.java.
If I pass one of these to the decrypt method of the EPKI class on an
NSS generated EPKI the ASN1 decode fails, presumably because the decrypt
went wrong. My guess is something is different between the C and Java
representations of the password.
Again, loading the epki from the filesystem that I mentioned above (that
was generated by JSS) I tested using the EPKI.decrypt both with null and
"new PasswordCoverter()" as the second argument. null resulted in an
error about padding, "new PasswordConverter()" was able to successfully
decrypt the EPKI. Perhaps NSS and JSS are generating different bytes
out the password and hence different sym. keys?
- Somewhat related to the first point. I changed the code for SafeBag
class to write out the EPKI it creates during
createEncryptedPrivateKeyBag. This EPKI is readable via OpenSSL
(openssl pkcs8 -in test.p8 -inform DER).
After seeing this, I changed my PKCS12 code to read that p8 from the
filesystem instead of actually extracting it from the db. In this case
I was able to decrypt the key using only Java methods into a PKI, use
ASN1Util to decode it back into a JSS PKI and continue on building the
PKCS12. The resulting PKCS12 is readable by OpenSSL, Java and MS-CAPI.
All of this testing was done using PBEAlgorithm.PBE_SHA1_DES3_CBC since
the SafeBag.createEncryptedPrivateKeyBag method is hardcoded to use
that, and I'd like to use that one anyway.
Hopefully I've presented this info in a somewhat coherent manner.
Dave
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
