Cryptography & TLS
Cryptography answers three security questions — confidentiality (nobody reads it), integrity (nobody tampers with it), and authenticity (it really is who it claims to be). A security interview does not test formulas; it tests whether you know which primitive solves which problem and why naive schemes break.
This topic collects the building blocks: symmetric and asymmetric ciphers, the key pair, the hybrid scheme (exactly what TLS uses), the digital certificate and the Certificate Authority (CA) that vouches for it, the TLS handshake itself, and a separate discipline — password storage. The main traps up front: encryption gets confused with hashing, "asymmetric" is assumed to be fast, and the fast hash MD5 is assumed to be fine for passwords. The full map is in the layers below.
Topic map
- Symmetric vs asymmetric encryption — one shared key versus a key pair, speed versus the key-delivery problem.
- Public and private keys — how the pair is linked, which key encrypts for confidentiality and which signs for authenticity.
- Hybrid encryption — why bulk data is encrypted symmetrically while asymmetry only protects the session key.
- Digital certificate — binding an identity to a public key and how a certificate differs from a bare key.
- Certificate Authority (CA) — who signs certificates and how, and the chain of trust up to a root
CA. - TLS handshake — how HTTPS negotiates ciphers, validates the certificate, and switches to a symmetric session key.
- Password storage — why
MD5/SHA-1are unacceptable and how a slow, salted hash works.
Common traps
| Mistake | Consequence |
|---|---|
| Confusing encryption (reversible) with hashing (irreversible) | Passwords get "encrypted" with a key, giving reversibility plus a single point of failure |
| Thinking asymmetric encryption is fast and fit for bulk data | In practice it is orders of magnitude slower and limited by key size |
| Believing a certificate contains the private key | The private key would leak when the certificate is shared; a certificate carries only the public key |
| Trusting any self-signed certificate | A man-in-the-middle slips through — only a CA signature confers trust |
Storing passwords as salted MD5/SHA-1 | A fast hash is brute-forced at billions per second even with a salt |
| Thinking all of HTTPS is encrypted asymmetrically | Asymmetry only derives the session key; the rest is symmetric |
Interview relevance
Crypto questions test whether you separate the primitives and understand their purpose, not whether you know the internals of AES. A candidate who says "you don't encrypt passwords, you salt and hash them with a slow Argon2, because encryption is reversible and keeps the key as a single point of failure" immediately stands out against "well, MD5 with a salt".
Typical checks:
- The difference between symmetry and asymmetry and why they are combined into a hybrid scheme in reality.
- The roles of the key pair — which key encrypts for confidentiality, which signs.
- What a certificate is, how it differs from a key, and where trust in it comes from.
- The flow of the TLS handshake and why traffic ends up encrypted symmetrically.
- How to store passwords correctly and why
MD5/SHA-1and "encrypting passwords" are wrong answers.
Common wrong answer: "store passwords securely by encrypting them with AES". That gives reversibility (leak the key, leak every password) and does not protect against compromise of the server itself; the right answer is an irreversible, slow, salted hash — bcrypt/scrypt/Argon2.