Closed Bug 676118 Opened 13 years ago Closed 3 months ago

Patch to add ability to encrypt and decrypt CMS messages using ECDH

Categories

(NSS :: Libraries, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dcooper16, Assigned: dcooper16)

References

(Blocks 1 open bug)

Details

(Whiteboard: [SMIME-ECC])

Attachments

(12 files, 3 obsolete files)

1.25 KB, patch
Details | Diff | Splinter Review
28.98 KB, patch
Details | Diff | Splinter Review
27.89 KB, patch
Details | Diff | Splinter Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
8.51 KB, application/octet-stream
Details
1.77 KB, application/x-pkcs12
Details
7.31 KB, application/octet-stream
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
This patch adds the ability for NSS to encrypt and decrypt CMS (and S/MIME) messages using ECDH.  This patch is dependent on the patches in bug numbers 591640, 676100, and 676108 being accepted.  It also requires the patch in bug #676114 in order to work with smart cards, such as the PIV Card, that only implement the ECDH primitive.

I have performed interoperability testing with Microsoft Outlook 2010 in order to verify that the patch implements ECDH in CMS correctly.

I did not include any #ifdef statements in the patch, such as "#ifdef NSS_ECC_MORE_THAN_SUITE_B", but I understand that such an #ifdef will likely be added to any version of the patch that is incorporated into NSS.
Based on my testing, I believe that the patch in attachment 550231 [details] [diff] [review] correctly implements ECDH in CMS.  However, I did encounter some problems when performing interoperability testing with Microsoft Outlook 2010.  The patch in attachment 550231 [details] [diff] [review] will decrypt messages that are encrypted using Outlook 2010, but messages that are encrypted using the patch in attachment 550231 [details] [diff] [review] cannot be decrypted using Outlook 2010.

The problem is due to a bug in Outlook 2010.  RFC 3635 (Section 2.3.2) and RFC 5753 (Section 7.2 and Appendix A.1) state that the parameters field MUST be absent for AES key wrap.  However, Outlook 2010 includes a parameters field with a value of NULL.  The value of the parameters field for the key wrap algorithm is used in the construction of ECC-CMS-SharedInfo, which is an input to the KDF.  So, having parameters present with a value of NULL rather than absent affects the result of the key derivation function.

This patch makes the messages encrypted by NSS compatible with Outlook 2010 by specifying a parameters field of NULL for AES key wrap rather than leaving the parameters field absent.  The result of this patch is to create encrypted messages that can be decrypted by Outlook 2010, but that are not compliant with the standard.  (This patch does not affect the decryption of messages.  When decrypting the code uses the the parameters field as encoded in the received message to construct ECC-CMS-SharedInfo.)

I have reported this problem to someone at Microsoft and am hoping that Outlook 2010 will be patched so that it can decrypt messages that are encrypted in a standards compliant manner, in which case it would not be necessary to include this patch in NSS.  However, until Outlook is fixed, this patch is necessary to perform interoperability testing with Outlook.
Assignee: nobody → dcooper16
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #550231 - Flags: review?(wtc)
David, are the existing functions with similar names supposed to do what your new functions do? I recommended removing the existing functions in bug 671060 because they were incorrect and/or unused. At fist glance, it seems like you can instead replace the existing functions with your functions, instead of leaving them intact. If so, then I will resolve bug 671060 as a duplicate of this one.
(In reply to comment #2)
> David, are the existing functions with similar names supposed to do what
> your new functions do? I recommended removing the existing functions in bug
> 671060 because they were incorrect and/or unused. At fist glance, it seems
> like you can instead replace the existing functions with your functions,
> instead of leaving them intact. If so, then I will resolve bug 671060 as a
> duplicate of this one.

Brian, Sorry if my naming scheme caused confusion, but my new functions do not do the same thing as the functions mentioned in bug #671060,  so bug #671060 is not a duplicate of this bug.

NSS_CMSUtil_EncryptSymKey_ESDH and NSS_CMSUtil_DecryptSymKey_ESDH are supposed to implement ephemeral-static Diffie-Hellman (i.e., the Diffie-Hellman algorithm using finite field cryptography) whereas NSS_CMSUtil_EncryptSymKey_ESECDH and NSS_CMSUtil_DecryptSymKey_ECDH implement ephemeral-static elliptic curve Diffie-Hellman (i.e., the Diffie-Hellman algorithm using elliptic curve cryptography).  Thus, I took the names from the functions in bug #671060 and added "EC" for "elliptic curve", although I named the decryption function "ECDH" rather than "ESECDH" since the function could be extended to support static-static elliptic-curve Diffie-Hellman (RFC 6278).

My original idea when implementing this patch was to first implement NSS_CMSUtil_EncryptSymKey_ESDH and NSS_CMSUtil_DecryptSymKey_ESDH and then use the resulting code to implement the elliptic curve version.  But I quickly discovered that the CMS implementations of Diffie-Hellman (RFC 2631) and elliptic curve Diffie-Hellman (RFC 5753) are quite different.  Each uses a different KDF and uses different inputs to the KDF.  Since I wasn't really interested in Diffie-Hellman anyway, I decided to just implement elliptic curve Diffie-Hellman and not bother to try to implement Diffie-Hellman.  Although the code in this patch could be used as a starting point if anyone did want to implement CMS encryption and decryption using (finite field) Diffie-Hellman.
Whiteboard: [SMIME-ECC]
I didn't make any changes to the patch.  I just updated it so that it works with the current (i.e., HEAD) code in CVS.
Attachment #550231 - Attachment is obsolete: true
Attachment #550231 - Flags: review?(wtc)
Attachment #604173 - Flags: review?(wtc)
Depends on: 676100
Depends on: 676108
Just a very minor update to make the patch work with the current (i.e., HEAD) code in CVS.  I updated the portion of the patch for secoidt.h and secoidt.c to account for the two new OIDs that were just added to those files: SEC_OID_NIST_DSA_SIGNATURE_WITH_SHA224_DIGEST and SEC_OID_NIST_DSA_SIGNATURE_WITH_SHA256_DIGEST.
Attachment #604173 - Attachment is obsolete: true
Attachment #604173 - Flags: review?(wtc)
Attachment #642001 - Flags: review?(wtc)
Product: Core → MailNews Core
Version: Trunk → unspecified

This is just an update so that the patch works with the current NSS code.

Attachment #642001 - Attachment is obsolete: true
Attachment #642001 - Flags: review?(wtc)
Attachment #9090793 - Flags: review?(kaie)
Attachment #9090793 - Flags: review?(jjones)
Attachment #9090793 - Flags: review?(apavel)
Component: Security: S/MIME → Libraries
Product: MailNews Core → NSS
QA Contact: jjones
Version: unspecified → other
Comment on attachment 9090793 [details] [diff] [review]
Updated patch to add ability to encrypt and decrypt CMS messages using ECDH

Assuming you need a sheriff opinion, redirecting this to Aryx.
Attachment #9090793 - Flags: review?(apavel) → review?(aryx.bugmail)

Which email clients already support ECDH with S/MIME?

(In reply to Kai Engert (:kaie:) from comment #9)

Which email clients already support ECDH with S/MIME?

As noted above, Microsoft Outlook 2010 supported ECDH in 2011, when I first developed a set of patches needed for NSS to support ECDH. However, I haven't done anything with Outlook since then.

OpenSSL's cms command can also encrypt and decrypt S/MIME messages using ECDH. I just tried it with OpenSSL 1.0.2s, 1.1.0k, and 1.1.1c, and all three support it.

I have not tried any other email clients, so I don't know whether any others support it.

Just to set expectations, I've never seriously worked with this part of NSS, and I'm on my way to W3C TPAC for the next week. I probably won't be able to get to these reviews until the week of the 22nd. That said, Kai's review is sufficient to merge, certainly. If you need a second opinion while I'm unavailable, please ask kjacobs.

Attached patch ECDH CMS testsSplinter Review

This patch adds some tests to nss/tests/smime for CMS messages encrypted using ECDH. It includes one test in which NSS is used to encrypt and then decrypt a message using ECDH. It also changes the multiple recipient test so that one of the recipients has an ECDH key.

This patch also adds several tests in which NSS is used to decrypt messages that were encrypted using OpenSSL. These tests may be particularly useful for bug #676100, as they help to demonstrate that the ASN.1 templates need to be corrected in order to be able to parse correctly encoded messages that were enveloped using ECDH.

The decryption tests are a work in progress. The PKCS #12 file and the sample encrypted messages should really just be separate files. However, since I didn't know how to include binary files in a patch file, I just included code in the smime.sh script to generate these binary files.

My original plan was to just have smime.sh call openssl to generate test files, and then use cmsutil to decrypt them. I also wanted to have cmsutil encrypt some messages and then use openssl to decrypt them. However, it seems that that would not be very portable. While OpenSSL has supported "openssl cms" with ECDH since version 1.0.2, the "cms" command is not supported the version of openssl (LibreSSL 2.6.5) that comes with the Mac.

Attachment #9093918 - Flags: review?(kaie)
Attachment #9093918 - Flags: review?(jjones)

FYI: I just discovered that RFC 8551, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification, was published in April 2019, obsoleting RFC 5751.

Section 2.3 of RFC 8551 says:

Receiving and sending agents:

  • MUST support Elliptic Curve Diffie-Hellman (ECDH) ephemeral-static
    mode for P-256, as specified in [RFC5753].

  • MUST support ECDH ephemeral-static mode for X25519 using HKDF-256
    ("HKDF" stands for "HMAC-based Key Derivation Function") for the
    KDF, as specified in [RFC8418].

Hello David.

I was very busy with OpenPGP in the previous year, and didn't want to risk regressions in S/MIME, because I knew I wouldn't have time to follow up.
Now, I think this has been waiting long enough, and we should try to get this landed.
We're in the middle of the yearly Thunderbird development period, so we should have sufficient time to gather feedback on these enhancements.

Looking at your patch, my only issue is that I cannot tell if the cryptographic code you're adding to cmspubkey.c is correct.

J.C. is there someone in the NSS team who could understand if David's code is correct, and would have time to review?

Flags: needinfo?(jjones)

Benjamin, what do you think about comment 14?

Flags: needinfo?(jc) → needinfo?(bbeurdouche)

Hi Kai, I think it is fine to take it.
I can't really spend time on this, could you take the lead by providing the patch and review it?
I can have a second look when you think it is ready.

Flags: needinfo?(bbeurdouche) → needinfo?(kaie)

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: dcooper16 → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
Flags: needinfo?(kaie)

Depends on D164329

See Also: → 215997

Anna, is my understanding correct, you have uploaded David's patches to phabricator, but the patches are identical?
(No changes were made on top of David's patches).

Flags: needinfo?(nkulatova)

Bob, may I ask you to help with the review of the cryptographic code that is added to cmspubkey.c ?

Flags: needinfo?(rrelyea)

I added my review comments. In general the patch looks well structured and a good use of NSS primitives.

Flags: needinfo?(rrelyea)
Priority: -- → P2
Attachment #9307546 - Attachment description: WIP: Bug 676118: Microsoft Outlook 2010 compatibility patch → Bug 676118: Microsoft Outlook 2010 compatibility patch

Hi David,

Do you mind taking a look at the patches? Bob added some comments I think you're the most qualified to answer to!
Thanks!

Flags: needinfo?(nkulatova) → needinfo?(dcooper16)
Attachment #9307550 - Attachment description: WIP: Bug 676118: ECDH CMS tests → Bug 676118: ECDH CMS tests
Attachment #9307543 - Attachment description: WIP: Bug 676118: Updated patch to add ability to encrypt and decrypt CMS messages using ECDH → Bug 676118: Updated patch to add ability to encrypt and decrypt CMS messages using ECDH

Are these patches still be working with recent versions of Thunderbird?

ASN templates + S/MIME ECC support + Outlook compatibility patch let's me encrypt mails, but I can only decrypt them with my self compiled Thunderbird.
Neither Outlook 365 nor OpenSSL 3.1.4 work for me with certificates using secp384r1 curve.

OpenSSL command line:
openssl cms -decrypt -in '.\Test.eml' -recip 'test384.cert' -inkey 'test384.key' -nointern
OpenSSL error:
Error decrypting CMS using private key
A8150000:error:1C800066:Provider routines:aes_wrap_cipher_internal:cipher operation failed:providers\implementations\ciphers\cipher_aes_wrp.c:192:
A8150000:error:030000BD:digital envelope routines:EVP_DecryptUpdate:update error:crypto\evp\evp_enc.c:842:

As the problem seems to be related with the key wrap function, which was manipulated for Outlook 2010 compatibility, I tried without this patch. But in this case, my self compiled version simply crashes on encryption of the mail.

I'd like to drive this bug to completion. Assigning to myself.

Patch crashes, confirming comment 25.
Tried on both comm-esr115 and comm-beta.

I'm investigating.
Something related to "ukm" pointing to null.

False alert. After applying the patches from bug 676100 the crash is gone.

Hi,

just to be clear:

Just using

Attachment #9307543 - Attachment description: Bug 676118: Updated patch to add ability to encrypt and decrypt CMS messages using ECDH → WIP: Bug 676118: Add ability to encrypt and decrypt CMS messages using ECDH
Attachment #9307546 - Attachment description: Bug 676118: Microsoft Outlook 2010 compatibility patch → WIP: Bug 676118: Microsoft Outlook 2010 compatibility patch
Attachment #9307550 - Attachment description: Bug 676118: ECDH CMS tests → WIP: Bug 676118: ECDH S/MIME tests

As a response to comment 25: In my local testing with a NSS generated certificate, storing the key/cert in a p12 file, then using openssl pkcs12 to extract the private key and storing the key into a PEM file, I can successfully decrypt an ECDH message that was created by Thunderbird.

This is an ECC test key, which was generated with OpenSSL, using sha384ECDSA (PIN is 000)
and a mail encrypted with my self compiled version of Thunderbird and this test key.
Decryption fails as described with OpenSSL, it's fine in my Thunderbird.

Would you be so kind, to test this against your version?

(In reply to BigMike from comment #31)
The PIN is 0000
Sorry for the typo in the text.

(In reply to BigMike from comment #31)

Created attachment 9392820 [details]
Test certificate and mail; certificate PIN is 0000

This is an ECC test key, which was generated with OpenSSL, using sha384ECDSA (PIN is 000)
and a mail encrypted with my self compiled version of Thunderbird and this test key.
Decryption fails as described with OpenSSL, it's fine in my Thunderbird.

Would you be so kind, to test this against your version?

It's been many years since I've looked at this patch, but when I look at the encrypted email you provided I see:

SEQUENCE {
OBJECT IDENTIFIER ecdhX963KDF-SHA384 (1 3 132 1 11 2)
SEQUENCE {
OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
NULL
}
}

Based on comment #1, it seems this email was created with the Microsoft Outlook 2010 compatibility patch applied. Have you tried it without applying this patch? Given that applying that patch results in something that is not compliant with the standard, it's quite possible that it doesn't work with OpenSSL. For all I know, it may not work with recent versions of Microsoft Outlook either. I can only say that 13 years ago the patch was needed to interoperate with Microsoft Outlook 2010.

Flags: needinfo?(dcooper16)

Comment on attachment 9090793 [details] [diff] [review]
Updated patch to add ability to encrypt and decrypt CMS messages using ECDH

Clearing review requests, we're handling it in phabricator.

Attachment #9090793 - Flags: review?(kaie)
Attachment #9090793 - Flags: review?(jc)
Attachment #9093918 - Flags: review?(kaie)
Attachment #9093918 - Flags: review?(jc)

(In reply to David Cooper from comment #33)

SEQUENCE {
OBJECT IDENTIFIER ecdhX963KDF-SHA384 (1 3 132 1 11 2)
SEQUENCE {
OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
NULL
}
}

Thanks David for having a look.

This sequence is present in my message that OpenSSL can decrypt, too, so it might not be the cause of the issue with OpenSSL.

BigMike, thanks for providing that test data.

I can reproduce, my OpenSSL 3.1.1 on Fedora cannot decrypt your message.

(edit: corrected my openssl version)

(In reply to BigMike from comment #25)

Error decrypting CMS using private key
A8150000:error:1C800066:Provider routines:aes_wrap_cipher_internal:cipher operation failed:providers\implementations\ciphers\cipher_aes_wrp.c:192:
A8150000:error:030000BD:digital envelope routines:EVP_DecryptUpdate:update error:crypto\evp\evp_enc.c:842:

I get the same error message (with different line numbers).

I searched the web, and found this ticket:
https://github.com/openssl/openssl/discussions/22861

which gives this explanation from t8m:

"The wrap ciphers have only limited support in openssl enc. One limitation is that you cannot encrypt anything bigger than 4096 bytes.
May I ask why do you want to use a wrap cipher mode with enc? It is not supposed to be used to encrypt any data, its purpose is to encrypt raw keys - i.e., mostly random data."

Comment 37 suggests that the size of the encrypted message could make a difference.

I saw my original payload was very small, just 30 bytes, while BigMike's message was about 3 KB.

I've now tried a 66 KB message myself, but my OpenSSL version 3.1.1 is still able to decrypt my message.

I think the difference is the certificate that we're encrypting for.

If I encrypt a message to the certificate that BigMike sent to me, I can reproduce the decrypt failure.

However, both our certificates use secp384r1

They differ in the signature algorithm, mine uses ecdsa-with-SHA256, Mike's uses ecdsa-with-SHA384, could that be the cause?

I can try to generate another certificate myself using the same signature algorithm. I had generated my own cert using NSS tools.

Names and extensions should be irrelevant for the decryption failure, I think?

No, that also doesn't make a difference.
Encrypting to my ecdsa-with-sha384 signed certificate works fine.

Can it be a matter of the key material that Mike's cert contains?

Mike, do you want to try yourself using this certificate?
Password: x

Please ignore comments 39 and 40 - they were incorrect.

My OpenSSL can decrypt a file that I send to Mike's certificate.

I cannot reproduce Mike's failure based on my own build.

The only decrypt error happens with the message that Mike attached.

Mike, I don't know what happened on your system.
Maybe the earlier version of the patches were unstable, and after my recent updates to the patches, they work better now.
Or, maybe you made a mistake when applying the patches.

As an additional test, I also removed the outlook-compat patch.
OpenSSL can still decrypt that.

I suggest that I create a test Thunderbird executable with the latest patches.
Maybe you could use that to test on your system.

Could you write down a chain of action that I can also test? P.s. just probably not this week

Outlook from Office 365 is able to decrypt a message that was used with the latest patches.
It reports ECDSA was used.

(I couldn't yet test the other direction, I'll need to work on test certificates that Outlook is willing to use.)

I had a frustrating day, because I failed to send encrypted emails using Outlook from Office 365 using S/MIME ECC certificates.

After failing with simpler certificates that I had generated myself, I concluded that I probably must use email certificates that comply with all the latest baseline requirements, with all the right certificate extensions on both CA and EE certs, so I decided to try buying from an official CA.

But even after I've bought two email test certificates from Sectigo today, I still see the same failure with Outlook.

"Microsoft Outlook had problems encrypting this message because the following recipients had missing or invalid certificates, or conflicting or unsupported encryption capabilities"

This is despite the user certificate manager claiming that the certificate "is ok". I have deleted all my earlier self-generated certificates and rebooted, so nothing old should remain.

The certificates have been created by submitting a CSR to the Sectigo web interface. I had created the CSRs using the code from bug 1581796.

Does anyone of you have experience with this kind of failure, or additional ideas how to debug?

(In reply to Kai Engert (:KaiE:) from comment #45)

"Microsoft Outlook had problems encrypting this message because the following recipients had missing or invalid certificates, or conflicting or unsupported encryption capabilities"

After playing with various curves and attributes, I gave up on this, too.

  • Click simply next in that dialog and outlook sends an encrypted mail, which is perfectly decryptable with OpenSSL (and it's also stored encrypted in sent folder); but I'm not sure if I used my sender or my receiver certificate in OpenSSL
  • Or if you'd like to circumvent the error message, don't send the message at all; just save it as a draft, the draft will be encrypted

(In reply to Kai Engert (:KaiE:) from comment #42)

I cannot reproduce Mike's failure based on my own build.

The only decrypt error happens with the message that Mike attached.
Thank you for all your efforts

Mike, I don't know what happened on your system.
Maybe the earlier version of the patches were unstable, and after my recent updates to the patches, they work better now.
Or, maybe you made a mistake when applying the patches.
Since your Thunderbird is able to encrypt messages with my test certificate, this is highly probable.
I'll have a look at the latest changes. Did you also change something at the ASN template patch or only at the ECC support patch?

I suggest that I create a test Thunderbird executable with the latest patches.
Maybe you could use that to test on your system.
I'll try with your test certificate and have a look at your and my code first :)

(In reply to BigMike from comment #46)

  • Click simply next in that dialog and outlook sends an encrypted mail, which is perfectly decryptable with OpenSSL (and it's also stored encrypted in sent folder); but I'm not sure if I used my sender or my receiver certificate in OpenSSL

Thanks for this hint.

When I was using my self-generated certificates, it was NOT possible to continue anyway. The "continue" button was disabled.

However, when using certs from Sectigo, the continue button is available!

Thunderbird with these patches can decrypt the messages that Outlook sent!

Given we have this interoperability success, it seems we are ready to take this code.
I'll ask Bob for a final review of my latest changes on top.

Attachment #9307543 - Attachment description: WIP: Bug 676118: Add ability to encrypt and decrypt CMS messages using ECDH → WIP: Bug 676118: Add ability to encrypt and decrypt CMS messages using ECDH.

Hi Kai,

I'm using Windows. I've tried your (Windows) test build with a completely fresh profile and my certificates.

Is this test build with or without the Outlook compatibility patch? I saw, you made a lot of changes to the patch, I haven't in my build...

Thunderbird crashes on mail encryption. The crash reports are attached.

After that, I tried your certificate, but Thunderbird keeps me telling, it doesn't find a matching certificate. Maybe, because I don't have the CA certificate to mark it trusted? But on the other hand, you were able to use my certificate without the matching CA cert!?

(In reply to BigMike from comment #51)

Is this test build with or without the Outlook compatibility patch?

With

I saw, you made a lot of changes to the patch, I haven't in my build...

I've used the tip of the NSS development branch, because I have rebased the ECDH patch on top of that.

Thunderbird crashes on mail encryption. The crash reports are attached.

Thanks. I'll have a look. And I could try running on Windows myself. So far I've only used Linux.

After that, I tried your certificate, but Thunderbird keeps me telling, it doesn't find a matching certificate. Maybe, because I don't have the CA certificate to mark it trusted?

Yes, you need to mark the CA as trusted in your test profile. If you have imported the p12 file, you should find the CA in TB's certificate manager. It's named "Insecure Test CA" I think. Select it, click the "edit trust" button, and mark it as trusted for email security. That should be sufficient.

But on the other hand, you were able to use my certificate without the matching CA cert!?

All I did with your certificate was trying to decrypt with OpenSSL.

Does anyone of you have experience with this kind of failure, or additional ideas how to debug?

see: bug#1836849

make_NIST-EC_emails/envelopedData

Last year I also tested ECDH between programs, Outlook could not handle any message (generated in Openssl and gpgsm).

Thunderbird crashes on mail encryption. The crash reports are attached.

I confirm and will debug.

We crash while ENCODING something using the ECC_CMS_SharedInfoTemplate template
(which can apparently happen even when READING an existing message...).

We crash while writing the header of that template, while trying to obtain the length of the SECOID_AlgorithmIDTemplate type attribute.

I looked at other existing code, which encodes this type in asn.1 and also uses a pointer.

I found that other code uses "SEC_ASN1_XTRN | SEC_ASN1_POINTER",
while this code here uses "SEC_ASN1_INLINE | SEC_ASN1_POINTER".

I changed the code to "SEC_ASN1_XTRN | SEC_ASN1_POINTER",
and it no longer crashes for me.

I'll create a new test build.

Attachment #9307543 - Attachment description: WIP: Bug 676118: Add ability to encrypt and decrypt CMS messages using ECDH. → Bug 676118: Add ability to encrypt and decrypt CMS messages using ECDH. r=rrelyea

(In reply to Kai Engert (:KaiE:) from comment #56)

  • I can confirm: No crashes anymore
  • Mail from your testing build to Outlook 365 (2402), Signed+Encrypted works fine
  • From Outlook 365 (2402) to your testing build, encryption is fine, but Outlook uses SHA1ECDSA/SHA1 as signature algorithm, which Thunderbird doesn't accept as valid (for good reasons) - and actually Outlook warns about sending the message, because of the used certificates, so maybe, this is a fallback?
  • Sending unencrypted, Outlook uses the configured SHA384ECDSA/SHA384
    So, now the problems are on Microsoft's side :)

Thank you!

Oh, forgot to say: OpenSSL successfully decrypts the message, too

r=kaie on the outlook compat patch. I'll land it.

r=kaie on the tests from both bug 676100 and from this bug. Only minor modification by me to create permanent binary test files.

Also r=rrelyea, as he expressed at https://phabricator.services.mozilla.com/D164332?id=806724#7077808

After I've addressed Bob's review requests, David's patch has r=rrelyea

I will land that patch in two pars.
First part will be David's original code, plus trivial rebase changes.
Second part will be the work I did on top to address Bob's most recent review requests.

Assignee: nobody → dcooper16

Reopening, because a small follow-up fix is necessary, to a recently added function (see bug 1877730).

Flags: needinfo?(rrelyea)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

We'll also require fixes for build and test failures.

(1) Windows doesn't like a const int for defining the size of a local variable,
I'll change that to an enum value, which worked in try.

(2) We have an unresolved external symbol on Windows,
SECOID_AlgorithmIDTemplate_Util,
I'll check what fix is necessary.

(3) We have ABI warnings, see end of this logfile:
https://firefoxci.taskcluster-artifacts.net/xnaCRkQNRcqrULUSza9fpw/0/public/logs/live_backing.log

  The enum value additions can be ignored.

  The size changes related to parent type NSSCMSContentInfo were caused
  by the template (and related types) canges:
      https://hg.mozilla.org/projects/nss/rev/c4a0fa94c133aaa97f267e74c83f4d5b7298f4ee
  I think those changes aren't a problem, because that type 
  isn't produced or directly inspected/manipulated by the application,
  rather it's a kind of opaque handle  be treated as a type of handle, 

  The top comment in file cmst.h claims that all of the types in that file should be
  treated as opaque.

(In reply to Kai Engert (:KaiE:) from comment #65)

(2) We have an unresolved external symbol on Windows,
SECOID_AlgorithmIDTemplate_Util,
I'll check what fix is necessary.

By comparing similar code, it seems the call to SEC_ASN1EncodeItem must use SEC_ASN1_GET(SECOID_AlgorithmIDTemplate).

I've commited the fix for build failures (1) and (2) :
https://hg.mozilla.org/projects/nss/rev/dea9f1eebe78ee9881d202525a376045f320f0e3

I'll submit a patch to fix the ABI warnings in a minute.

Attachment #9395147 - Attachment description: Bug 676118 - Follow-up to fix memory leak. r=rrelyea → Bug 676118 - Follow-up to fix memory leak. r=jschanck
Attachment #9395010 - Attachment description: Bug 676118 - Follow-up fix to update NSS_CMSRecipient_IsSupported. r=rrelyea → Bug 676118 - Follow-up fix to update NSS_CMSRecipient_IsSupported. r=bbeurdouche
Status: REOPENED → RESOLVED
Closed: 3 months ago3 months ago
Resolution: --- → FIXED
Flags: needinfo?(rrelyea)
Blocks: 1892223
Blocks: smime-2023
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: