Encryption is a way to hide the meaning of data. It takes normal, readable data — called plaintext — and turns it into scrambled data called ciphertext. Anyone who intercepts the ciphertext without the right key just sees random-looking bytes.
plaintext: "Hello, bank!"
| encrypt with a key
v
ciphertext: "8f3a9c2e1b7d..."
To reverse the process and get the plaintext back, you need a matching key. This step is called decryption.
- Algorithm — the fixed set of math rules used to scramble and unscramble data (for example, AES).
- Key — a secret value fed into the algorithm. The same algorithm with a different key produces different ciphertext.
What encryption does, and doesn't, cover:
- Does — hide the meaning of data from anyone without the key.
- Does not — stop someone from changing the ciphertext. TLS adds a separate hash-based check for that.
- In TLS — this protection is often called "encryption in transit," since it covers data while it moves between your browser and a server.
Related Resources
Symmetric encryption uses one shared key for both sides of the conversation.
Alice Bob
key: "K7x..." key: "K7x..." (same key)
plaintext --[encrypt]--> ciphertext --[decrypt]--> plaintext
Whoever holds the key can both lock (encrypt) and unlock (decrypt) the data. This makes symmetric encryption simple and, importantly, fast — it needs much less computing power than asymmetric encryption.
Common symmetric algorithms:
- AES (Advanced Encryption Standard) — the industry standard today. Usually seen as AES-128 or AES-256, where the number is the key size in bits. Modern TLS uses AES in GCM mode, which adds a built-in integrity check.
- ChaCha20 — a newer algorithm, often paired with Poly1305 for integrity. It is popular on mobile devices because it is fast even without special hardware support.
- 3DES / DES — older algorithms, now considered weak or outdated. Modern TLS does not use them.
The one big problem symmetric encryption does not solve: how do two strangers agree on a shared key over an open, public network without anyone else seeing it? That problem is what asymmetric encryption helps solve, which the next question covers.
Related Resources
Asymmetric encryption uses two different keys instead of one:
- A public key, which the owner shares with anyone.
- A private key, which the owner never shares.
Anyone Server
has: server's public key has: matching private key
plaintext --[encrypt with public key]--> ciphertext
|
v
[decrypt with private key] --> plaintext
Anyone can encrypt a message using the server's public key, but only the server can decrypt it, because only the server holds the matching private key. The two keys are linked by math, but you cannot practically work out the private key just by knowing the public key.
Common asymmetric algorithms:
- RSA — one of the oldest and most widely used. Relies on the difficulty of factoring very large numbers.
- ECC (Elliptic-Curve Cryptography) — a newer family of math that gives the same security as RSA with much smaller keys. TLS uses ECC in two ways: ECDHE for key exchange and ECDSA for signatures.
Asymmetric encryption solves the "how do strangers agree on a key" problem from the previous question. But it is much slower than symmetric encryption, so TLS only uses it briefly, during the handshake, and switches to fast symmetric encryption for the actual data.
Related Resources
| Symmetric | Asymmetric | |
|---|---|---|
| Keys used | One shared key | Public + private key pair |
| Speed | Fast | Much slower (100x+ more math) |
| Key sharing problem | Hard — both sides need the same secret key first | Solved — the public key can be shared openly |
| Typical use in TLS | Encrypting the actual application data | Agreeing on a shared secret, and proving server identity |
| Example algorithms | AES, ChaCha20 | RSA, ECDHE, ECDSA |
Neither type alone is a great fit for TLS:
- Pure symmetric encryption is fast, but two strangers (your browser and a random website) have no safe way to agree on a shared key first.
- Pure asymmetric encryption solves the key-sharing problem, but it is too slow to encrypt a large amount of data, like a video stream or a big file download.
So TLS combines both, in a hybrid scheme:
Step 1 (asymmetric, slow, small amount of data):
Browser <----- agree on a shared secret -----> Server
(using ECDHE/RSA key exchange during the handshake)
Step 2 (symmetric, fast, all the real traffic):
Browser <----- AES-encrypted application data -----> Server
(using the shared secret from Step 1 as the AES key)
Result: the security of asymmetric key exchange, the speed of symmetric encryption.
Related Resources
A hash function turns data of any size into a short, fixed-size fingerprint.
"Pay Alice $100" --[SHA-256]--> a1b2c3d4e5f6... (always 256 bits)
"Pay Alice $900" --[SHA-256]--> 9f8e7d6c5b4a... (completely different)
Key properties a good hash function must have:
- Deterministic — the same input always produces the same hash.
- Fixed size — the output length never changes, no matter how big the input is.
- One-way — you cannot work backward from the hash to recover the original input.
- Avalanche effect — changing even one character in the input changes the hash completely.
- Collision-resistant — it should be practically impossible to find two different inputs that produce the same hash.
SHA-256 (part of the SHA-2 family) is the hash function most commonly used in modern TLS. Older functions like MD5 and SHA-1 are considered broken and are no longer trusted.
TLS uses hashing for two main jobs:
- Integrity checks — making sure data was not changed or corrupted while it traveled over the network.
- Digital signatures — hashing is the first step in signing data, which the next question explains.