Hack to allow ec_private_key_openssl loading keys generated with NSS.

crypto/ec_private_key_openssl.cc

Index: crypto/ec_private_key_openssl.cc
diff --git a/crypto/ec_private_key_openssl.cc b/crypto/ec_private_key_openssl.cc
index ce921dde15f6d1d96e46e286d2f45eb95440ee16..8504ab50c357ceb2b2f9afffc4dbb63c242fd84f 100644
--- a/crypto/ec_private_key_openssl.cc
+++ b/crypto/ec_private_key_openssl.cc
@@ -132,6 +132,11 @@ ECPrivateKey* ECPrivateKey::CreateFromEncryptedPrivateKeyInfo(
       PKCS8_decrypt(p8_encrypted.get(),
                     password.c_str(),
                     static_cast<int>(password.size())));
+  if (!p8_decrypted.get() && password.empty()) {
+    // Hack for reading keys generated by ec_private_key_nss. Passing NULL
+    // causes OpenSSL to use an empty password instead of "\0\0".

[wtc, 2014/03/22 03:13:45]

Does NSS have a bug?

[mattm, 2014/03/22 04:01:34]

I don't know I'd call it a bug in NSS, other than perhaps of lacking
documentation.
NSS takes a SECItem for the password and uses it directly, so it's up to the app
to use an appropriately formatted password. (In ec_private_key_nss.cc, we pass
in a 0-length pwitem.)

OpenSSL interprets the password input as ASCII and converts it to 2-byte unicode
string with included null termination (Unless you #define PBE_UNICODE when
building OpenSSL, in which case it's like NSS and you can pass in whatever you
want without it being changed.)

PKCS 12 section B.1 says the password should be a 2-byte big-endian unicode
string with included 2 bytes of null termination, but then B.2.3 says that if
the password is the empty string, P should also be empty. I guess taken
literally, "\0\0" is not an empty string, but I dunno if that's what was
intended.

+    p8_decrypted.reset(PKCS8_decrypt(p8_encrypted.get(), NULL, 0));
+  }
   if (!p8_decrypted.get())
     return NULL;