Re: How to export private key in RSA format from NSS
Have you tried exporting with PK11_ExportDERPrivateKeyInfo? That's what WebCrypto uses to export keys in PKCSD#8 format: http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoKey.cpp?#333 On Jul 13, 2014, at 10:48 PM, Chuck Lee chu...@mozilla.com wrote: Hi all, I am now working on supporting PKCS#12 format key on Firefox OS's Wifi module [1]. Because current PSM/NSS API doesn't fit the requirement of UX(assigning nickname of imported certificates) and gonk(wpa_supplicant needs to read private key in RSA format), I have to do some hack to NSS API and implement the function on my own. Now I can import PKCS#12 format correctly, as described in bug comment, but can't export the private key in the format wpa_supplicant requires - I can only get encrypted private key PKCS#8 format(by PK11_ExportEncryptedPrivKeyInfo), but can't in RSA format(by PK11_ExportPrivKey, it said lack of some attributes like private exponent) And I fount that, by using openssl, that I can get expected RSA private key by decrypting the PKCS#8 private key. I tried to decrypte it by PK11_Decrypt() but it doesn't work so far. So I like to ask how to decrypt a PKCS#8 private key by NSS API? Or is there anther way to get private key in RSA format from NSS? Thanks. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1012549 -- 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
Re: SSLKEYLOGFILE always enabled
Is having it in by default useful enough to outweigh the risk? When the Dual_EC_DRBG news stories were blowing it, it was revealed that you could switch to it by just changing the Windows Registry. It's a Windows-supported backdoor - no malicious code needs to stay running on your system - just flip that bit, and delete yourself. After that, you're all set. Similarly, having this feature provided by default seems like it provides a very easy, supported way to extract sensitive key data to the filesystem or some other covert channel - without invalidating package signatures, hashes of libraries or binaries, etc. Don't get me wrong, it's invaluable to be able to use it for debugging, but I question to need to have it enabled by default... -tom On 13 July 2014 19:23, Patrick McManus pmcma...@mozilla.com wrote: I looked into this once, and iirc the change was made intentionally and I guess the documentation not updated. I just updated the wikis. Thanks. On Sun, Jul 13, 2014 at 10:30 AM, Роман Донченко d...@corrigendum.ru wrote: Hello, https://developer.mozilla.org/en-US/docs/Mozilla/ Projects/NSS/Key_Log_Format states that: Obviously this is only a debugging measure and is only enabled if NSS is built with DEBUG and TRACE defined. Analogously, https://developer.mozilla.org/en-US/docs/Mozilla/ Projects/NSS/Reference/NSS_environment_variables says: SSLKEYLOGFILE: [...] Note: The code must be built with TRACE defined to use this functionality. However, the actual responsible code (https://hg.mozilla.org/ projects/nss/file/65605e800fd1/lib/ssl/sslsock.c#l2840) doesn't seem to be protected by any compile-time conditions (except for NSS_HAVE_GETENV). And I've checked with a stock Ubuntu NSS package that SSLKEYLOGFILE works, even though SSLDEBUGFILE doesn't. So who's in the wrong here? Is it a bug in the code, or in the documentation? Roman. -- 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSLKEYLOGFILE always enabled
On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote: Is having it in by default useful enough to outweigh the risk? When the Dual_EC_DRBG news stories were blowing it, it was revealed that you could switch to it by just changing the Windows Registry. It's a Windows-supported backdoor - no malicious code needs to stay running on your system - just flip that bit, and delete yourself. After that, you're all set. Similarly, having this feature provided by default seems like it provides a very easy, supported way to extract sensitive key data to the filesystem or some other covert channel - without invalidating package signatures, hashes of libraries or binaries, etc. Don't get me wrong, it's invaluable to be able to use it for debugging, but I question to need to have it enabled by default... -tom Either you control your machine, or you do not. Either the OS provides robust controls, or it does not. If an attacker has physical access to your machine and can set this, or if an attacker can control your operating environment such that the environment variable is set, it's all over. This is no different than malware hijacking your browser of choice and hooking the API calls - which we do see for both Firefox and Chrome. Now, we can talk about grades of attacks, and finer nuances, but for a debug bit that has to be set client side, it really seems a no-op, and for which common sense would suggest is not a reasonable threat model. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSLKEYLOGFILE always enabled
On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote: Is having it in by default useful enough to outweigh the risk? When the Dual_EC_DRBG news stories were blowing it, it was revealed that you could switch to it by just changing the Windows Registry. It's a Windows-supported backdoor - no malicious code needs to stay running on your system - just flip that bit, and delete yourself. After that, you're all set. Similarly, having this feature provided by default seems like it provides a very easy, supported way to extract sensitive key data to the filesystem or some other covert channel - without invalidating package signatures, hashes of libraries or binaries, etc. Don't get me wrong, it's invaluable to be able to use it for debugging, but I question to need to have it enabled by default... -tom Either you control your machine, or you do not. Either the OS provides robust controls, or it does not. If an attacker has physical access to your machine and can set this, or if an attacker can control your operating environment such that the environment variable is set, it's all over. This is no different than malware hijacking your browser of choice and hooking the API calls - which we do see for both Firefox and Chrome. Now, we can talk about grades of attacks, and finer nuances, but for a debug bit that has to be set client side, it really seems a no-op, and for which common sense would suggest is not a reasonable threat model. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to export private key in RSA format from NSS
Yes, but it doesn't work because it also calls PK11_ExportPrivKeyInfo() to get the RSA private key info. Now I am trying to decrypt key exported by PK11_ExportEncryptedPrivKeyInfo() with method SEC_OID_PKCS12_V2_PBE_WITH_SHA1_AND_40_BIT_RC4 directly, which seems to be the most simple method to decrypt. 於 2014/7/16 上午 01:59, Richard Barnes 提到: Have you tried exporting with PK11_ExportDERPrivateKeyInfo? That's what WebCrypto uses to export keys in PKCSD#8 format: http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoKey.cpp?#333 On Jul 13, 2014, at 10:48 PM, Chuck Lee chu...@mozilla.com wrote: Hi all, I am now working on supporting PKCS#12 format key on Firefox OS's Wifi module [1]. Because current PSM/NSS API doesn't fit the requirement of UX(assigning nickname of imported certificates) and gonk(wpa_supplicant needs to read private key in RSA format), I have to do some hack to NSS API and implement the function on my own. Now I can import PKCS#12 format correctly, as described in bug comment, but can't export the private key in the format wpa_supplicant requires - I can only get encrypted private key PKCS#8 format(by PK11_ExportEncryptedPrivKeyInfo), but can't in RSA format(by PK11_ExportPrivKey, it said lack of some attributes like private exponent) And I fount that, by using openssl, that I can get expected RSA private key by decrypting the PKCS#8 private key. I tried to decrypte it by PK11_Decrypt() but it doesn't work so far. So I like to ask how to decrypt a PKCS#8 private key by NSS API? Or is there anther way to get private key in RSA format from NSS? Thanks. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1012549 -- 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
