Cryptography — Practical Fundamentals

#The Big Picture: what crypto is for

Almost every interview question reduces to one of four jobs. If you can name the job, you can pick the tool.

The one rule that ties it together: asymmetric crypto is slow, so we only use it to establish trust and agree on a shared key. Then fast symmetric crypto does the actual bulk encryption. That is TLS in a single sentence — the handshake is asymmetric, the conversation is symmetric.

#Symmetric Encryption

What is it?One shared key encrypts and decrypts. Like a physical key that both locks and unlocks the same box. Fast — it's what actually encrypts your data.

Why it mattersThis is the workhorse. Every HTTPS page, every encrypted disk, every VPN tunnel is symmetric encryption doing the heavy lifting. The hard part isn't the cipher; it's getting the shared key to both sides safely — which is why the rest of cryptography exists.

Where it's usedTLS sessions, disk encryption (BitLocker, FileVault, LUKS), VPNs (WireGuard, IPsec), Wi-Fi (WPA2/WPA3), SSH sessions, cloud storage at rest.

#The two ciphers you need to know

Both are AEAD ciphers — "Authenticated Encryption with Associated Data." AEAD means the cipher also detects tampering; if even one bit of the ciphertext is flipped, decryption fails loudly instead of returning garbage. Always use AEAD. The bare cipher modes that don't authenticate (ECB, CBC, CTR on their own) are how padding-oracle and bit-flipping attacks happen.

Memory hook

"Use AES-GCM, and never reuse a nonce." A nonce is a "number used once" — a small value that must be unique for every message under the same key. Reusing a nonce with GCM is catastrophic: it leaks the relationship between two plaintexts and lets an attacker forge valid messages. If nonce uniqueness is hard to guarantee (e.g. random generation across many servers), use AES-GCM-SIV, which is designed to survive accidental reuse.

Why you'll hear "never use ECB"ECB encrypts each chunk independently, so identical input chunks produce identical output chunks. The famous "ECB penguin" image is still recognizable after encryption because the pattern leaks straight through. ECB is the canonical "you did encryption wrong" answer.

#Recommendation

Use AES-256-GCM by default; use ChaCha20-Poly1305 where there's no AES hardware. Never roll your own mode, never use ECB, never reuse a nonce.

#Asymmetric Encryption

What is it?A pair of mathematically linked keys: a public key you hand out freely and a private key you guard. What one key does, only the other can undo. It's slow, so it's never used for bulk data — only for two jobs: agreeing on a key and signatures.

Why it mattersIt solves the problem symmetric crypto can't: how do two strangers who never met establish a secret over a wire an attacker is watching? The public key can be shouted across the room; only the private-key holder can act on it.

The mirror-image roles (the part that trips people up):

You cannot sign with a public key. Encrypt-to-public, sign-with-private.

#RSA vs Elliptic Curve

ECC gets the same security with far smaller keys — a 256-bit ECC key ≈ a 3072-bit RSA key. Smaller and faster is why everything new (TLS, SSH, Signal, modern certificates) leans elliptic-curve.

The curves to know

Memory hook

ECDSA vs Ed25519 — the "k" footgun. Traditional elliptic-curve signing (ECDSA) needs a fresh random number per signature. If that random number ever repeats or is predictable, the private key falls right out of two signatures — this is exactly how the Sony PS3 was hacked and how Bitcoin wallets have been drained. Ed25519 removes the random number entirely by deriving it deterministically from the message and key, so there's no RNG to fail. Interview line: "ECDSA's safety depends on a perfect random generator; Ed25519 removes that dependency."

#Recommendation

Prefer Ed25519 / X25519 for new systems. RSA (2048-bit minimum, 4096 for long-lived keys) is fine where you need broad compatibility. Never use raw "textbook" RSA — encryption needs OAEP padding, signatures need PSS padding.

#Diffie-Hellman and Forward Secrecy

What is it?A way for two people to agree on a shared secret while everyone is listening, without ever sending the secret. Each side mixes a public value with their own private value; the math works out so both arrive at the same answer but an eavesdropper can't.

Memory hook

The paint analogy (interviewers love this). Both sides start with a public, shared paint colour. Each secretly adds their own colour and swaps the mixed buckets in the open. Each then adds their secret colour to the other's bucket — and both end up with the identical final mix. An eavesdropper saw the two mixed buckets but can't "un-mix" paint to recover either secret. Mixing is easy; separating is hard. That's the whole trick.

Why it matters — Forward SecrecyThe "E" in ECDHE (Elliptic-Curve Diffie-Hellman Ephemeral) means a brand-new throwaway key pair every session, discarded right after. This gives forward secrecy: if an attacker records your encrypted traffic today and steals the server's private key a year from now, they still can't decrypt the old recordings, because the keys that protected them no longer exist.

This is the single biggest security win of TLS 1.3: it requires ephemeral Diffie-Hellman, so every connection has forward secrecy automatically. (Old TLS 1.2 allowed a mode where the client encrypted the session key to the server's long-term RSA key — steal that key later and all recorded traffic unlocks. TLS 1.3 deleted that mode.)

#Hashing

What is it?A one-way function that turns any input into a fixed-size fingerprint (a "digest"). Same input always gives the same fingerprint; you can't run it backwards; and you can't find two inputs with the same fingerprint.

Why it mattersHashing is how we check integrity ("did this file/message change?") and how we build fingerprints for signatures, certificates, and version control. When you verify a download's checksum or Git identifies a commit, that's hashing.

Where it's usedTLS and certificate signatures, HMAC, Git commit IDs, file integrity checks, blockchain proof-of-work, password storage (with special slow hashes — see below).

Memory hook

Why hash security is "half" the bit length — the birthday paradox. In a room of just 23 people, there's a >50% chance two share a birthday — surprising, because you're comparing every pair, not matching one specific date. The same math means finding a collision in an n-bit hash takes ~2^(n/2) tries, not 2^n. So a 256-bit hash gives only ~128-bit collision resistance. This is why 128-bit MD5 (only ~64-bit collision strength) fell so easily, and why you want generously sized digests.

#Recommendation

SHA-256 for general integrity and signatures. Never use a plain hash for passwords — that's a different problem (next section).

#Password Storage

Last verified2026-06 — Argon2id is the current OWASP first choice.

The problemIf your user database leaks, the attacker has every password hash and unlimited time to guess offline. A fast hash like SHA-256 does billions of guesses per second on a GPU — so a fast hash is a bad password hash.

The fix: deliberately slow, memory-hungry hashesPassword hashes are engineered to be expensive so an attacker can only try a few hundred or thousand guesses per second instead of billions.

Always add a salt — a unique random value per password, stored alongside the hash. The salt means two users with the same password get different hashes, so one precomputed "rainbow table" can't crack everyone at once. (A pepper — a secret added to all passwords and kept out of the database — is an optional extra layer.)

Memory hook

"a fast hash is a bad password hash." General hashes are built for speed; password hashes are built to be slow on purpose. bcrypt is slow; scrypt and Argon2id are also memory-hard so attackers can't just throw cheap parallel hardware at them.

#Recommendation

Argon2id for new systems; bcrypt is acceptable for existing ones. Always per-password salt. Never SHA-256/MD5 for passwords.

#MACs and Digital Signatures

Both answer "who sent this, and was it tampered with?" — but they trust differently.

#MAC (Message Authentication Code)

What is it?A keyed fingerprint. Both sides share one secret key; the sender attaches a tag, the receiver recomputes it. If the tags match, the message is authentic and unmodified. The common one is HMAC (e.g. HMAC-SHA256).

Where it's usedAPI request signing (AWS signs requests with HMAC-SHA256), session tokens, JWT "HS256", inside TLS.

The catch — symmetric trustBecause both sides hold the same key, a MAC proves the message came from someone who has the key — but the receiver could have forged it too. So a MAC gives integrity + authenticity between two trusting parties, but not non-repudiation (you can't prove to a third party which of the two sent it).

⚠️

Don't roll your own MAC by writing hash(secret + message). With SHA-256 that's vulnerable to a "length-extension attack" — an attacker who sees the tag can append data and produce a valid tag without knowing the secret. HMAC's nested design prevents this. Use HMAC, not naive concatenation.

#Digital Signature

What is it?Same goal, but with a key pair. You sign with your private key; anyone verifies with your public key. Since only you have the private key, a valid signature proves you specifically signed it — and you can't deny it later (non-repudiation).

Where it's usedTLS certificates (the CA signs your cert), code signing (Windows/macOS apps, software updates), Git commit signing, JWT "RS256/ES256", document signing.

#How TLS Works

What is it?TLS ("Transport Layer Security," the "S" in HTTPS) is the protocol that turns an open internet connection into a private, authenticated one. It does three things: encrypts the traffic, proves the server's identity (via its certificate), and detects tampering.

The whole idea in four steps

So: asymmetric to set up trust and a shared key, symmetric for the actual conversation.

TLS 1.3 handshake (1 round trip)

Client                                         Server
  │── ClientHello ──────────────────────────────►│
  │   "here are the ciphers I support,            │
  │    and here's my ECDHE key share already"     │
  │                                               │
  │◄───────────────────────── ServerHello ────────│
  │   "picked this cipher, here's my key share"   │
  │◄──── {Certificate} ───────────────────────────│  ← from here on, encrypted
  │◄──── {CertificateVerify} ─────────────────────│  signature proving it owns the cert
  │◄──── {Finished} ──────────────────────────────│
  │                                               │
  │── {Finished} ────────────────────────────────►│
  │                                               │
  │════════ encrypted application data ══════════ │

The clever bitthe client sends its key share in the very first message — it doesn't ask permission first. Because both sides can derive the shared secret right after ServerHello, the server can encrypt the certificate itself, so a passive eavesdropper can't even see which site you're visiting from the certificate.

#TLS 1.3 vs TLS 1.2

Last verified2026-06 — TLS 1.3 (RFC 8446, 2018) is the default in all major browsers and servers; TLS 1.0/1.1 are disabled.

The honest interview answer is: TLS 1.3 is faster and removed all the ways to do it insecurely.

Why this matters in one sentenceTLS 1.2 was insecure mostly through bad configuration — leaving weak ciphers enabled. TLS 1.3 deletes the bad options entirely, so you can't misconfigure your way into a weak handshake.

Memory hook

Why 1.3 is one round tripin 1.2 the client first asks which key exchange to use, waits, then sends its key. In 1.3 there's only one key-exchange family (ECDHE), so the client just sends its key share immediately. 1.2 negotiates-then-acts; 1.3 acts because there's nothing left to negotiate.

0-RTT caveat (a common follow-up)TLS 1.3 can resume a previous session with zero round trips by sending data in the first packet. The risk is replay — a network attacker can capture and re-send that early data. So 0-RTT is only safe for idempotent requests (a GET that just reads), never for "transfer money."

#Certificates and PKI

The problem certificates solvePublic-key crypto lets a server hand you a public key — but how do you know it's really bank.com's key and not an attacker's? Anyone can generate a key pair and claim any name.

The passport analogy (the best way to explain PKI):

• You don't personally verify every traveler. You trust the government (the Certificate Authority, CA) that issued the passport.
• The passport (the certificate) binds an identity (a domain name) to a tamper-proof government signature (the CA's signature).
• Border control (your browser) carries a list of trusted governments (the root store) and checks the passport against it.
• If a country starts issuing fake passports, everyone stops trusting it (a CA gets distrusted — this has really happened).

So a certificate is just: a public key + an identity + an expiry date, all signed by a CA your browser already trusts. That's the whole idea.

#The chain of trust

Root CA          (self-signed, kept offline in a vault, pre-installed in your device)
   └── Intermediate CA   (signed by the root; does the day-to-day issuing)
          └── Your server's certificate   (signed by the intermediate)

Your browser trusts the root. The root vouches for the intermediate. The intermediate vouches for the server. The root key stays offline so it can't be stolen; if an intermediate is compromised it can be revoked without burning the root.

#Types of certificate (what an interviewer probes)

By how much identity was checked

Memory hook

The old EV "green bar" with the company name is gone — browsers removed it around 2019 because users never noticed it and it gave no real anti-phishing benefit. Today a DV and EV cert look identical: a plain padlock. The padlock means "encrypted," not "trustworthy" — phishing sites have valid certificates too.

By how many names they cover

#Let's Encrypt and short lifetimes

Free, automated DV certs (via the ACME protocol) made HTTPS universal. Their certs last only ~90 days (and the industry is moving toward even shorter). Short lifetimes are a feature: a stolen key is only useful briefly, and broken revocation matters less because the cert expires soon anyway. This only works because renewal is fully automated.

#Revocation (when a cert must die early)

If a private key is stolen before expiry, you need to revoke the cert. This is the genuinely weak part of PKI:

The practical reality: revocation is unreliable, which is the real reason the industry chose short-lived certificates instead.

#Certificate Transparency (CT)

Every publicly trusted certificate must be recorded in public, append-only logs, and browsers reject certs that aren't. Why it exists: in 2011 the CA DigiNotar was hacked and secretly issued a fake *.google.com cert used to spy on ~300,000 users in Iran — and nobody could see it. CT makes secret mis-issuance visible: you can monitor the logs (via crt.sh) for any certificate issued for your domain. The trade-off: CT also lets attackers enumerate your subdomains, since every cert you get publicly reveals a hostname.

#How to Verify a Certificate (as a user)

A very common practical question: "You visit a site — how do you actually know the certificate is legit?" Walk through what the browser checks, in order:

As a human double-checking manuallyclick the padlock → "Connection is secure" → view the certificate. Confirm the issuer is a real CA, the subject/SAN matches the domain exactly (watch for look-alikes like bank-secure.com), and the validity dates are current. But remember the limit: a valid cert only proves "this is really the domain in the address bar and the traffic is encrypted." It does not prove the site is honest — a phishing domain can hold a perfectly valid DV certificate.

Memory hook

The key insight interviewers wantthe certificate authenticates the domain name, not the intentions of whoever owns it. Verifying the cert stops a man-in-the-middle; it doesn't stop you from voluntarily visiting a scam site.

#mTLS (Mutual TLS)

What is it?Normal TLS proves only the server's identity to the client — you verify the bank, the bank doesn't cryptographically verify you (you log in with a password instead). mTLS makes it two-way: the client also presents a certificate, so both sides prove their identity with keys.

Normal TLS:   Client ──checks──► Server's cert      (only server proves identity)
mTLS:         Client ──checks──► Server's cert
              Client ◄──checks── presents own cert  (both prove identity)

The problem it solvesPasswords and API keys can be phished, leaked, or replayed. A client certificate is a cryptographic identity that can't be guessed and can be tightly scoped and rotated. mTLS answers "is this really an authorized service/device, not just someone who got hold of a token?"

Where it's used (this is the practical part):

Why not use it everywhere?Every client needs its own cert, and you need to issue, distribute, rotate, and revoke all of them — that's a lot of PKI plumbing. So mTLS shines for machine-to-machine identity (a fixed, managed set of clients) and is rare for ordinary human web users, where passwords + MFA are easier to manage.

#Recommendation

Use mTLS for internal service-to-service auth and machine identity, ideally automated by a service mesh or a workload-identity system (SPIFFE) so cert rotation isn't manual. For human users, stick with passwords + phishing-resistant MFA (FIDO2/passkeys).

#The Quantum Question

Last verified2026-06 — NIST published the first post-quantum standards in 2024 (FIPS 203/204/205); hybrid TLS key exchange is shipping in major browsers.

You'll get one quantum question. Keep it simple — there are two quantum algorithms and they do different damage:

Warning

Harvest now, decrypt laterAn attacker can record encrypted traffic today and decrypt it once a large quantum computer exists. Any data that must stay secret for a decade is already at risk, which is why key exchange is being migrated first.

The responseTLS is rolling post-quantum key exchange out as a hybrid (X25519 + ML-KEM-768 together), so the session stays safe as long as either algorithm holds. Post-quantum signatures in certificates come later, because they make certificate chains several kilobytes larger.

#Recommendations Cheat Sheet

Last verified2026-06

Universal rulesnever invent your own crypto, never use ECB, never reuse a nonce, always salt passwords, prefer authenticated (AEAD) encryption, and prefer the elliptic-curve / TLS 1.3 / Argon2id "modern defaults" unless compatibility forces otherwise.