S/MIME for public key encryption and signing of email explained

Question

I am doing my best to understand how this works. I read numerous articles, but always get confused.

From my limited understanding, both sender and recipient must have their client installed with a key/certificate provided by a certificate authority. But how do the mail clients of both the sender and the receiver use these certificate ?

Here a concrete example of something that confuses me, from Wikipedia (https://en.wikipedia.org/wiki/S/MIME):

While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, [...]

So, the sender mail client should be able to encrypt a message using the recipient certificate. In practice, how does the sender mail client infer, just from the mail address of the recipient, what is the recipient certificate ? Does the mail clients of the sender and of the recipient "ping" each other and exchange somehow this information ? Is it inferred from the domain of the email address ? Or are the users of the email clients expected to exchange before hand these information ?

Answer 1

You are asking several questions. That's probably because you are confused. Let me try to sort things out.

For encryption purposes

• the sender uses the recipient's public key (from the recipient's public certificate) to encrypt the email
• the recipient then uses their own private key to decrypt the email

For signing purposes

• the sender uses their own their own private key to sign the email
• the recipient then uses the sender's public key (from the sender's public certificate) to verify the signature

To exchange public certificates

1. Alice sends a signed, but not encrypted email to Bob
2. the signature includes Alice's public certificate
3. Bob can extract Alice's public certificate from the mail
4. Bob trusts Alice's certificate because it was signed by a trusted authority *)
5. Bob can now verify the signature including the certificate
6. Bob can now send encrypted email to Alice

*) Every operating system comes with a load of pre-trusted certificate authorities

Bob then also shares his own certificate by signing the email when replying back to Alice. After that, encryption is possible in both directions.

Other

The quote from Wikipedia addresses a different aspect:

If Alice sends an encrypted email to Bob, Alice uses Bob's public key to encrypt the email, so only Bob can decrypt it. But this also means that Alice cannot decrypt her own email (that it stored in her 'sent' folder)!

It would be a severe security breach to store the email unencrypted in Alice's 'sent' folder, so what can be done? The email can be encrypted for both, the recipient Bob as well as the sender Alice.

Now how can one email be encrypted with multiple encryption keys?

The email is actually not encrypted with Bob's key, but instead

1. a random key is chosen to encrypt the email contents
2. the random key is encrypted with Bob's key and added to the message
3. the random key is also encrypted with Alice's key and added to the message

Then to decrypt, the random key is decrypted with the recipient's private key, then the email contents is decrypted with that decrypted key.

The random key is called the 'content encryption key' or CEK, while the personal keys are called the 'key encryption keys' or KEK in this scenario.

There's yet another reason to use a CEK - which has to do with symmetric encryption being much faster and more scalable than asymmetric encryption - but that's another story that shall be told in an answer to another question.