5 exercises — choose the best-structured answer to common cryptography interview questions. Focus on encryption primitives, key lifecycle, TLS, and engineering best practices.
Structure for cryptography interview answers
Name the primitive and why: AES-256-GCM vs RSA-OAEP — explain the security property
Quantify the risk: bits of security, algorithm agility, deprecation timeline
Separate protocol from primitive: TLS 1.3 uses ECDHE for key exchange, AES for bulk encryption
0 / 5 completed
1 / 5
The interviewer asks: "Explain the difference between symmetric and asymmetric encryption, and tell me when you would use each in a real system." Which answer best demonstrates practical cryptography knowledge?
Option B is strongest: it gives concrete algorithms with bit-security levels, a performance comparison (~1,000× difference), specific use cases for each, explains why key distribution is the core problem asymmetric solves, and shows hybrid cryptography in action via TLS 1.3 (ECDHE + AES-256-GCM). The rule-of-thumb closing is memorable and shows architectural thinking. Option C's "at rest vs. in transit" framing is a common oversimplification — symmetric encryption is used heavily in TLS (in transit) for bulk data. Symmetric vs. asymmetric: algorithms + security levels → performance dimension → use cases for each → key distribution problem → hybrid in practice (TLS example) → rule of thumb.
2 / 5
The interviewer asks: "Walk me through the TLS 1.3 handshake — what happens before the first byte of application data is sent?" Choose the most accurate technical description.
Option C is strongest overall, covering the 1-RTT achievement, key_share pre-population (the mechanism that eliminates a round trip), encrypted server certificate and Finished in one flight, HKDF for key derivation, and the important fact that RSA key exchange was removed (it lacked forward secrecy — a common interview follow-up). Option B is more technically detailed but slightly less accurate on the exact flight structure. Option D is conceptually correct but too abstract — doesn't name the specific algorithms (ECDHE, HKDF). TLS 1.3 handshake: 1-RTT via key_share pre-population → encrypted server certificate in same flight → HKDF for key derivation → RSA key exchange removed (forward secrecy) → 0-RTT session resumption mention.
3 / 5
The interviewer asks: "How should encryption keys be managed in a production cloud system — covering generation, storage, rotation, and revocation?" Which answer demonstrates complete key lifecycle management?
Option A is strongest: it covers all four lifecycle stages (generation, storage, rotation, revocation) with implementation specifics — CSPRNG in HSM for generation, envelope encryption hierarchy (master key → DEK → data), rotation semantics (re-encrypt + retain old keys until migration complete), revocation semantics (re-encryption required for symmetric keys), audit logging with alerting on anomalies, and separation of duties. Option C describes envelope encryption correctly but misses revocation, separation of duties, and audit alerting. Option D focuses on API keys and temporary credentials — valid advice but incomplete as a key lifecycle framework. Key lifecycle: CSPRNG generation in HSM → envelope encryption hierarchy → rotation semantics → revocation and re-encryption requirement → audit trail with anomaly alerting → separation of duties.
4 / 5
The interviewer asks: "What is cryptographic agility and why does it matter for a system built today?" Choose the answer that best demonstrates strategic cryptography thinking.
Option D is strongest: it explains why agility matters specifically today (NIST post-quantum standards finalised, "harvest now, decrypt later" threat), grounds it in algorithm deprecation history (MD5, SHA-1 breakage timeline), gives the implementation pattern (abstract interface + algorithm identifier stored alongside ciphertext + versioned key IDs), and names the practical minimum for a migration path without flag-day cutover. Options A and C describe the concept correctly but don't explain the urgency (post-quantum) or the implementation pattern completely. Cryptographic agility: post-quantum urgency → deprecation history → abstract interface implementation → self-describing ciphertexts + algorithm identifiers → versioned keys → incremental migration without flag day.
5 / 5
The interviewer asks: "How would you design a secrets management system for a microservices platform running on Kubernetes?" Which answer covers the key design requirements?
Option B is strongest: it explains why native Kubernetes Secrets are insufficient (base64 ≠ encryption, etcd visibility), provides the Vault integration mechanism (sidecar injection, Kubernetes Auth), introduces dynamic secrets (short-lived credentials per service — no long-lived shared passwords), covers rotation with graceful handling, encryption at rest, audit logging with alerting, and least-privilege policy design. Options C and D describe valid approaches (External Secrets Operator and Sealed Secrets are both production-grade) but don't address dynamic secrets or audit logging. K8s secrets management: native Secrets limitation → dedicated secrets store (Vault) → Kubernetes Auth Method → dynamic short-lived credentials → rotation handling → encryption at rest → audit logging → least-privilege policies.