Encryption Basics
Date: 2026-08-17
Reversible scrambling with a key. Symmetric encryption is fast and needs a shared secret; asymmetric is slow and solves the problem of not having one — and every real system uses asymmetric briefly to agree on a symmetric key.
Encryption transforms plaintext into ciphertext using a key, reversibly. Unlike Hashing, the original is recoverable — with the key.
The two families
SYMMETRIC ASYMMETRIC
one key, both ways a KEY PAIR
public + private
fast slow (100–1000×)
AES-256, ChaCha20 RSA, elliptic curve
problem: how do you solves exactly that
share the key?
ASYMMETRIC, THE CORE PROPERTY
encrypt with PUBLIC → decrypt with PRIVATE
= confidentiality. Anyone can send you
something only you can read
sign with PRIVATE → verify with PUBLIC
= authenticity. Only you could have
produced this
The public key is published. The private key never leaves. That asymmetry is what makes trust possible between parties who have never met.
How real systems combine them
Asymmetric is too slow for bulk data, so it’s used only to establish a shared secret:
1 asymmetric key exchange
→ both sides derive the same
symmetric key
2 symmetric encryption from then on
→ fast, for the whole session
That’s TLS. The certificate and handshake are asymmetric; the actual traffic is symmetric — TLS and HTTPS.
Encryption in transit versus at rest
IN TRANSIT TLS. Solved, and you should
have it everywhere
AT REST disk or database encryption.
Protects against a stolen
disk or a lost backup
← does NOT protect against
an attacker with database
access, because the
application decrypts
transparently
END TO END only the endpoints hold keys;
the server cannot read it
← the strongest, and the
hardest to build features on
At-rest encryption is often assumed to do more than it does. It’s a compliance and physical-theft control. A SQL injection reads decrypted data — Common Vulnerabilities.
What encryption alone doesn’t give you
Confidentiality is not integrity. Older modes let an attacker alter ciphertext in ways that produce meaningful plaintext changes without detection.
Authenticated encryption solves this — AES-GCM, ChaCha20-Poly1305 — by producing a tag that fails loudly if anything was altered.
Use an authenticated mode. Always. This is the single most common way hand-rolled encryption goes wrong.
The rules that actually matter
- Never write your own. Not the algorithm, not the mode, not the padding. Use a vetted library with sensible defaults — libsodium, the platform’s crypto API, or your language’s standard offering
- Never reuse a nonce or IV — an initialisation vector, the random value that makes the same plaintext encrypt differently each time — with the same key. It’s the standard catastrophic failure, and it can expose the plaintext outright
- Key management is the hard part, not the maths. Where the key lives, who can read it, how it rotates, what happens when it leaks — Secrets Management
- Encryption is not access control. If the application decrypts for anyone who asks, the encryption isn’t the boundary — Authentication vs Authorisation
- Rotate keys, and design for it before you need it. Retrofitting rotation onto data encrypted with one permanent key is a migration nobody enjoys
What you’ll actually do
Very little of this by hand, which is correct:
in transit enable TLS. Done
passwords a password hashing
library, not encryption
tokens/sessions signed, and encrypted
only if they carry
sensitive data
card data you don't touch it. The
payment provider tokenises
it, and staying out of
PCI scope is the design goal
at rest a platform toggle
See: Hashing · Sessions and Tokens
The judgement worth having is knowing what each control protects against — so that “it’s encrypted” prompts the question against whom, rather than ending the conversation.