• Neeraj

The 101 series: Encryption in emails

Updated: Mar 2

If you're like me, you first heard about encryption while watching The Da Vinci Code. And then ignored it for years, till you found that encryption makes the modern world go round - featuring in emails, cash withdrawals and online transactions.

The idea of encryption is simple - a message can be converted into a secret code no one can read, unless they know how to decode it (like Robert Langdon). Thanks to technology, cracking most modern day encryption is almost impossible.


So how did I get interested in encryption? Well I was trying to find out about Verifiable Credentials (VCs) and found that VC encryption is quite similar to Email encryption. Which's great, except I knew nothing about Email encryption.

I did eventually find out a few things, most notably that it's a rabbit hole. So it's only fair that I share my notes around encryption here and shorten the introduction for a few other non-techies. Here're the parts we're gonna talk about:

Let's start with...

What's new with Email?

Not much really, they've been around for a while. The point of this article is to talk about encryption, so I'm going to skip the history lesson. Tl;dr being they ruled the world before their cooler instant messaging cousins came along. But not everyone's moved to Slack and / or Telegram - I still use Email and I bet a lot of other people do.

Feel free to imagine three paragraphs here about how useful Email is, how it has changed our lives, made us better people, blah blah. Meanwhile, I'll move on and talk about...

How do emails work?

For most of us, sending an Email seems like a simple two step process:

Reality, however, is a tad different:

In reality, sending your message off into the network cloud is a bit like sending Little Red Riding Hood into the deep dark woods. You never know what might happen.

I'm not going to talk more about how the workings of email here, largely because it'll look like a copied assignment from here and here.

But now that you know your email bounces around before reaching it's destination, the answer to...

Why encrypt Emails?

...should be obvious.

Think of all the parties your email goes through. Imagine what'd happen if all of them could see the content of your mails. Maybe there'd be complete transparency, no misunderstandings and ensuing world peace. That's about as likely as Unicorn Jedi warriors saving earth from an alien invasion. More likely, Big Tech would know even more about you than it does today.


Luckily, some smart people saw (some of) this coming and started encrypting emails (and other messages) in transit a decade ago, meaning nosy intermediaries who forward your mails couldn't see what goes in them. This's called Transport Level Encryption, which's done via Transport Layer Security (TLS). It doesn't stop your email application (aka client) from reading your messages though. Gmail and most other email clients have TLS turned on by default in 2022. Caveat: TLS only works if both the sender('s mail client) and the recipient('s mail client) both use TLS.

A more complete alternative is End -to-end Encryption (E2EE) where only the sender and the receiver can read the content, not even the client. Whatsapp claims to do it for all conversations. Gmail's "thinking" about doing it, but I wouldn't hold my breath.

That being the why, let's come to...

How does this encryption work?

Finally, we come to the point! Thank you!

There are different types of encryption, but they fall into two broad categories: symmetric and asymmetric.

  • Symmetric encryption's your good old fashioned idea of locking content with one key and sharing (a copy of) the key.

  • Asymmetric encryption's basically mathematical magic, that allows you to lock content with one key and open it with another (!). More on that in a bit.


One of the most popular forms of asymmetric encryption on the net is PKC (Public Key Cryptography). PKC's used to encrypt emails in transit, so that's what we'll talk about here.

PKC is a form of asymmetric encryption, as in it uses different keys to encrypt (lock) and decrypt (unlock). PKC involves the use of a "key-pair":

  • One's called a private key, which is the little secret you (or your email client) keep to yourself, just like your teenage DMs.

  • Then there's a partner public key, which you can (and should) share with the world, like your fake LinkedIn endorsements.

These keys are not picked at random, they're generated as a pair by algorithms.

Now here's the magic bit - if a message is encrypted using a public key from a pair, it can only be decrypted using the corresponding private key. And vice versa.

Let me repeat that, in case you haven't heard it before:

If a message is encrypted using a public key from a pair, it can only be decrypted using the corresponding private key. And vice versa.

Public and private keys essentially act like complementary keys to a safe. Neither is useful alone, but together they can unlock the safe. Why? Because math!

Sounds a little weird the first time, but you get used to it. You'll have to either trust the math, work it out yourself or wait for me to oversimplify it in a later post.

Assuming it works, let's come to...

How're Emails Encrypted?

When someone sends you a mail with a service like Gmail in 2022:

  1. The mail application encrypts the mail using the public key of the recipient.

  2. The carrier in between (your snoopy internet service provider) forwards your mail along without being able to read the encrypted details.

  3. When the recipient application gets your mail, it decrypts the message using the recipients private key.


If you're wondering what the servers do, you can think of them as forwarding agents who know the right way to send and receive mails. If you want more, knock yourself out.

And that's it - Bob and Alice can talk away without the nosy servers knowing what they're talking about! Cheers all around, let's go home!

But wait...

Does encryption stop here?

No it doesn't. While you might blow the trumpets and hit the sack for now, you'll eventually come back to ask:

  1. How does Alice know the mail's from Bob ( and not from jealous Eve (

  2. How does Alice know that Bob's message wasn't altered? Her public key is public, remember? Eve can't read Bob's message, but can't she replace it with another of his own?

  3. How do Bob and Alice know each others' public keys?

Answers to 1 & 2 lie in a concept called digital signature. Not to be confused with pompous signature lines on emails.

Digital signatures use the concept of PKC again. But in reverse order to the previous section. Idea's simple, just remember

  • Anything encrypted with Bob's private key can be decrypted by Bob's public key only.

  • So any message that can be decrypted with Bob's public key must've been encrypted by Bob's private key.

  • Assuming only Bob has access to his private key, the message must have come from Bob.

So we simply re-encrypt the encrypted message (6ekd890optak1 above) with Bob's private key. Alice uses Bob's public key to confirm it's from Bob and everyone lives happily ever after!


As promised, what I've explained is in fact an oversimplified picture. The concept is the same, but modern day digital signatures work a bit differently. They convert the message into a hash, which can be compared later to ensure the message hasn't been altered. I'm going to skip that part because

Great, now we know how it all works! If all you wanted was to know how encryption works in principle, you should stop here. If you want to know what happens in reality, read on.

Let's now move on to tying up some loose ends, starting with...

What's the deal with TLS?

Seems like you chose the red pill. Well you'd been warned.

Remember everything I told you about Alice, Bob & Eve? This's the part where it all breaks down. Heartbreaking, I know. Just when it seemed like there might be a twist...


The ugly truth is that servers don't care about Alice, Bob or Eve; they just want to talk to their mail clients. When the mail client XYZ says is Bob, the servers assume it's true. What the servers do question is if XYZ is in fact XYZ.

So to answer question 3 from the last section (the one you conveniently forgot), Alice doesn't need to know Bob's public key. Instead, we operate with a chain of trust like the following:

  1. Alice and her mail client ABC trust each other

  2. Mail client ABC and server group S trust each other

  3. Server group S and mail client XYZ trust each other

  4. Mail client XYZ and Bob trust each other

And that's how Alice, mail client ABC, server group S, mail client XYZ and Bob all come to trust each other.

1 & 4 above are enabled via login authentication (password, biometrics etc.) and the mail application URL (, not

2 & 3 are enabled via agencies called Certificate Authorities and the Transport Layer Security (TLS) we'd mentioned earlier.

The idea behind TLS is to establish a secure connection between two parties, such as server group S and mail applications ABC or XYZ. Secure as in making sure:

  • Mail client ABC / XYZ is what it claims to be

  • Server S is what it claims to be

  • No one else can listen to a conversation between ABC / XYZ and S

A secure connection is established via a process called a TLS handshake. Once established, any following data exchange is assumed to be secure. The handshake works via a framework called Public Key Infrastructure (PKI), which's one word away and heavily reliant on Public Key Cryptography (PKC).

If I were to oversimplify the TLS handshake, it'd be something like this:

  • Client ABC initiates contact with server, establishes some rules of engagement for the conversation to follow.

  • Server S responds with its digital certificate and few other details. The certificate includes a public key K, is issued by a Certificate Authority (CA) and confirms that the public key K belongs to server S.

  • Client ABC checks if the certificate is valid (involves checking the digital signature with the CA's public key) to confirm that public key K belongs to server S.

  • But now client ABC, as paranoid as it is, needs to make sure it's talking to server S and not another server that got hold of S's certificate. To do so, it presents a challenge - it encrypts something using the public key K from the certificate and asks the server to decrypt using its private key.

  • If server S is able to decrypt the message, it means it has the private key corresponding to public key K. Which means it is... <drumroll> the real slim server S!

  • And that's just half of it. Server S is equally paranoid, so it mets out the same treatment to client ABC. By the end of it, both of them are sure they're who they claim to be (phew!)

To be more scary and precise, the exchange looks like this:


Now that client ABC and S can talk, ABC sends the mail to S.

Next, client XYZ goes through the same process while trying to fetch the mail from server S.

Sounds like an overkill doesn't it? But better safe than sorry...


You might have noticed that a lot of steps above bank on trusting CAs. Since we've been sufficiently paranoid to trust no one else so far, you might wonder...

What's so special about Certificate Authorities (CAs)?

Why do we trust a certificate from a Certificate Authority (CA)?

Answer's that we've got no choice. I mean, you have to start somewhere and CA's act as the first link in the chain. CA's certify other entities (Intermediate CAs), which certify other entities (Servers). There are different validation levels and related (elaborate) certification processes, but that's a story for another time.

While we put our trust in CAs as a source, validating identity remains one of the biggest problems on the internet...

(Source: most situations.

And with that, we come to the most important question of them all:

Why did I tell you all this, really?

To get you warmed up for my next post on Verifiable Credentials (VCs). And because this's way too long to cover there.

27 views0 comments

Recent Posts

See All