Cryptography basics
Every crypto question is really asking which of these you need. Confidentiality — nobody else can read it. Integrity — nobody changed it. Authentication — it's really from who it claims. Non-repudiation — they can't later deny sending it. Different primitives give different subsets, and mixing them up is the classic error.
| Symmetric | Asymmetric | |
|---|---|---|
| Keys | One shared secret for both encrypt and decrypt | A public/private pair |
| Speed | Fast — hardware accelerated (AES-NI) | ~1000× slower |
| Problem it has | Key distribution — how do you share the secret over an untrusted network? | Too slow for bulk data |
| Examples | AES-256-GCM, ChaCha20-Poly1305 | RSA, ECDSA, Ed25519, ECDH |
| Used for | Encrypting the actual traffic | Key exchange and signatures |
Asymmetric crypto solves key distribution but is far too slow for a video stream. Symmetric crypto is fast but can't bootstrap a shared secret over a hostile network. So TLS is a hybrid: use asymmetric operations once, during the handshake, to authenticate the server and agree a symmetric session key — then encrypt all the actual data symmetrically. Best of both, and the asymmetric cost is paid once per connection rather than per byte.
Hashing, MACs and signatures
| Primitive | Gives | Needs | Note |
|---|---|---|---|
| Hash (SHA-256) | Integrity only | Nothing | One-way, fixed output, avalanche effect. An attacker who can change the data can change the hash too — so a bare hash proves nothing about origin. |
| MAC / HMAC | Integrity + authentication | A shared secret | Both parties can produce it, so it gives no non-repudiation. |
| Digital signature | Integrity + authentication + non-repudiation | A private key | Sign with the private key, verify with the public. Only the holder could have produced it. |
| Password hash (bcrypt, Argon2) | Storage safety | A salt | Deliberately slow. Using SHA-256 for passwords is a vulnerability: it's fast, so it's cheap to brute-force. |
Diffie-Hellman and forward secrecy
The magic trick: two parties agree a shared secret over a public channel,
and an eavesdropper who saw EVERYTHING cannot compute it.
public: g, p
Alice picks secret a, sends g^a mod p
Bob picks secret b, sends g^b mod p
Alice computes (g^b)^a = g^ab
Bob computes (g^a)^b = g^ab ← same shared secret
Eve saw g, p, g^a, g^b — and computing a from g^a is the
discrete logarithm problem, which is computationally infeasible.
Plain DH gives no authentication — Eve can do DH separately with each
side and sit in the middle. That is why TLS SIGNS the exchange with a
certificate: DH gives secrecy, the certificate gives identity.With old RSA key exchange, the client encrypted the session key with the server's public key. So an attacker who recorded years of traffic and later stole the server's private key could decrypt all of it, retroactively.
With ephemeral Diffie-Hellman (ECDHE), a fresh key pair is generated per session and thrown away afterwards. The long-term certificate key only signs the exchange; it never encrypts the session key. So stealing it tomorrow lets an attacker impersonate the server going forward, but does not decrypt anything recorded in the past. That's why TLS 1.3 removed static RSA key exchange entirely and mandates ephemeral exchange.