What is Autocrypt and Why CTemplar Adopted it

Introducing Autocrypt and What it Means for CTemplar (and Non-CTemplar) Email Users Looking for Security and Privacy?

One of the biggest problems end-to-end encrypted email users face is the fact that encryption only works if both the sender and the recipient are using the same email service.

If the sides are using different email providers, however, then the emails sent between them cannot be encrypted, at least not without some juggling. The reason behind this is that they need to exchange keys securely.

This problem can be solved with Autocrypt, which is a cryptographic protocol that can enable encryption between separate email services.

Autocrypt uses OpenPGP standard and actually requires no support from email providers apart from keeping the Autocrypt-specific header fields. This is because the header contains the encryption preferences and the key materials necessary for the key exchange between users.

 So far, Autocrypt has been implemented by several email services (see the table below) and now CTemplar is joining them as we’ve finally implemented Autcrypt into our service.

This was something that was on our roadmap for a while now and we are proud to finally be able to offer full end-to-end encryption to our users even when they are sending emails to someone on non-CTemplar email service.

So far, sending an encrypted email message to non-CTemplar users meant that either:

  1. The message has to be sent in plaintext to the email server, which then encrypts the message for the CTemplar user and sends the plain message to non-CTemplar users (If the recipients are both CTemplar and non-CTemplar users);
  2. The message is sent to the email server in plaintext which encrypts it for the user, stores it and sends the plaintext to non-CTemplar users (for non-CTemplar recipients);
  3. Or, the user has to send an encryption password with a hint to the non-CTemplar user in case he wants to send them an encrypted message.

As you can probably guess, none of this is ideal and it meant that we had to encrypt emails that you get from non-CTemplar services “at rest”, but with Autocrypt, you’ll be able to get complete and, more importantly, convenient E2EE of emails.

Examples of Autocrypt in Action

Let’s take a look at a few examples of email communication with Autocrypt.

1:1 (One-to-One) Communication

If you are sending an email to another person upon sending the email, your mail user agent (MUA) will add a header containing your encryption key. This will look something like this:

Autocrypt: [email protected]; prefer-encrypt=mutual; keydata=…

From here, the recipient’s MUA will scan the email and once it finds your encryption key, it will store and identify it with your email address.

When the recipient then decides to send you a reply message, their MUA will locate the encryption key and inform them that the message will be encrypted and then, of course, encrypt it.

Next, your MUA will now scan the incoming email from the other person and store their key. Now both you and the recipient can send encrypted emails to each other.

1:N (One-to-Many) Communication

Let’s say you’re sending an email to two or more people. 

Just like in the 1:1 example above, your outgoing email will include a header that will include your encryption key. 

However, since the other two have only exchanged emails with you, they can’t encrypt to each other, but only you. 

To solve this and allow anyone to send encrypted messages to anyone in the group, you must add another header for every recipient, called Autocrypt-Gossip. This header reproduces their key to other recipients and allows them to start an encrypted conversation with others in the group.

Note that a 1:1 key exchange is somewhat more trustworthy than 1:N as there’s a chance that an attacker might spread the wrong encryption keys in the group. So whenever given the choice, use Autocrypt: headers over Gossip Headers.

What if You Lose Access to Your Key?

In case you lose access to your decryption key, your MUA will generate a new key for you and add it to the header with each mail from that point forward. Now the receiving MUA will replace the old with the new key.

At the same time, if the other person sends you an email that is encrypted to the old key, all you have to do is reply and this will allow their email service to see your new key and start using it.
Ready for the next stage of decentralized email security and privacy? Sign up today for CTemplar.