Sans Big Tech Part 6: Encrypting emails at rest

In Part 1 and Part 2 of this series, I explained why I start building a personal cloud as part of a long journey towards digital independence from Big Tech. In Part 3, I grappled with the big security risks that come with this choice:

When you go for your own cloud, security becomes your own responsibility. You have one and only one friend – mathematics (encryption). Ideally, everything in the server should be encrypted.

However, this is not always possible. For example, I run my own email server on my private cloud using Postfix and Dovecot, and this server has to receive and process incoming mail. All that is possible is to set up the email server so that incoming emails are automatically encrypted before being saved to the disk. If the server gets compromised, hackers will not be able to read old mails, but would have access to mails that arrive while they have control of the machine.

Even this setup poses a number of challenges, and it took me a long time to come up with a usable solution. The solution on the server side is quite straightforward due to the perl script created by Mike Cardwell who also explained the usage of this code in a blog post. Kacang Bawang adapted the method to work with the Postfix mail transfer agent that I use on my server. Basically, this solution uses public key encryption which requires the server to have only the encryption key (public key) and not the private decryption key. This means that the server can encrypt the email before storing it, but it cannot decrypt the encrypted email. A hacker who gains control of the server cannot read these emails.

The problems that took me a long time to solve were all related to the email clients on my Linux desktop and my Android phone. On the phone, I needed an email client that could handle encrypted email automatically and transparently. This means ditching the Gmail client in favour of a more GnuPG friendly client. K-9 Mail was a good choice, but I had difficulty getting used to its user interface. So I switched to FairEmail, and I quickly came to like its interface. Both K-9 Mail and FairEmail handle GPG encryption out of the box through the OpenKeyChain App. With this setup, the email client automatically decrypts emails received from my server, and I can read the email without any additional effort on my part.

On the desktop, where I have more than 350,000 downloaded emails, my requirements are more demanding. Such a large email collection is useless without the ability to search it quickly and flexibly. For nearly a decade now, I have been using notmuch for its outstanding search capability which I described in a blog post many years ago. For this search to work, the indexing must be done after the email has been decrypted. Fortunately, notmuch has the ability to do this with a command line option notmuch new --decrypt=true. The problem is that I do not want this decryption to happen for emails that were encrypted by the sender for confidentiality or other reasons. The only automatic decryption that I want is for emails automatically encrypted by my server. My solution is very simple. I use a bespoke public key on my server which is not used for anything else, and I run notmuch new with GNUPGHOME set to a special folder that contains only this one bespoke key. Now search on the desktop works nicely on the desktop exactly as it would if had not been encrypted by the server.

The drawback with this setup is that I lose the ability to search the body of the email on my phone. Searching the headers (from, to, subject and date) work fine because this metadata is not encrypted while using GnuPG. This is also a weakness of the solution because a hacker would be able to read all the header metadata of all emails even though the body of the email is encrypted.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s