Cryptography Basics
Symmetric, asymmetric, hashing, signatures — the four primitives everything else is built from.
Symmetric vs Asymmetric
Symmetric crypto (AES): one shared key encrypts and decrypts — fast, but both sides must already share the secret. Asymmetric crypto (RSA, elliptic curves): a public/private key pair — anyone encrypts with the public key, only the private key decrypts. Slow, but solves key distribution.
| Symmetric (AES-256) | Asymmetric (RSA/ECC) | |
|---|---|---|
| Keys | One shared secret | Public + private pair |
| Speed | Fast — bulk data | ~1000× slower — small payloads |
| Solves | Confidentiality at speed | Key exchange, signatures, identity |
| Real use | Disk/DB/TLS session data | TLS handshake, SSH, JWT signing |
Hashing — Fingerprints, Not Encryption
A hash function (SHA-256) maps any input to a fixed-size digest. Three properties make it cryptographic: one-way (can’t reverse), deterministic (same input → same digest), collision-resistant (can’t find two inputs with the same digest). Change one bit of input and the digest changes completely.
# verify a download wasn't corrupted or tampered sha256sum ubuntu-24.04.iso # git commit IDs are hashes of content + history git log --format=%H -1
Signatures & Key Exchange
Flip asymmetric crypto around and you get digital signatures: sign a message’s hash with your private key; anyone verifies with your public key. That yields integrity (any change breaks the signature), authenticity (only the key holder could sign), and non-repudiation (they can’t deny signing).
Diffie-Hellman key exchange solves the bootstrap problem: two parties each combine their private value with the other’s public value and arrive at the same shared secret — an eavesdropper seeing both public values still can’t compute it. This runs inside every TLS handshake (as ECDHE).
The Golden Rules
| Rule | Why |
|---|---|
| Never roll your own crypto | Decades of cryptanalysis beat any clever homebrew; use vetted libraries (libsodium, your platform’s TLS) |
| Never reuse a nonce/IV | Nonce reuse in AES-GCM catastrophically breaks confidentiality and integrity |
| Keys are the secret, not the algorithm | Kerckhoffs’s principle: assume the attacker knows everything except the key |
| Use authenticated encryption | AES-GCM / ChaCha20-Poly1305 — encryption without integrity invites tampering (padding-oracle attacks) |
| Plan for rotation | Keys leak; design so rotating them is routine, not a crisis |
Interview Questions
Why does TLS use both asymmetric and symmetric crypto?
Asymmetric solves the meeting-of-strangers problem (key exchange + server identity) but is ~1000× too slow for data. So the handshake uses ECDHE + certificates once, derives a symmetric session key, and AES/ChaCha20 carries the actual traffic.
Encryption vs hashing vs encoding.
Encryption: reversible with a key — confidentiality. Hashing: one-way fingerprint, no key — integrity. Encoding (base64): reversible with no key at all — a data format, and zero security. Calling base64 “encryption” is an instant red flag.
What does a digital signature prove?
That the holder of the private key produced this exact content: verify the signature over the message hash with the public key. Any modification breaks it (integrity), only the key holder could create it (authenticity, non-repudiation).
How does Diffie-Hellman work at a high level?
Each side combines its private value with the other’s public value; the math (discrete log / elliptic curves) makes both arrive at the same secret while an observer of the public values can’t compute it. Ephemeral DH (the E in ECDHE) gives forward secrecy — session keys die with the session.