Add S/MIME decryption

[BastianZim]

Feature request

It would be nice if cryptography could be used to decrypt S/MIME encrypted emails.

This could be low-level right now, similar to https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization/?highlight=s%2Fmime#cryptography.hazmat.primitives.serialization.pkcs7.PKCS7SignatureBuilder or something more high level later.

The respective OpenSSL command would be openssl smime -decrypt -in smime-ok.eml -recip myself.pem

But since there is currently no stable python tool to decrypt S/MIME (That I know of), anything is already very much appreciated. :)

[BastianZim]

I formulated this quite vague as I'm not sure how much info is needed but please let me know if I should add more.
Also, I saw some attempts at creating an issue to track all S/MIME-related features from a more high-level approach (#1621 (comment)) to bring it out of the hazards area but from what I can see, that hasn't happened yet. Happy to create something, if required.

[pirm-in]

I am pretty new to this topic, but came to work on a project recently where we need to handle email messages with S/MIME signed and encrypted attachments in python. we started to implement a POC with M2crypto, just to realize that the other party, which is sending us the messages, uses openssl cms for encryption, and we could not verify/decrypt the messages.
so i did some research and came across this: https://security.stackexchange.com/questions/41399/openssl-pkcs7-vs-s-mime
where the author of the accepted answer basically tells, that cms is used for the newer versions of S/MIME (current version is v4)
in a nutshell: i think what we actually would want/need is an API which supports the high-level features of the openssl CLI cms command, not the older version openssl smime

for a short term solution in our project at hand we will probably fall back on just calling the openssl command via python-subprocess, but it's not something we want to stay with obviously.

what i am wondering right now is

• what is the progress since the More SMIME please! issue has been closed
• what is the actual state of S/MIME encryption
• what exactly needs to be done to satisfy this comment
• is it possible to do all this with the current state of pyca/cryptography (with an acceptable effort from a business perspective)
• what on earth have i been gotten into 😅

[reaperhulk]

CMS is an enormous (and terrible) specification so you'll need to very precisely define what it is you need. This really means spelunking through RFCs and determining the minimal set of supported structures.

No one has stepped up to try to even define the scope of this work, much less determine how we would actually accomplish it. As for SMIME, no API has been proposed for encryption/decryption and no API has been proposed for verification so those remain items for future work. They're definitely more tractable than expanding to full CMS support, but carry a variety of challenges of their own.

None of this is impossible, but making progress will require consistent commitment since we need to agree on a design, discuss implementation, and then it needs to get written and go through what will likely be several cycles of significant feedback.

[mij]

I agree with @reaperhulk . And an incremental approach would be:

1. Implement S/MIME signature generation
2. Implement S/MIME signature verification
3. Implement S/MIME encryption
4. Implement S/MIME decryption

I would speculate a few million emails are sent daily with S/MIME signature for each one sent with S/MIME encryption.
And I would also speculate that S/MIME signature generation limits the effort to <20% of the spec. All of the variability in crypto algorithms, is made irrelevant.

That's also what e-mail clients focus on.

[alex]

As a status update, we now do signing and encryption, we don't have verification or decryption yet.

[bluetech]

A use case for PKCS7 / CMS verify is Apple Pay Payment Token.

The hack backend._lib.PKCS7_verify in cryptography<43 and test_support.pkcs7_verify in cryptography==43 are sufficient for this use case, though obviously these functions are private and not for real use.

[reaperhulk]

@bluetech thanks for the use case! We're interested in supporting PKCS7 verification, although we're likely to do so by first enhancing our path building work.

[nitneuqr]

Hey, new here; I've been working with a client that uses encrypted email on Outlook. Was using asn1crypto & cryptography since march 2024 for private email decryption & encryption.

Since july 2024, I've been using the new code for encryption, works like a charm with Outlook. Thanks again!

I'd love to help on decryption. Is there already someone working on it? I understand that test_support.pkcs7_decrypt works but is private and is based on OpenSSL, so what we'd want is a class / function that does the same without openssl dependency?

[alex]

No one has started on decryption. The `test_support` function is the bare minimum necessary for our tests. The first step here will be figuring out what the right API is, so if you want to take a look at what your needs are and come back with a proposal for what the API should look like, we can get started on that.

…

On Thu, Aug 22, 2024 at 11:56 AM Quentin Retourne ***@***.***> wrote: Hey, new here; I've been working with a client that uses encrypted email on Outlook. Was using asn1crypto & cryptography since march 2024 for private email decryption & encryption. Since july 2024, I've been using the new code for encryption, works like a charm with Outlook. Thanks again! I'd love to help on decryption. Is there already someone working on it? I understand that test_support.pkcs7_decrypt works but is private and is based on OpenSSL, so what we'd want is a class / function that does the same without openssl dependency? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[nitneuqr]

Great! Started working on it, will continue in the following weeks on my fork then.

[alex]

This was merged in #11555. For any follow ups, folks can file separate issues.