Key Concepts in Encryption
Son güncelleme: November 26, 2018
Under some circumstances, encryption can be fairly automatic and simple. But there are ways encryption can go wrong. The more you understand it, the safer you will be against such situations. We recommend reading the “What Should I Know About Encryption?” guide first if you haven’t already.
In this guide, we will look at five main ideas. These are important concepts for understanding encryption in transit:
- A cipher, a key
- Symmetric and asymmetric encryption
- Private and public keys
- Identity verification for people (public key fingerprints)
- Identity verification for websites (security certificates)
A Cipher, A Key anchor link
You’ve probably seen something that, on its face, is not understandable to you. Maybe it looks like it’s in another language, or like it’s gibberish—there’s some sort of barrier to being able to read and understand it. This doesn’t necessarily mean that it’s encrypted.
What differentiates something that is not understandable from something that’s encrypted?
Encryption is a mathematical process used to scramble information, so that it can be unscrambled only with special knowledge. The process involves a cipher and a key.
A cipher is a set of rules (an algorithm) for encrypting and decrypting. These are well-defined steps that can be followed as a formula.
A key is a piece of information that instructs the cipher in how to encrypt and decrypt. Keys are one of the most important concepts for understanding encryption.
One Key or Many Keys? anchor link
In symmetric encryption, there is one single key to both encrypt and decrypt information.
 |
| Older forms of encryption were symmetric. For the “Caesar cipher” used thousands of years ago by Julius Caesar, the key to encrypt and decrypt a message was a shift of three. For example, “A” would be changed to “D.” The message “ENCRYPTION IS COOL” would be encrypted to “HQFUBSWLRQ LV FRRO” using the key of three. That same key would be used to decrypt it back to the original message. |
Symmetric encryption is still used today—it often comes in the form of “stream ciphers” and “block ciphers,” which rely on complex mathematical processes to make their encryption hard to crack. Encryption today includes many steps of scrambling data to make it hard to reveal the original content without the valid key. Modern symmetric encryption algorithms, such as the Advanced Encryption Standard (AES) algorithm, are strong and fast. Symmetric encryption is widely used by computers for tasks like encrypting files, encrypting partitions on a computer, completely encrypting phones and computers using full-disk encryption, and encrypting databases like those of password managers. To decrypt this symmetrically-encrypted information, you’ll often be prompted for a password. This is why we recommend using strong passwords, and provide tutorials for generating strong passwords to protect this encrypted information.
Having a single key can be great if you are the only person who needs to access that information. But there’s a problem with having a single key: what if you wanted to share encrypted information with a friend far away? What if you couldn’t meet with your friend in person to share the private key? How could you share the key with your friend over an open Internet connection?
Asymmetric encryption, also known as public key encryption, addresses these problems. Asymmetric encryption involves two keys: a private key (for decryption) and a public key (for encryption).
|
Symmetric Encryption |
Asymmetric Encryption |
|---|---|
|
|
|
|
|
|
|
|
|
|
Symmetric and asymmetric encryption are often used together for encrypting data in transit.
Asymmetric Encryption: Private and Public Keys anchor link
Private and public keys come in matched pairs, because the private key and public key are mathematically tied together. You can think of it like a rock that is split in half. When held back together, the two halves fit in place to form the whole. No other rock-half will do. The public key and private key files are much the same, but are ultimately composed of computer-readable representations of very large numbers.
Although it is called a “public key,” it can be confusing to think of the public key as an actual, literal key to open things. It doesn’t quite serve that function. For more in-depth information on public keys and private keys, see SSD’s deep dive on public key cryptography.
 |
|
A public key is a file that you can give to anyone or publish publicly. When someone wants to send you an end-to-end encrypted message, they’ll need your public key to do so. |
|
|
|
Your private key lets you decrypt this encrypted message. Because your private key allows you to read these encrypted messages, it becomes very important to protect your private key. In addition, your private key can be used to sign documents so that others can verify that they really came from you. |
Since the private key is ultimately a file on a device that requires protection, we encourage you to password protect and encrypt the device where the private key is stored. On Surveillance Self-Defense, we have guides for strong passwords and device encryption.
|
Public Key |
Private Key |
|---|---|
|
|
|
|
|
|
|
In some ways, you can think of sending information in transit like sending a postcard. In the postcard illustration on the left (below), a sender writes: “HI! :-)” The sender addresses it to the message recipient. This message is unencrypted, and anyone passing the message along the way can read it.
On the right is that same postcard, with the message encrypted between the sender and receiver. The message still conveys the message “Hi! J” but now it looks like a block of encrypted gibberish to the rest of us.
How is this done? The sender has found the recipient’s public key. The sender addresses the message to the recipient’s public key, which encrypts the message. The sender has also included their signature to show that the encrypted message is really from them.
Note that the metadata—of who is sending and who is receiving the message, as well as additional information like time sent and received, where it passed through, and so on—is still visible. We can see that the sender and receiver are using encryption, we can tell that they are communicating, but we can’t read the content of their message.
Who Are You Encrypting To? Are They Who They Really Say They Are? anchor link
Now, you might be wondering: “I get that my public key lets someone send me an encrypted message, and that my private key lets me read that encrypted message. But what if someone pretends to be me? What if they create a new public and private key, and impersonate me?”
That’s where public key cryptography is especially useful: It lets you verify your identity and your recipient’s identity. Let’s look at the capabilities of the private key more closely.
In addition to letting you read encrypted messages that are sent to your public key, your private key lets you place unforgeable digital signatures on messages you send to other people, as though to say “yes, this is really me writing this.”
Your recipient will see your digital signature along with your message and compare it with the information listed from your public key.
Let’s look at how this works in practice.
Identity Verification for People: Public Key Fingerprints anchor link
When we send any kind of message, we rely on the good faith of people participating. It’s like in the real world: We don’t expect a mail delivery person to meddle with the contents of our mail, for example. We don’t expect someone to intercept a friend’s letter to us, open and modify it, and send it to us, as though nothing had been changed. But there’s a risk this could happen.
Encrypted messages have this same risk of being modified, however, public key cryptography allows us a way to double-check if information has been tampered with, by double-checking someone’s digital identity with their real-life identity.
The public key is a giant block of text in a file. It is also represented in a human-readable shortcut called a key fingerprint.
The word “fingerprint” means lots of different things in the field of computer security.
One use of the term is a “key fingerprint,” a string of characters like “65834 02604 86283 29728 37069 98932 73120 14774 81777 73663 16574 23234” that should allow you to uniquely and securely check that someone on the Internet is using the right private key.
In some apps, this information can be represented as a QR code that you and your friend scan off each other’s devices.
You can double-check that someone’s digital identity matches who they say they are through something called “fingerprint verification.”
Fingerprint verification is best done in real-life. If you’re able to meet with your friend in person, have your public key fingerprint available and let your friend double-check that every single character from your public key fingerprint matches what they have for your public key fingerprint. Checking a long string of characters like “342e 2309 bd20 0912 ff10 6c63 2192 1928” is tedious, but worth doing. If you’re not able to meet in person, you can make your fingerprint available through another secure channel, like another end-to-end encrypted messaging or chat system, or posted on a HTTPS site.
Verifying someone’s key fingerprint gives you a higher degree of certainty that it’s really them. But it’s not perfect because if the private keys are copied or stolen (say you have malware on your device, or someone physically accessed your device and copied the file), someone else would be able to use the same fingerprint. For this reason, if a private key is “stolen,” you will want to generate a new public and private key pair, and give your friends your new public key fingerprint.
Summary: Public-Key Encryption Capabilities anchor link
In general, using public-key encryption can provide users:
Secrecy: A message encrypted with public-key cryptography allows the sender to create a message that is secret, so that only the intended recipient can read it.
Authenticity: A recipient of a message signed with public-key cryptography can verify that the message was authentically crafted by the sender if they have the sender’s public key.
Integrity: A message signed or encrypted with public-key cryptography, in general, cannot be tampered with, otherwise the message will not decrypt or verify correctly. This means that even unintentional disruption of a message (e.g. because of a temporary network problem) will be detectable.
Identity Verification for Websites and Services: Security Certificates anchor link
You might wonder: “I can verify public key fingerprints, but what’s the equivalent for the web? How can I double-check that I’m using a service that really is the service that it says it is? How can I be sure that no one is interfering with my connection to a service?”
Someone using end-to-end encryption shares their public key widely so others can verify that they are who they say they are. Similarly, when using transport-layer encryption, your computer automatically checks to confirm whether a public key for a service is who it really says it is, and that it is encrypting to the intended service: this is called a security certificate.
Below, you can see an example of the security certificate for SSD from a generic Web browser. This information is often accessible by clicking the HTTPS lock in your Web browser and pulling up the certificate details.
The Web browser on your computer can make encrypted connections to sites using HTTPS. Websites often use security certificates to prove to your browser that you have a secure connection to the real site, and not to some other system that’s tampering with your connection. When they do that, they examine certificates to check the public keys of domain names—(like www.google.com, www.amazon.com, or ssd.eff.org). Certificates are one way of trying to determine if you know the correct public key for a person or website, so that you can communicate securely with them. But how does your computer know what the right public key is for sites you visit?
Modern browsers and operating systems include a list of trusted Certificate Authorities (CAs). The public keys for these CAs are pre-bundled when you download the browser or buy a computer. Certificate Authorities sign the public key of websites once they’ve validated them as legitimately operating a domain (such as www.example.com). When your browser visits an HTTPS site, it verifies that the certificate the site delivered has actually been signed by a CA that it trusts. This means that a trusted third-party has verified that the site is who they are claiming to be.
Just because a site’s security certificate been signed by a Certificate Authority, does not mean that the website is necessarily a secure site. There are limits to what a CA can verify—it can’t verify that a website is honest or trustworthy. For example, a website may be “secured” using HTTPS, but still host scams and malware. Be vigilant, and learn more by reading our guide on malware and phishing.
From time to time, you will see certificate-related error messages on the Web. Most commonly this is because a hotel or cafe network is trying to intercept your connection to a website in order to direct you to their login portal before accessing the web, or because of a bureaucratic mistake in the system of certificates. But occasionally it is because a hacker, thief, or police or spy agency is breaking the encrypted connection. Unfortunately, it is extremely difficult to tell the difference between these cases.
This means you should never click past a certificate warning if it relates to a site where you have an account or are reading any sensitive information.
Putting It All Together: Symmetric Keys, Asymmetric Keys, & Public Key Fingerprints. anchor link
The example of Transport-Layer Security Handshakes
When using transport-layer encryption, your computer’s browser and the computer of the website you’re visiting are using both symmetric algorithms and asymmetric algorithms.
Let’s examine a concrete example of how all these ideas work together: when you connect to this HTTPS website (https://ssd.eff.org/), what happens?
When a website uses HTTPS, your browser and the website’s server have a very fast set of interactions called “the handshake.” Your browser—the likes of Google Chrome, Mozilla Firefox, Tor Browser, and so forth—is talking to the server (computer) hosting our website, https://ssd.eff.org.
In the handshake, the browser and server first send each other notes to see if they have any shared preferences for encryption algorithms (these are known as “cipher suites”). You can think of it like your browser and our ssd.eff.org server are having a quick conversation: they’re asking each other what encryption methods they both know and should communicate in, as well as which encryption methods they prefer. (“Do we both know how to use an asymmetric algorithm like RSA in combination with a symmetric algorithm like AES? Yes, good. If this combination of encryption algorithms doesn’t work for us, what other encryption algorithms do we both know?”)
Then, your browser uses asymmetric encryption: it sends a public key certificate to ssd.eff.org to prove that you are who you say you are. The site server checks this public key certificate against your public key. This is to prevent a malicious computer from intercepting your connection.
Once your identity is confirmed, the site’s server uses symmetric encryption: it generates a new, symmetric, secret key file. Then, using asymmetric encryption to encrypt the key using your browser’s public key, and sends it to your browser. Your browser uses its private key to decrypt this file.
If this symmetric key works, your browser and website’s server use it to encrypt the rest of their communications. (This set of interactions is the transport layer security (TLS) handshake.) Thus, if all goes right in the handshake, your connection to ssd.eff.org shows up as Secure, with HTTPS beside ssd.eff.org.
For a deeper dive on public and private keys, as well as verification, read our SSD guide on public key encryption next.