Given that we use digital correspondence a lot in our daily lives, the hot topic of “end-to-end encryption” appears in the news every so often. But what is end-to-end encryption, and how does it differ from other kinds of encryption?
Let’s break down this encryption method and see why it’s so important.
What Is “End-to-End Encryption”?
End-to-end encryption is a way of protecting communications from prying eyes. If you send a message on the internet to someone else without proper encryption, people watching your connection can see what you’re sending. This is known as a man-in-the-middle attack.
As such, messaging services sometimes employ end-to-end encryption (E2EE) to protect their users. Some of the top instant messaging services use E2EE to prevent people from snooping in on their users.
To achieve this, the service implements a method that allows users to encrypt their messages automatically. Before someone sends a message out, they encrypt it using what’s called a “key.” This key makes the message unreadable, so snoopers can’t see what it says.
When the message arrives on the recipient’s device, the app uses a key to untangle the message back into what it originally said. Now the recipient can read what the message said, and hackers are kept out of the equation.
How Does E2EE Differ From Other Types of Encryption?
You may be confused as to how this method of encryption is any different than other methods. In truth, the actual mechanics behind E2EE are similar to other kinds of encryption. The main difference, however, is the answer to this question: who holds the encryption keys?
When you use a service with encryption that isn’t E2EE, you may send messages to your friend using a key that the service gave you. This is great for stopping hackers from peeking into your communications, but it does mean that the people who operate the service you’re using can technically read what you send.
It’s like if you used a messaging app to talk to your friend, and the developers who designed the app told you both to use the key “APPLE” to encrypt your data. Sure, random hackers can’t read what you say, but the developers know that you’re using APPLE as the key. This means they can decrypt your messages as you send them and read everything you’re saying.
When a company uses this kind of encryption, it turns into an issue of trust. Do you trust that the company that runs the messaging app will turn a blind eye and let you talk in private? Or will they use the APPLE key to crack open your security and read all the juicy details?
This isn’t an issue for E2EE. As you might expect from the “end-to-end” in its name, E2EE works by allowing each user to generate their own encryption keys on their device. This way, nobody—not even the messaging app developers—can unencrypt the messages without physically taking your device.
This is why E2EE is so popular and why some secure email apps use it. Users don’t need to trust a faceless company. They have everything they need to do the encryption themselves.
There are a few ways you can achieve this, but “public key encryption” and the “Diffie-Hellman key exchange” are some of the more well-known methods.
Achieving E2EE With Public Key Encryption
When a program uses public-key encryption, every user on the service gets two keys. The first is their public key, and this can be freely seen and given out to anyone. However, it’s worth noting that the public key can only encrypt data; it cannot be used to decrypt it.
Each user also gets a private key, which is never shared and permanently sits on its device. The private key is designed so that the private key can decrypt any data encrypted using the public key. However, you should also note that the private key can only decrypt data; it’s never used to encrypt it.
When two people want to talk to one another, they trade public keys. They then use the other person’s public key to encrypt their messages to them. Once a public key encrypts it, it can only be properly decrypted by the recipient’s private key, which never leaves their device.
A Non-Technical Example of Public Key Encryption
To better picture how this system works, imagine that Bob and Alice want to talk to one another. To achieve this, they buy a lockbox from a somewhat eccentric security company.
Here’s how it works.
A lockbox can be swiped with a “lock” or an “unlock” card to lock or unlock it. Every user has a unique “lock” and “unlock” card to use on the lockbox. Furthermore, you can order a copy of a specific person’s “lock” card from the company, but you can never order someone’s “unlock” card.
Bob has two cards: BOB LOCK and BOB UNLOCK. Alice also has her own set of cards, ALICE LOCK and ALICE UNLOCK.
If Bob closes the lockbox and swipes the BOB LOCK card, the lockbox will lock itself. It will remain locked, even if Bob swipes the BOB LOCK card a second time. The only way to unlock it is to swipe BOB UNLOCK. No other person’s unlock cards will work.
Now, let’s say Bob wants to send a message to Alice. He needs to order a copy of one of Alice’s lock cards from the lockbox company to do this. The company allows this because you can’t use a lock card to break into a lockbox. You can only use it to lock one.
Bob orders an ALICE LOCK card. He then writes a letter to Alice, puts it in the lockbox, and then swipes the ALICE LOCK card. The lockbox is tightly locked and can only be unlocked if an ALICE UNLOCK card is swiped. Bob’s own unlock card is useless.
Now, Bob can send the lockbox to Alice. Even if someone interested in the letter were to order their own ALICE LOCK card and hijack the box, they can’t get it open. Only an ALICE UNLOCK card can unlock it, and Alice is the only owner of said card.
Alice receives the lockbox from Bob, uses her ALICE UNLOCK card to open it, and reads the letter. If Alice wanted to send a message back, she can order and use a BOB LOCK card to send the lockbox back. Now, only the BOB UNLOCK card can open it—which only Bob has.
Achieving E2EE With the Diffie-Hellman Key Exchange
If two people want to achieve E2EE on an insecure network, there is a way for them to share encryption keys in plain sight and not get hacked.
To do this, both sides first agree on a shared key. This key is openly shared, and the Diffie-Hellman key exchange system assumes that hackers will find out what this key is.
However, both sides then generate a private key on their own devices. They then add this private key to the shared one, then send their combined key to the recipient. When they receive the recipient’s combined key, they add it to their private one to get a shared secret key to use for encryption.
A Non-Technical Example of the Diffie-Hellman Key Exchange
If we go back to Bob and Alice, let’s say they use this technique to share information. First, they both agree on a shared number—let’s say the number three. This is done publically, so a snooper can theoretically overhear this number.
Then, Bob and Alice choose a number in private. Let’s say Bob chooses the number eight, and Alice chooses five. Then, they add their chosen number to the agreed shared number and give the other person the result.
- Bob takes the shared key (3) and his private key (8) and gets 11 (8+3). He gives the number 11 to Alice.
- Alice takes the shared key (3) and her private key (5) and gets 8 (5+3). She gives the number 8 to Bob.
This share is also done in public, so again, a snooper can potentially see that Bob shared 11 and Alice shared 8.
Once the share is done, each side adds what they received with their private number. This results in both sides getting the same number due to how a sum with only addition doesn’t care about order.
- Bob receives Alice’s combined number (8), adds his private number to it (8), and gets 16. (8+8)
- Alice receives Bob’s combined number (11), adds her own private number to it (5), and gets 16. (11+5)
- Both sides can encrypt messages using the key “16,” which nobody outside of Bob and Alice knows about.
Of course, in this example, a hacker could crack this code very easily. All they need is the shared key, the key Bob sends, and the key Alice sends, all of which are sent in broad daylight.
However, programmers implementing the Diffie-Hellman key exchange will implement complex equations that are hard for hackers to reverse-engineer and will still give the same result no matter what order the numbers are entered in.
That way, hackers are left puzzled about what generated the numbers while Bob and Alice chat safely using the shared key.
Sending Data Safely Using E2EE
If you don’t want to trust companies not to peek at your data, you don’t have to. Using E2EE methods, nobody can peek at your messages until they arrive safely at their destination.
If all this talk of encryption has made you want to tighten up your computer’s security, did you know there are several ways to encrypt your daily life?
Image Credit: Steve Heap / Shutterstock.com
About The Author
