What Should I Know About Encryption?
You have probably heard the term “encryption ” used in several contexts and associated with different words. Generally, encryption refers to the mathematical process of making a message unreadable except to a person who has the key to “decrypt ” it into readable form.
Throughout history, people have used encryption to send messages to each other that (hopefully) couldn’t be read by anyone besides the intended recipient. Today, we have computers that are capable of performing encryption for us. Digital encryption technology has expanded beyond simple secret messages; today, you can use encryption for more elaborate purposes, for example, to verify the author of messages.
Encryption is the best technology we have to protect information from bad actors, governments, and service providers, and it has developed to the point that it is virtually impossible to break—when used correctly.
In this guide, we’ll look at two major ways encryption is applied: to scramble data at rest and data in transit.
Encrypting Data At Rest anchor link
Data “at rest” is data that is stored somewhere: on a mobile device, laptop, server, or external hard drive, for example. When data is at rest, it is not moving from one place to another.
One example of a form of encryption that protects data at rest is “full-disk” encryption (also sometimes called “device encryption”). Enabling full-disk encryption encrypts all the information stored on a device and protects the information with a passphrase or another authentication method. On a mobile device or laptop, this usually looks just like a typical device lock screen, requiring a passcode, passphrase, or thumbprint. However, locking your device (i.e., requiring a password to “unlock” your device) does not always mean that full-disk encryption is enabled.
![]() ![]() |
A smart phone and laptop that each have a password-protected “lock” screen. |
Be sure to check how your operating system enables and manages full-disk encryption. While some operating systems have full-disk encryption enabled by default, some operating systems do not. That means someone could access the data on your mobile device by merely breaking the device lock, but not having to break the encryption key since the device itself is not encrypted. Some systems still store unencrypted plaintext on RAM, even when you are using full-disk encryption. RAM is temporary storage, which means that shortly after your device is powered down the memory typically can't be read, but a sophisticated adversary could attempt a cold boot attack and conceivably retrieve the RAM contents.
Full-disk encryption can protect your devices from people who have physical access to them. This is useful if you want to protect your data from roommates, coworkers or employers, school officials, family members, partners, police officers, or other law enforcement officials. It also protects the data on your devices if they are stolen or lost, like if you accidentally leave your phone on a bus or at a restaurant.
There are additional ways to encrypt data at rest. One option, known as “file encryption,” encrypts only specific, individual files on a computer or other storage device. Another option is “drive encryption” (also known as “disk encryption”): this encrypts all of the data on a specific storage area on a device.
You can use these different types of encryption at rest in combination. For example, let’s say you wanted to protect sensitive information on your medical documents. You can use file encryption to separately encrypt an individual medical file stored on your device. You can then use drive encryption to encrypt the part of your device that this medical information is stored on. Finally, if you have enabled full-disk encryption on your device, everything—all medical information as well as every other file on the drive, including the files for the computer’s operating system—is encrypted.
On Surveillance Self-Defense, we’ve written a couple guides for enabling encryption on your devices. Although you can find in-depth descriptions of encryption at rest options online (and here on SSD!), be aware that these options change frequently and instructions can become outdated quickly.
Encrypting Data In Transit anchor link
![]() |
The diagram shows unencrypted data in transit—which is often the default setting for Internet service providers. On the left, a smartphone sends a green, unencrypted message to another smartphone on the far right. Along the way, a cellphone tower passes the message along to company servers and then to another cellphone tower, which can each see the unencrypted “Hello” message. All computers and networks passing the unencrypted message are able to see the message. At the end, the other smartphone receives the unencrypted “Hello” message. |
Data “in transit” is information that is moving over a network from one place to another. When you send a message on a messaging app, for example, that message moves from your device, to the app company’s servers, to your recipient’s device. Another example is web browsing: when you go to a website, the data from that webpage travels from the website’s servers to your browser.
Some popular apps offer features that seem to protect messages, such as disappearing messages. However, just because a communication (like a chat or message) can feel secure, doesn’t mean that it actually is secure. Computers passing along your message may be able to look at the contents of your message.
It’s important to verify that conversations between you and your recipient are encrypted—and to know whether they are encrypted via transport-layer encryption or end-to-end encryption .
There are two ways to encrypt data in transit: transport-layer encryption and end-to-end encryption. The type of encryption a service provider supports can be an important factor in deciding what services are right for you. The examples below illustrate the differences between transport-layer encryption and end-to-end encryption.
Transport-layer encryption anchor link
![]() |
The diagram shows transport-layer encryption. On the left, a smart phone sends a green, unencrypted message: “Hello.” That message is encrypted, and then passed along to a cellphone tower. In the middle, the company servers are able to decrypt the message, re-encrypt it, and send it along to the next cellphone tower. At the end, the other smartphone receives the encrypted message, and decrypts it to read “Hello.” |
Transport-layer encryption, also known as transport layer security (TLS), protects messages as they travel from your device to the app’s servers and from the app’s servers to your recipient’s device. In the middle, your messaging service provider—or the website you are browsing, or the app you are using—can see unencrypted copies of your messages. Because your messages can be seen by (and are often stored on) company servers, they may be vulnerable to law enforcement requests or leaking if the company’s servers are compromised.
Transport-layer encryption example: HTTPS anchor link
Do you notice the green lock and “https://” beside the web address for ssd.eff.org in the web address part of your browser window? HTTPS is an example of transport-layer encryption that we encounter frequently on the web. It provides more security than unencrypted HTTP. Why? Because the servers of the HTTPS website you are browsing can see the data you enter while on their site (for example, messages, searches, credit card numbers, and logins) however this information is unreadable to eavesdroppers on the network.
If someone is spying on the network and trying to see what websites users are visiting, an HTTP connection offers no protection. An HTTPS connection, on the other hand, hides which specific page on a website you navigate to—that is, everything “after the slash.” For example, if you are using HTTPS to connect to “https://ssd.eff.org/en/module/what-encryption” an eavesdropper can only see “https://ssd.eff.org”.
The web is in the middle of a large shift to using HTTPS for all webpages. This is because HTTP lacks any meaningful security, and HTTPS is secure by default. Webpages that come to you over HTTP are vulnerable to eavesdropping, content injection, cookie stealing, login and password stealing, targeted censorship, and other problems.
We recommend using EFF’s browser extension HTTPS Everywhere to receive the greatest amount of protection with HTTPS. HTTPS Everywhere ensures that if a website we know about offers HTTPS as well as HTTP, you’ll always be using the secure HTTPS version of the site.
Just because a service uses HTTPS does not mean that the service necessarily protects the privacy of its users visiting its website. For example, an HTTPS-protected site may still use tracking cookies or host malware .
Transport-layer encryption example: VPN anchor link
A Virtual Private Network (VPN ) is another example of transport-layer encryption. Without a VPN, your traffic travels over your Internet service provider’s (ISP’s) connection. With a VPN, your traffic still travels over your ISP’s connection, but it will be encrypted between you and your VPN provider. If someone is spying on your local network and trying to see what websites you’re visiting, they will be able to see that you’re connected to a VPN, but not able to see what websites you are ultimately visiting. Your ISP can detect who your VPN provider is.
While using a VPN hides your traffic from your ISP, it also exposes all your traffic to the VPN provider itself. The VPN provider will be able to see, store, and modify your traffic. Using a VPN essentially shifts your trust from your ISP to the VPN, so it’s important to make sure you trust your VPN provider to protect your data.
For further advice on choosing a VPN that’s right for you, read SSD’s guide on VPNs.
End-to-End Encryption anchor link
![]() |
The diagram shows end-to-end encryption. On the left, a smart phone sends a green, unencrypted message: “Hello.” That message is encrypted, and then passed along to a cellphone tower and company servers. At the end, the other smartphone receives the encrypted message, and decrypts it to read “Hello.” Unlike with transport-layer encryption, your ISP servers are not able to decrypt the message; Only the endpoints (the original devices sending and receiving encrypted messages) have the keys to decrypt the message. |
End-to-end encryption protects messages in transit all the way from sender to receiver. It ensures that information is turned into a secret message by its original sender (the first “end”) and decoded only by its final recipient (the second “end”). No one, including the app you are using, can “listen in” and eavesdrop on your activity.
Accessing end-to-end encrypted messages in an app on your device actually means that the app company itself can’t read them. This is a core characteristic of good encryption: even the people who design and deploy it cannot themselves break it.
On Surveillance Self-Defense, we offer guides for using end-to-end encryption tools in our Communicating With Others guide.
Transport-Layer Encryption or End-to-End Encryption? anchor link
Important questions to ask to decide whether you need transport-layer encryption or end-to-end encryption are: Do you trust the app or service you are using? Do you trust its technical infrastructure? How about its policies to protect against law enforcement requests?
If you answer “no,” to any of these questions, then you need end-to-end encryption. If you answer “yes” to them, then a service that supports only transport-layer encryption may suffice for you—but it is generally better to go with services that support end-to-end encryption when possible.
We created the animation below to demonstrate how end-to-end and transport-layer encryption work for data in transit. On the left is an end-to-end encryption chat tool (a chat box using the Off-the-Record (“OTR ”) instant messaging encrypted protocol ). On the right, is a transport-layer encryption chat box (encrypted through the Google Hangouts’ website use of HTTPS).
In the GIF, the primary user types a message in the Google Hangouts chat box:
“Hi! This is not end-to-end encrypted. Google can see our conversation.”
This user also has an Off-the-Record (OTR) chat box open and enables the “private conversation” setting. On the OTR chat box, the descriptive text says:
“Attempting to start a private conversation with [gmail account]. Private conversation with [gmail account] has started. However, their identity has not been verified.”
Simultaneously, in the Google Hangouts chat box, gibberish ciphertext is being exchanged, showing that the users are now on the Off-the-Record (OTR) end-to-end encryption protocol. Every message passed through OTR chat box also appears in the Google Hangouts chat box, however, instead of being readable, it appears as gibberish. The other user types a message in the OTR client:
“It looks like gibberish to anyone else.”
The primary user writes:
“Yup, it looks like nonsense.”
The other user sends a smiley emoji.
What Encryption In Transit Does Not Do anchor link
Encryption is not a cure-all. Even if you are sending encrypted messages, the message will be decrypted by the person with whom you are communicating. If your endpoints (the devices that you are using for communication) are compromised, your encrypted communications can be compromised. Additionally, the person with whom you are communicating can take screenshots or keep records (logs) of your communication.
If you automatically store backups of encrypted conversations to “the cloud” (other computers), be mindful to check that your backups are also encrypted. This ensures that your conversations are not only encrypted in transit, but also at rest.
If you encrypt data in transit, it will protect the content of your communications, but will not encrypt metadata. For example, you can use encryption to scramble the messages between you and your friend into gibberish, but it does not hide:
- that you and your friend are communicating.
- that you are using encryption to communicate.
- other types of information about your communication, such as the location, times and length of communication.
People with heightened surveillance concerns (such as those worried about active monitoring of their networks) can put themselves at risk by only using encryption during sensitive times or for specific activities. Why? If you only use encryption sometimes, it could tie your metadata to important dates and times. Therefore, use encryption as much as possible, even for mundane activities.
Also, if you’re the only person using encryption on a network, this metadata may be seen as suspicious. This is why many encryption enthusiasts encourage everyone to use encrypted tools whenever they are able: to normalize the use of encryption for people who really need it.
Putting It All Together anchor link
Together, encrypting both data in transit and at rest will offer you more comprehensive security than using just one or the other. This is what information security experts call “defense in depth.” By utilizing multiple methods to defend your data, you can achieve a deeper level of protection.
For example, if you send unencrypted messages (not encrypting your data in transit) from an encrypted mobile device (encrypting your data at rest), those messages will still be vulnerable to network eavesdropping and interception from governments, service providers, or technically-skilled adversaries. The record of the messages on your mobile device, however, will be protected from someone with physical access to your mobile device if they don’t have the passcode.
Conversely, if you send end-to-end encrypted messages (encrypting your data in transit) on an unencrypted device (not encrypting your data at rest), those messages will be impermeable to snooping and eavesdropping on the network. If someone gets physical access to your mobile device, however, they will be able to access and read the messages.
With these examples in mind, encrypting your data both while it’s in transit on the network and while it’s at rest on your device is ideal for protecting yourself from a wider range of potential risks.
For a deeper dive on how to use encryption, please continue onto our guide Key Concepts in Encryption.