Heya, I found how you can digitally sign and encrypt emails! (It even gives them a cool icon for others to see!), and I havenāt seen anything about it before so I thought Iād share how I did it!
Do you also want to send encrypted emails and sign them? Just follow these few steps!
But beforehand, letās define some terms :
-
Signed email : Email with a valid numerical signature. Anyone can read it and know it has not been modified since it was sent.
-
Encrypted email : Email encrypted with the recipientās public key. They can decrypt it with their private key
-
S/MIME certificate : A
.p12file containing your private key (So keep it for yourself and donāt send it to anyone!!) and your public key.
Okay, now itās time toā¦
Start the setup (Obtain an S/MIME certificate)
- Youāll need to ask to an authority for a certificate. Personally I use Actalis because they give free certificates for multiple email addresses, valid for a year (you need to redo the setup every year). If you donāt want to use Actalis, more info is avilable here.
- Donāt forget to put the website in english if you donāt understand italian.
- Go on the page to request an S/MIME certificate, create an account and follow the setup. The verification email can take a little while (~2min)
- When the setup ends, youāll have a valid certificate in your dashboard (It can take a few minutes to appear if you just verified it) that you can download, and a password that Actalis emailed you to enable your certificate.
Install the certificate
- Download the .p12 file, then open it, type your password, and leave the default options to install the certificate on your device (Android or PC, on Android pick āFor VPN and appsā). Donāt delete your old one, so you can still decrypt old messages sent on the expired certificate
- Use an S/MIME compatible email client. On PC, there is Thunderbird, on Android, FairEmail.
- In your email client settings, importer the S/MIME certificate pofor signing AND encrypting your messages. It changes depending on your client, so here it is for Thunderbird :
- In the top-right menu, go to
Account settings,End-to-end encryption, underS/MIMEclick onManage S/MIME certificates,Importand pick your.p12file. Then, pickSelect a certificate, and pick yours from the tab āYour certificatesā.
- In the top-right menu, go to
An image is worth a thousand words (Sorry for the french)
Donāt forget to check the box to sign and/or encrypt every message just below, if you want!
Communicate with someone
Once this is done, here is how you can communicateā¦
- ā¦While signing your messages :
Itās easy, just click on āSignā before sending. Usually, email clients show a small medal next to your name to show the email is signed.
- ā¦While encrypting your messages :
For that, youāll need your recipientās public key. They needs to send you a signed message (not encrypted, since you donāt have each otherās key at this point) where you can get their public key from their signature, and add it to your email client, which will allow you to encrypt messages you send to them. Then, send them a signed email (you can encrypt it) so they can get your public key and add it to their client, and then youāll be able to exchange encrypted emails!
Iām not an expert and probably made a few mistakes, if you spot any please tell me in the comments and Iāll try to fix the guide!
Yes, it exists.
S/MIME requires the receiving side to have its own certificate or, to be more correct, a private key represented by the certificate. The recipientās certificate needs to be known to the sender. The senderās certificate needs to be known by the recipient. Thatās why S/MIME is not used. It requires configuration on both sides, before it can be used.
Most people donāt know how to obtain certificate and configure email client with it or donāt bother to obtain certificate even if they know. The same problem exists if PGP is used, even if it is a bit different.
I will cover S/MIME and PGP because of similarities.
S/MIME or certificate based solution is supported by many clients, so it is easier on end user than PGP. S/MIME is part of the specification, thatās why good email clients have built-in support. S/MIME problems are all around certificate management: how to obtain certificate (free or not), how to import certificate, how to trust certificate, how to import trusted root of the certificate.
It is easier to manage keys for free in PGP. PGP has no protocol level support in email clients, so it requires additional handling of underlying content. In effect PGP encrypted messages are injected into text message or sent as email attachments. In both cases PGP content has to be handled by external application (PGP encrypted text or image) or email client specific plug-in.
The technology is very old for both cases. It has not caught on due to friction of key management for both technologies. PGP has additional problem of content handling.
S/MIME is perfect if you want to communicate with family or friends as you can ensure everyone in your circle has their own private key. Even in this narrow case, I guarantee you will experience some friction to get this through.
Organizations can have it easier as they can issue certificates to their users. But then problem of trusted certificate authority comes into play, if they use their authority (every email client or OS running this email client has to import new Trusted Certificate Root, that is hard at ORG level and it gets worse when they have to tell their outside contacts how to work with them). If they use well known authority, they avoid Trusted Cert Root problem, but they have to pay for every user certificate.
So, you can see how thereās friction in S/MIME solution. IMO, S/MIME is a good solution, but friction made it unrealistic in major use cases.
At this point I recommend Delta Chat. I am not involved with it. I just like what I see. It is uses PGP technology. In the end it is looks like a modern P2P chat application with all the expected Chat functionality, but it is actually an email client sending PGP encrypted messages over email. Delta chat solved private key creation using built-in key generation. Public key exchange is solved via key exchange protocol. The problem of content attachment is solved by the application itself. Take a look at articles about it https://delta.chat/en/references
Signal vs Delta Chat. Signal metadata exposes your contacts and probably your time of contact. With Delta Chat you get the same level of meta data exposure: your contact and time of contact are in the open, because underlying protocol is email.
S/MIME protections. S/MIME keeps the same metadata in the open: contact and time of contact. Thatās because S/MIME protects the payload (message body), not the email protocol headers.
I might be a bit off on how PGP or S/MIME is passed around at SMTP headers level, but overall meaning shall stay the same.
