How Encryption Works — Keeping Data Secret

Every time you log into a website, send a message, or make a payment, encryption is quietly protecting your data from anyone who might intercept it. Without encryption, passwords, financial records, and private conversations would travel across the internet in plain text — readable by any router, ISP, or attacker in between.

This article explains how modern encryption works: symmetric and asymmetric algorithms, how keys are agreed between strangers, how HTTPS protects your browser traffic, what digital signatures guarantee, how end-to-end encryption keeps messages private, where real systems actually fail, and why quantum computers are forcing the entire field to change its algorithms.

---

What Encryption Is (and What It Isn't)

Encryption is the process of transforming readable data (plaintext) into an unreadable scramble (ciphertext) using a mathematical algorithm and a key. Only someone with the correct key can reverse the process and recover the original data.

Encryption is often confused with two related concepts:

• Hashing — A one-way transformation. You can hash data but cannot reverse it. Used for storing passwords and verifying file integrity. Not encryption.
• Encoding — Transforms data format (Base64, UTF-8) with no secrecy. Anyone can decode it. Not encryption.

The strength of encryption depends on the algorithm and the key size. Modern ciphers are designed so that brute-forcing the key — trying every possible combination — is hopeless. A 128-bit key has 2^128, or roughly 3.4 × 10^38, possible values. Even a hypothetical machine testing a billion billion (10^18) keys per second would need more than 5 × 10^12 years to try half of them, which is hundreds of times the roughly 13.8-billion-year age of the universe.

Kerckhoffs's principle: the secret is the key, not the method

A rule that shapes all modern cryptography is usually credited to the Dutch cryptographer Auguste Kerckhoffs: a system should stay secure even if everything about it except the key is public. That is why AES, RSA, and TLS are published standards that anyone can read and attack. Algorithms that rely on being secret ("security through obscurity") tend to collapse once someone reverse-engineers them, while openly published algorithms that have survived decades of public attack earn trust precisely because so many people have tried and failed to break them.

Three goals, not one

People say "encryption" when they often mean three separate guarantees:

Goal	Question it answers	Typical tool
Confidentiality	Can anyone else read this?	Symmetric ciphers (AES, ChaCha20)
Integrity	Was this changed in transit?	MACs, authenticated encryption, hashes
Authenticity	Did this really come from who it claims?	Digital signatures, certificates

A system that encrypts without authenticating can still be attacked: an adversary who cannot read a message may still be able to flip bits in it in ways that change its meaning. That is why modern protocols use authenticated encryption, covered below.

---

A Short History: From Substitution to Public Keys

Cryptography is old, but the version that protects the internet is surprisingly recent.

• Classical ciphers. The Caesar cipher shifted each letter by a fixed amount; substitution ciphers swapped letters by a table. Both fall to frequency analysis — counting which symbols appear most often — because they preserve the statistical fingerprint of the language.
• Machine ciphers. Twentieth-century rotor machines such as Germany's Enigma changed the substitution with every keystroke. Allied codebreakers still broke it, largely by exploiting operator habits and predictable message content rather than a flaw in the pure mathematics — an early lesson that implementation and human behavior matter as much as the algorithm.
• Information theory. Claude Shannon's work in the 1940s put cryptography on a mathematical footing and showed that the one-time pad (a truly random key as long as the message, never reused) is provably unbreakable — and also impractical, because you must somehow deliver that enormous key in advance.
• Standardized computer ciphers. The US Data Encryption Standard (DES) was published in the 1970s. Its 56-bit key became brute-forceable as hardware improved, which led to the open competition that selected the Rijndael algorithm, designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, as the Advanced Encryption Standard (AES), published by NIST as FIPS 197 in 2001.
• Public-key cryptography. In 1976 Whitfield Diffie and Martin Hellman published a method for two parties to agree on a shared secret over a public channel. RSA followed in 1977. These ideas solved the problem that defeated every earlier system: how to share a key with someone you have never met.

If you want the network side of this story — how packets actually travel between you and a server — our explainer on how the internet actually works walks through the layers that encryption sits on top of, and the history of the invention of the internet shows why the original protocols carried everything in plain text.

---

Symmetric Encryption — One Key for Everything

Symmetric encryption uses the same key to both encrypt and decrypt data. It is fast and efficient, making it ideal for encrypting large amounts of data.

How AES Works

AES (Advanced Encryption Standard) is the dominant symmetric algorithm, standardized by NIST in 2001 and used in everything from disk encryption to TLS. It operates on 128-bit blocks of data with key sizes of 128, 192, or 256 bits.

AES is a block cipher that transforms data through multiple rounds of operations:

1. SubBytes — Each byte is replaced using a lookup table (S-Box), introducing non-linearity.
2. ShiftRows — Rows of the 4×4 byte grid are shifted cyclically.
3. MixColumns — Columns are mixed using matrix multiplication over a finite field.
4. AddRoundKey — The round key (derived from the main key) is XORed with the block.

These steps repeat 10 times (AES-128), 12 times (AES-192), or 14 times (AES-256); the final round skips MixColumns. Each round makes the relationship between key and ciphertext increasingly complex — changing one bit of the input or key changes roughly half the output bits (the avalanche effect).

# Python example using the cryptography library
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# Generate a random 256-bit key
key = os.urandom(32)

# Generate a random nonce (number used once)
nonce = os.urandom(12)

# Encrypt
aesgcm = AESGCM(key)
ciphertext = aesgcm.encrypt(nonce, b"Secret message", None)

# Decrypt
plaintext = aesgcm.decrypt(nonce, ciphertext, None)
print(plaintext) # b"Secret message"

Modes of operation: why the raw cipher is not enough

A block cipher on its own only scrambles one 16-byte block. To encrypt a whole file or a stream of network traffic you need a mode of operation, and choosing the wrong one is a classic mistake.

• ECB (Electronic Codebook) encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks, so patterns leak straight through — the famous demonstration is an encrypted bitmap image whose outline is still clearly visible. ECB should not be used for real data.
• CBC (Cipher Block Chaining) mixes each block with the previous ciphertext block, hiding patterns. It was widely used in older TLS versions but needs separate authentication and has been the source of several padding-related attacks.
• CTR (Counter) mode turns the block cipher into a stream cipher by encrypting a counter and XORing the result with the data.
• GCM (Galois/Counter Mode) combines CTR-mode encryption with an authentication tag. AES-GCM is the standard choice for modern use because it provides both confidentiality and integrity, detecting any tampering with the ciphertext.

This family is called AEAD — authenticated encryption with associated data. TLS 1.3 only permits AEAD ciphers, a deliberate break from older versions that allowed fragile combinations. ChaCha20-Poly1305 is the main non-AES alternative; it is fast in software, which made it popular on phones that lack AES hardware acceleration.

The nonce rule

The nonce in the code above is not decoration. With GCM, reusing the same nonce with the same key for two different messages is catastrophic: it can leak the XOR of the two plaintexts and allow an attacker to forge authentication tags. Protocols handle this by deriving nonces from a counter or a sequence number so they never repeat under one key. Many real-world failures come from exactly this kind of detail rather than from the cipher itself.

The symmetric key problem: How do two parties securely share the key in the first place? If an attacker intercepts the key exchange, they can decrypt everything. This is where asymmetric cryptography comes in.

---

Asymmetric Encryption — Public and Private Keys

Asymmetric cryptography uses a key pair: a public key and a private key that are mathematically linked.

• The public key is shared freely with everyone.
• The private key is kept secret by the owner.

This elegantly solves the key distribution problem. If Alice wants to send Bob a secret message, she encrypts it with Bob's public key. Only Bob's private key can decrypt it — and Bob never had to share it with anyone.

Diffie-Hellman: agreeing on a secret in public

Diffie-Hellman key exchange is the idea behind most modern key agreement. A useful mental model is paint mixing: Alice and Bob publicly agree on a common color, each secretly mixes in a private color, and they swap the results. Each then adds their own private color again. Both end up with the same final mixture, but an eavesdropper who only saw the publicly exchanged mixtures cannot "unmix" them to find it.

Mathematically, the "unmixing" is the discrete logarithm problem. Given a public base g, a prime modulus p, and the value g^a mod p, finding the secret a is believed to be infeasible for well-chosen large numbers. Alice sends g^a, Bob sends g^b, and both compute g^(ab) — the shared secret — without either secret exponent ever crossing the wire.

RSA

RSA (Rivest–Shamir–Adleman, 1977) was the first practical public-key encryption and signature scheme. Its security relies on the difficulty of factoring the product of two large prime numbers. Multiplying two primes of a thousand-plus bits takes a computer a moment; recovering the primes from their product is computationally infeasible with classical computers at recommended key sizes.

A tiny worked example shows the structure (real keys use numbers hundreds of digits long):

1. Pick primes p = 61 and q = 53. Their product n = 3,233 is part of the public key.
2. Compute φ(n) = (61 − 1)(53 − 1) = 3,120.
3. Choose a public exponent e = 17, which shares no factor with 3,120.
4. Find the private exponent d so that e × d leaves a remainder of 1 when divided by 3,120. Here d = 2,753, because 17 × 2,753 = 46,801 = 15 × 3,120 + 1.
5. To encrypt the message m = 65, compute 65^17 mod 3,233 = 2,790.
6. To decrypt, compute 2,790^2,753 mod 3,233, which returns 65.

Anyone who could factor 3,233 back into 61 and 53 could compute d — trivial here, infeasible at 3,072 bits.

RSA is far slower than AES for the same amount of data — by orders of magnitude — so it is never used to encrypt bulk data directly. Raw "textbook" RSA as shown above is also insecure in practice; real systems add randomized padding schemes such as OAEP for encryption and PSS for signatures.

ECC

ECC (Elliptic Curve Cryptography) achieves equivalent security to RSA with much smaller key sizes. A 256-bit ECC key provides roughly the same security as a 3,072-bit RSA key. Smaller keys mean faster computation and less bandwidth — critical for mobile devices and TLS handshakes.

Most modern TLS deployments use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key exchange, chosen for its combination of speed and forward secrecy. "Ephemeral" means each connection uses fresh, throwaway key pairs, so stealing a server's long-term key later does not unlock recorded past sessions.

---

Hashing — One-Way Fingerprints

Hashing is not encryption, but it is a core cryptographic tool. A hash function takes any input and produces a fixed-length output (digest). The same input always produces the same hash; even a one-character change produces a completely different hash.

SHA-256 produces a 256-bit (64 hex characters) digest:

echo -n "Hello" | sha256sum
# 185f8db32921bd46d35cc74b12e0a3a0...
echo -n "Hello!" | sha256sum
# 334d016f755cd6dc58c53a86e183882f... # completely different

Hash functions are one-way by design — you cannot reverse a hash to get the original input. This makes them ideal for:

• Password storage — Store a slow, salted hash of the password, never the password itself
• File integrity — Compare hash of downloaded file against published hash
• Digital signatures — Sign a hash of a document rather than the document itself
• Bitcoin.">Blockchain — Each block contains the hash of the previous block, a structure explained in our guide to how blockchain works

Why password hashing must be slow

General-purpose hashes like SHA-256 are designed to be fast, which is exactly wrong for passwords. If a database of fast hashes leaks, attackers can test billions of guesses per second on graphics cards. Password-specific functions such as bcrypt, scrypt, and Argon2 are deliberately slow and, in the case of scrypt and Argon2, memory-hungry, which multiplies the cost of every guess. A salt — a random value stored alongside each hash — ensures two users with the same password get different hashes and defeats precomputed lookup tables. The cleaner long-term answer is to remove shared secrets entirely, which is what passkeys do by replacing passwords with public-key credentials stored on your device.

---

The Hybrid Approach — How TLS Uses Both

In practice, modern cryptography uses both symmetric and asymmetric techniques:

1. Asymmetric crypto (slow) is used to securely establish a shared secret
2. That shared secret becomes the symmetric key (fast) for encrypting actual data

This hybrid approach gives you the security of asymmetric key exchange with the speed of symmetric encryption.

The TLS 1.3 Handshake Step by Step

When you visit https://example.com, your browser and the server execute a TLS handshake. In TLS 1.3, defined in RFC 8446 (published in August 2018), it looks like this:

1. Client Hello — The browser sends the TLS versions and cipher suites it supports, a random value, and — new in 1.3 — a key share: its half of an ephemeral Diffie-Hellman exchange, guessed in advance for the group the server is most likely to accept.
2. Server Hello — The server picks a cipher suite (e.g., TLS_AES_256_GCM_SHA384) and returns its own key share. At this point both sides can compute the shared secret, so everything after this message is already encrypted.
3. Certificate and proof — The server sends its certificate chain and a signature over the handshake transcript made with its private key, proving it actually holds the key the certificate names.
4. Certificate verification — The browser checks that the certificate chains up to a Certificate Authority (CA) it trusts, that it covers the domain name, and that it has not expired.
5. Finished — Both sides exchange "Finished" messages containing a MAC over the whole handshake, which detects any tampering with the earlier messages.

From this point, all HTTP requests and responses are encrypted with the negotiated AEAD cipher using keys derived from the shared secret. An eavesdropper sees only ciphertext, plus some metadata such as IP addresses, timing, and traffic volume.

TLS 1.3 streamlined the handshake to a single round trip (1-RTT) instead of two, removed RSA key transport and other legacy options, and made forward secrecy mandatory. That combination made HTTPS connections both faster and harder to misconfigure.

What the padlock does and does not prove

The browser padlock means three things: the connection is encrypted, it has not been tampered with in transit, and the server holds a valid certificate for the domain in the address bar. It does not mean the site is honest. A phishing domain can obtain a perfectly valid certificate, and HTTPS does nothing to protect data once it reaches the server. For a broader view of what attackers actually exploit, see our data-led overview of cybersecurity threats in 2026.

---

Digital Signatures

Digital signatures prove that a message came from a specific sender and has not been altered. They use the key pair the other way around from encryption:

1. Signing — The sender hashes the message, then applies a signing operation to that hash using their private key. The result is the signature.
2. Verification — The recipient runs a verification operation with the sender's public key, the received message, and the signature. The check succeeds only if the signature was produced by the matching private key over exactly that message.

For RSA, signing resembles "encrypting the hash with the private key," which is how it is often explained. Elliptic-curve schemes such as ECDSA and Ed25519 work differently under the hood, but the guarantees are the same.

This proves two things:

• Authenticity — Only the private key holder could have created that signature
• Integrity — If the message was altered after signing, verification fails

TLS certificates, software updates, Git commits, and code signing all use digital signatures.

Certificates and the chain of trust

A public key on its own is just a number; you need some reason to believe it belongs to the bank and not to an impostor. A certificate binds a public key to a name, and a Certificate Authority signs that binding. Your operating system and browser ship with a list of trusted root CAs. A server's certificate is typically signed by an intermediate CA, which in turn is signed by a root — the chain of trust. If any link fails to verify, the browser shows a warning. The weakness of the model is that any trusted CA can issue a certificate for any domain, which is why public Certificate Transparency logs now record issued certificates so that mis-issuance can be spotted.

---

End-to-End Encryption

End-to-end encryption (E2EE) means only the communicating parties can read the messages — not the server, not the provider. Ordinary HTTPS protects data between you and a server; the server itself sees the plaintext. With E2EE, the server only ever relays ciphertext.

The Signal Protocol (used by Signal, WhatsApp, and others) achieves E2EE through several techniques:

• X3DH (Extended Triple Diffie-Hellman) — Establishes an initial shared secret from a combination of long-term, medium-term, and one-time key pairs, so a conversation can start even when the recipient is offline.
• Double Ratchet Algorithm — After each message, both the symmetric key and the asymmetric ratchet advance. Each message is encrypted with a fresh key. If one key is compromised, past messages stay protected (forward secrecy) and later messages regain protection once the ratchet moves on (post-compromise security).

Signal has since published PQXDH, a successor to X3DH that adds a post-quantum key encapsulation mechanism to the initial key agreement; its specification is dated May 2023.

Where E2EE still leaks

Even perfect E2EE leaves metadata: who talks to whom, when, how often, and from which IP addresses. It also cannot protect messages on a compromised phone, and cloud backups that are not themselves end-to-end encrypted can expose message history. When evaluating a "secure" messenger, the questions are whether E2EE is on by default, whether backups are covered, and how much metadata the provider keeps.

---

Where Encryption Actually Fails

Breaking AES or RSA directly is almost never how data gets stolen. Real failures cluster in a few places:

• Key management. Keys hard-coded in source code, committed to public repositories, or stored next to the data they protect. Encryption is only as strong as the place the key lives.
• Implementation bugs. The 2014 Heartbleed bug in OpenSSL let attackers read server memory — potentially including private keys — without touching the cryptography itself.
• Bad randomness. Keys and nonces must be unpredictable. Weak random number generators have produced keys that attackers could guess or that collided across devices.
• Side channels. Timing differences, power consumption, and cache behavior can leak secret bits from an otherwise correct algorithm. Constant-time implementations and hardware AES instructions exist largely for this reason.
• Downgrade and misconfiguration. Allowing old protocol versions or weak ciphers lets an attacker push a connection onto the weakest option. TLS 1.3's removal of legacy choices was a direct response.
• People. Phishing, social engineering, and reused passwords bypass encryption entirely by obtaining legitimate access.

The practical lesson for developers is to use well-reviewed libraries with safe defaults rather than assembling primitives by hand. For everyone else, it is to keep software updated, because most fixes for these failures arrive as ordinary patches.

---

The Quantum Threat and Post-Quantum Cryptography

Quantum computers pose a serious long-term threat to RSA and ECC. Shor's algorithm — running on a sufficiently large, error-corrected quantum computer — can factor large numbers and solve discrete logarithm problems efficiently, which would break RSA, Diffie-Hellman and elliptic-curve cryptography. If you want to know why qubits can do this when ordinary bits cannot, our explainer on how quantum computers actually work covers superposition, interference and error correction.

Symmetric ciphers are much less threatened. Grover's algorithm gives a quadratic speed-up for brute-force search, which in theory halves the effective key length (AES-128 would offer roughly 64-bit security against such an attack). The straightforward response is to use 256-bit keys, which remain comfortably out of reach.

Harvest now, decrypt later

The reason migration is happening before a cryptographically relevant quantum computer exists is that encrypted traffic can be recorded today and stored. Data that must stay confidential for decades — medical records, state secrets, long-lived intellectual property — is exposed if it is captured now and decrypted later. Nobody can say with confidence when such a machine will arrive; NIST's own announcement notes that some experts expect one within a decade, while others are more skeptical. Planning for uncertainty is the point.

The NIST standards

On August 13, 2024, NIST released its first three finalized post-quantum standards and urged administrators to start integrating them immediately:

Standard	Former Name	Type	Math basis	Purpose
ML-KEM (FIPS 203)	CRYSTALS-Kyber	Key encapsulation	Module lattices	Replace RSA/ECDH for key establishment
ML-DSA (FIPS 204)	CRYSTALS-Dilithium	Digital signature	Module lattices	Primary general-purpose signature
SLH-DSA (FIPS 205)	SPHINCS+	Digital signature	Hash functions	Conservative backup signature
HQC (selected March 2025; standard not yet final)	HQC	Key encapsulation	Error-correcting codes	Backup to ML-KEM

On March 11, 2025, NIST selected HQC as a backup key-encapsulation algorithm. The rationale is diversity: HQC rests on different mathematics from ML-KEM, so a breakthrough against lattices would not automatically break both. NIST said it expected to finalize the HQC standard in 2027. In November 2024 NIST also published a draft transition report, NIST IR 8547, laying out how quantum-vulnerable algorithms will be phased out.

Hybrid deployment in the real world

Rather than switching algorithms overnight, deployments so far combine a classical exchange with a post-quantum one, so that the connection stays secure as long as either holds. Google announced in August 2023 that Chrome was adding a hybrid Kyber key-encapsulation mechanism to TLS. Apple announced its PQ3 protocol for iMessage in February 2024, rolling out with iOS 17.4, which combines post-quantum keys with existing elliptic-curve cryptography and periodically refreshes keys. Signal's PQXDH follows the same hybrid logic.

The hard part is not the algorithms but the inventory. Organizations have to find every place RSA and ECC are used — TLS, VPNs, code signing, smart cards, firmware, embedded devices — and replace them, often in hardware with long lifetimes. Post-quantum keys and signatures are also larger than their elliptic-curve equivalents, which matters for constrained devices and for protocols with tight message-size limits. A cryptographic transition of this scale has not been attempted before, which is why agencies describe it as a multi-year program. Our reality check on quantum AI hype covers how far today's quantum hardware still is from these attacks.

---

Symmetric vs Asymmetric vs Hashing — At a Glance

Property	Symmetric (AES)	Asymmetric (RSA/ECC)	Hashing (SHA-256)
Keys	One shared key	Public + private key pair	No key
Reversible	Yes (with key)	Yes (with private key)	No (one-way)
Speed	Very fast	Much slower	Very fast
Key size (comparable classical security)	128–256 bits	3,072-bit RSA / 256-bit ECC	N/A
Best for	Bulk data encryption	Key exchange, signatures	Passwords (slow variants), integrity
Examples	AES-256-GCM, ChaCha20-Poly1305	RSA, ECDSA, ECDHE, Ed25519	SHA-256, SHA-3, Argon2
Quantum outlook	Use 256-bit keys	Broken by Shor's algorithm; replace with ML-KEM / ML-DSA	Larger outputs remain adequate

---

Common Misconceptions

• "Military-grade encryption" means something special. It is a marketing phrase, usually meaning AES-256 — the same cipher your phone and browser already use.
• "Longer keys are always better." Beyond a point, longer keys add cost without meaningful security. AES-128 is not considered at risk from classical computers; the choice of AES-256 is mainly about quantum margin and policy.
• "Encrypted means anonymous." HTTPS and E2EE hide content, not the fact that you communicated, with whom, or when.
• "Hashing is a kind of encryption." Hashing has no key and cannot be reversed; you can only check a guess against it.
• "Quantum computers will break all encryption." They threaten today's public-key algorithms; symmetric ciphers with adequate key lengths and the new post-quantum standards are designed to withstand them.

---

FAQ

Q: Can encrypted data be hacked? A: Properly implemented modern encryption such as AES-256 cannot be brute-forced with current technology. Real-world breaches almost never break the algorithm — they steal keys, exploit software vulnerabilities, compromise endpoints, or use social engineering. The math is rarely the weak point; implementation and key management are.

Q: What's the difference between encryption and encoding? A: Encoding (Base64, URL encoding) is a format transformation with no secrecy — anyone can decode it. Encryption requires a key and is designed to keep data confidential. Never use encoding to "protect" sensitive data.

Q: Why does HTTPS show a padlock but the site still feels unsafe? A: HTTPS encrypts the connection between you and the server and confirms the server holds a certificate for that domain. It does not guarantee the server is trustworthy or that the site won't misuse your data. A phishing site can have a valid TLS certificate.

Q: Is end-to-end encryption truly unbreakable? A: The cryptography itself is sound. But E2EE can be defeated by compromising the device, exploiting software vulnerabilities in the messaging app, or backing up messages to cloud storage that is not end-to-end encrypted. Metadata about who you talk to also remains visible.

Q: When will quantum computers break RSA? A: Nobody knows. Current quantum computers are far too small and error-prone to threaten RSA. The concern is "harvest now, decrypt later" — attackers storing encrypted data today to decrypt when machines mature — which is why NIST published post-quantum standards in 2024 and urged immediate adoption.

Q: What is perfect forward secrecy? A: Forward secrecy means that if a long-term private key is compromised, past session keys cannot be derived from it. TLS with ECDHE has forward secrecy because each session generates fresh ephemeral keys that are discarded after use. RSA key transport, removed in TLS 1.3, lacked this property.

Q: Is AES-128 still safe? A: Against classical computers, yes; no practical attack recovers AES-128 keys. Some guidance prefers AES-256 for long-lived secrets because Grover's algorithm would reduce the effective strength of a 128-bit key against a future quantum attacker.

---

Sources

• NIST — First three finalized post-quantum encryption standards (August 13, 2024)
• NIST — HQC selected as fifth post-quantum algorithm (March 11, 2025)
• NIST IR 8547 (initial public draft, November 2024) — Transition to post-quantum cryptography standards
• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• AES (FIPS 197) — NIST
• Signal — The PQXDH Key Agreement Protocol
• Chromium Blog — Protecting Chrome traffic with hybrid Kyber KEM (August 2023)
• Apple Security Research — iMessage with PQ3 (February 2024)