Re: FIPS mode key import?
I don't know how it maps to NSS, but at the PKCS#11 layer you can generate a key pair, export the public key (even in FIPS mode, because it's public), use the public key to encrypt your secret key, then unwrap that with the private key. Then you can use that secret key to unwrap private keys. (At least one HSM has a PKCS#11 library that effectively does that for you, so it just allows plaintext import and export of non-CKA_SENSITIVE keys even if strict FIPS mode restricts the HSM boundary.) From: dev-tech-crypto on behalf of Chris Newman Sent: 01 June 2020 17:38 To: mozilla's crypto code discussion list Subject: FIPS mode key import? CAUTION: This email originated from outside of PulseSecure. Do not click links or open attachments unless you recognize the sender and know the content is safe. I have NSS-based DKIM signing working in our mail server software, but run into a problem when trying to do it in FIPS mode. I've been importing the DKIM private key using either PK11_ImportPrivateKeyInfoAndReturnKey or PK11_ImportDERPrivateKeyInfoAndReturnKey, but these APIs don't work in FIPS mode (they map to C_CreateObject which disallows raw key import). If FIPS mode only supports import of an encrypted private key, how would I import the symmetric key that was used to encrypt the private key? Seems like a catch22 for a distributed system where keys have to move around. I like to avoid the OpenSSL-crypto-monoculture, but right now it looks like using OpenSSL-FIPS is the fastest path forward. Any suggestions for a way I could keep using NSS for this? - Chris -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://app-us.bitdam.com/api/v1.0/links/rewrite_click/?rewrite_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXdyaXRlX2lkIjoiNWVkNTM0YTllMTMzMjI1OWMyYTIzNjU5IiwidXJsIjoiIn0.nC--nvz2SsPWjp5OWXGSmXxxci-E05q5XCMI5z03l0g=https%3A//nam04.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Flists.mozilla.org%252Flistinfo%252Fdev-tech-crypto%26amp%3Bdata%3D02%257C01%257C%257C16d46204adef48e5b7cd08d8064a564e%257C3290a9179dd643db843ba3e376f9f96c%257C0%257C1%257C637266263636461480%26amp%3Bsdata%3DhbeaCwPoa9HPjleDPJSw6CjjmEJz%252FFv5p4shli%252BoYRg%253D%26amp%3Breserved%3D0 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On 04/05/15 21:53, David Woodhouse wrote: On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: Surely that's not unique? Using the above example, surely the first certificate issued by the 2010 instance of 'My CA', and the first certificate issued by the 2015 instance, are both going to have identical CKA_ISSUER and CKA_SERIAL_NUMBER, aren't they? No, every subject and serial must be unique. If the 2010 and 2015 instance are distinct bytes, they need distinct serial numbers. I was speaking of the serial numbers of certificates issued *by* those two separate CAs. Or are you suggesting that those sets of serial numbers muat be disjoint? You mean the 2015 instance is a re-signing of the same certificate? Isn't the signature included in the distinct bytes, meaning it's still a new certificate which needs a new serial number, even if it's based on the same request and the request is signed by the same key. (If it's a re-issue with the same CA signature, same validity dates, and same everything else, then including CKA_VALUE won't make it distinct either, and there's no point in having two copies with different labels. It's the same object, imported twice.) However, I would expect both CKA_SUBJECT and CKA_ID to be the same for a re-signed certificate. (But that the CKA_SUBJECT and CKA_ID pair will uniquely identify the private key that both certificates apply to. Years of working with HSMs have left me with the attitude that the private key is the important bit, and any certificate is someone else's problem, so issuer and serial number are irrelevant :-) But I do realize that's not the typical application view.) -- http://www.brocade.com/products/all/application-delivery-controllers/index.page -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On 05/05/15 16:55, David Woodhouse wrote: On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: Hm... so if I have two certificates; one with: CKA_SUBJECT: My CA CKA_LABEL: My CA (2010 instance) and the other: CKA_SUBJECT: My CA CKA_LABEL: My CA (2015 instance) Surely that's not unique? Using the above example, surely the first certificate issued by the 2010 instance of 'My CA', and the first certificate issued by the 2015 instance, are both going to have identical CKA_ISSUER and CKA_SERIAL_NUMBER, aren't they? [My confusion over CA and ancestor CA serials elided.] I'm talking about the serial numbers of the certs issued *by* the two My CAs. Let's assume each CA starts at '1' — that in each case the CKA_SERIAL_NUMBER of the first cert issued *by* 'My CA' is 1. Now, since each of those CAs issues a cert with CKA_SERIAL_NUMBER=1, and in both cases the CKA_ISSUER of that issued cert is 'My CA', that means the combination of CKA_ISSUER and CKA_SERIAL_NUMBER does *not* uniquely identify a certificate, surely? (Unless the two CAs in question are expected to use *disjoint* number spaces for the CKA_SERIAL_NUMBER of certificates that they themselves issue?) My reaction is that if there are two different CAs, there ought to be two different issuers, and if there is one CA using two different certificates, it ought to use disjoint spaces for the serial numbers. (And if there were two issuers, presumably the subjects in the initial example would have been different.) But I would be totally unsurprised to find that reality doesn't work like that... My employer has a habit of creating new CAs with the same subject as old ones. So I've dealt with a number of bugs where validation fails because some piece of code assumes that it can find the issuer of a given certificate by looking for the first CA in the database whose CKA_SUBJECT matches the CKA_ISSUER of the certificate in question. Oh look, reality doesn't always work like I think it should. Guess how unsurprised I am :-) -- http://www.brocade.com/products/all/application-delivery-controllers/index.page -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On 30/04/15 17:56, David Woodhouse wrote: Has anyone looked at implementing RFC7512 support, allowing an object to be specified by a PKCS#11 URI? I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT, when PKCS#11 says The*CKA_ID*attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject and it is possible that keys for different subjects may have the same*CKA_ID*value without introducing any ambiguity? -- http://www.brocade.com/products/all/application-delivery-controllers/index.page -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS fails to compile on MIPS64 n32 platforms
On 20/05/14 02:18, Wan-Teh Chang wrote: On Fri, May 16, 2014 at 2:19 AM, Vicente Olivert Riera vincent.ri...@imgtec.com wrote: Sorry, I'm not english native. What's the meaning of I'd like *wtc* to way in? wtc is my user id (from the initials of my name) :-) And way in is a typo for weigh in. http://www.merriam-webster.com/dictionary/weigh%20in (meaning 2) http://idioms.thefreedictionary.com/weigh+in -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Chrome: From NSS to OpenSSL
On 12/04/14 21:33, Florian Weimer wrote: * Julien Pierre: Strange that PKCS#11 support is listed as a con for NSS . I found the PKCS#11 approach rather difficult to deal with if you're adding cryptography to some library whose client code has no idea that there is cryptography involved (and that NSPR and NSS need initialization). The global state is horrible in this scenario, and with an increased push towards use of cryptography, it comes up more and more often. Moving to OpenSSL won't remove that issue though: http://wiki.openssl.org/index.php/Library_Initialization (OpenSSL, unlike PKCS#11, doesn't require initialization on fork, though there are related problems: http://wiki.openssl.org/index.php/Random_fork-safety) And of course if you use OpenSSL's PKCS#11 engine, then you have the problem that you reimpose PKCS#11 requirements on a layer than didn't know it was using PKCS#11. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Chrome: From NSS to OpenSSL
On 08/04/14 13:11, Jean-Marc Desperrier wrote: Ryan Sleevi a écrit : reliance on PKCS#11 means that there are non-trivial overheads when doing something as simple as hashing with SHA-1. For something that is such a simple transformation, multiple locks must be acquired and the entire NSS internals may*block* if using NSS on multiple threads, in order to prevent any issues with PKCS#11's threading design. I don't believe that PKCS#11's threading design mandates that. Implementation easily can have that problem, and NSS sure does, but I think it would be possible to design a PKCS#11 implementation than let's you do hashing without requiring locks. Or maybe, it's more because of PKCS#11 session management rules that you hardly can avoid them. If you do all your hashing in one session, then the rules require you to use locks. The obvious answer is don't do that then, but PKCS#11 libraries for dumb devices are allowed to only support a limited number of sessions and force you to juggle C_GetOperationState/ SetOperationState. But if https://developer.mozilla.org/en/docs/PKCS11_FAQ is accurate, it will only fall back on the single session solution if the device requires it. And for hashing without secret keys (plain digest, not HMAC, no C_DigestKey calls), there's never any reason to use a limited device for that operation. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Chrome: From NSS to OpenSSL
On 31/01/14 18:28, Ryan Sleevi wrote: On Fri, January 31, 2014 9:18 am, Alan Braggins wrote: On 31/01/14 10:24, Julien Pierre wrote: On 1/27/2014 10:28, Kathleen Wilson wrote: Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from NSS to OpenSSL: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 Strange that PKCS#11 support is listed as a con for NSS . It is at least listed under pro as well (Having ENGINE_pkcs11 listed under both for OpenSSL might make sense too.) It was not accidental that it was listed under Con, nor do I see ENGINE_pkcs11 as a Pro As part of its fundamental design, NSS performs all operations using PKCS#11 tokens. Even the internal cryptographic implementation is exposed as a PKCS#11 token - softoken. That conflates two different things though. Having support for PKCS#11 tokens at all is a pro, even if one irrelevant to the vast majority of users. Having a design that shoe-horns all cryptographic operations through a PKCS#11 token layer has the disadvantages you describe, but isn't really the same thing as PKCS#11 support. It's good for interop with smart cards. Which is what it was designed for. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Chrome: From NSS to OpenSSL
On 31/01/14 10:24, Julien Pierre wrote: On 1/27/2014 10:28, Kathleen Wilson wrote: Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from NSS to OpenSSL: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 Strange that PKCS#11 support is listed as a con for NSS . It is at least listed under pro as well (Having ENGINE_pkcs11 listed under both for OpenSSL might make sense too.) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 27/01/14 17:26, ripber...@aol.com wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. The standard at this point does NOT allow you to use Camellia. So there should be some way to configure the browser so that it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to use Firefox' PKCS#11 interface
On 06/12/13 13:07, firef...@gmail.com wrote: Hi, I have a couple of questions concerning certificate handling in Firefox and PKCS#11. When Firefox receives a X.509 cert during HTTPS establishment, the certificate (chain) is validated by NSS, right?! Is this done via PKCS#11 or are Firefox and NSS communicating via an other interface? I can't find an appropriate PKCS#11 function, accepting a certificate chain. PKCS#11 doesn't work at that level. PKCS#11 tokens can store certificates, but the PKCS#11 API doesn't interpret them in any way. Operations like extracting a public key from a certificate, or validation, are done outside PKCS#11 apart from signature verification. (You could, perhaps, build a PKCS#11 module that recognized when the data passed to a C_Verify call happened to be a certificate and do something other than just verify the signature, but that would be truly horrible.) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 22/08/13 11:50, Alan Braggins wrote: On 21/08/13 18:23, Zack Weinberg wrote: I share concern about new side channel attacks due to GMAC, though. You aren't alone. https://bugzilla.mozilla.org/show_bug.cgi?id=868948 I asked a friend who works for ARM about the chances of constant time AES-GCM instruction set support. SecurCore; sure. A-series; no chance. I'm not convinced that the advantages of eliminating handshake fingerprinting outweigh the benefits of allowing endpoints with different capabilities to negotiate different ciphers (e.g. preferring AES more strongly if AES-NI instructions are available at both ends). Possibly you should be aiming for a shared set of principles to be used by browsers when choosing a suite, not a shared ordering. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 21/08/13 18:23, Zack Weinberg wrote: On 2013-08-19 2:06 PM, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM is (AIUI) preferred because it's immune to BEAST. The TLS1.1 explicit IV is sufficient for immunity to that specific attack even when using CBC mode. http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack I share concern about new side channel attacks due to GMAC, though. You aren't alone. https://bugzilla.mozilla.org/show_bug.cgi?id=868948 salsa20 + poly1305 anyone? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 19/08/13 19:06, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM (while recognizing that it isn't widely supported yet). (At least unless http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-00 gets anywhere - the current choice isn't so much GCM or CBC as GCM or MAC-then-encrypt-CBC. Personally I don't see very much point in Peter's proposal - supporting the new extension won't be that much less work than GCM, and GCM suites are already standardized.) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
