Threat Modeling for Cryptographic Systems Questions

Covers systematic identification of threats and adversary models specifically for systems that use cryptography. Topics include defining attacker capabilities such as passive eavesdropping, active tampering, insider threats and future threats like quantum attacks; deciding where cryptography is appropriate and where it is not; documenting trust assumptions and failure modes; tracing data flows to identify exposure points and metadata leakage; analyzing implementation risks such as weak random number generation and side channels; designing layered defenses, mitigation strategies, recovery and incident response procedures; and communicating clear recommendations to technical and non technical stakeholders.

HardTechnical

54 practiced

A widely-used crypto library dependency has a newly disclosed CVE enabling chosen-ciphertext attacks in certain usage modes. As lead cryptographer create a prioritized mitigation and rollout plan: immediate compensating controls, patching and testing strategy, key-rotation decisions, rollback plan, communication to downstream teams/customers, and longer-term supplier risk-reduction measures.

Sample Answer

**Situation & priorities (first 24–72 hrs)**I classify risk: CVE enables chosen-ciphertext attacks in certain modes — high for systems using hybrid/KEM+AE or RSA-OAEP-like constructs and for protocols accepting attacker-controlled ciphertext. Immediate goal: stop exploitation, preserve confidentiality/integrity, and maintain availability.

**Immediate compensating controls**- Block or disable vulnerable modes (e.g., deactivate CCA-unsafe APIs) via feature flags.- Enforce strict input validation and reject unauthenticated ciphertexts.- Add network WAF rules / rate-limits to detect abnormal ciphertext patterns.- Increase monitoring: log decryption failures, anomaly detection, and add HSM-backed enforcement where possible.

**Patching & testing strategy**- Prioritize vendor patch when available; obtain changelog and CVE fix details.- Create test matrix: unit tests for decryption semantics, fuzzing for malformed ciphertexts, regression tests against known exploit patterns, and interoperability tests for clients.- Stage rollout: dev → canary (small % of traffic) → regional → global with automated health checks and metrics (error rates, latency, cryptographic failure rates).

**Key-rotation decision**- If vulnerability allows plaintext recovery or key-recovery scenarios, rotate keys immediately for affected schemes; if exploit only yields oracle info without key exposure, rotate only after proof-of-fix but still consider rotation for high-value keys.- Use HSMs/segregated KMS policies; plan zero-downtime rotation with dual-read (old/new) where protocol allows and retire old keys after safe-interval informed by forensic analysis.

**Rollback plan**- Keep previous library binary and config that disables vulnerable modes; rollback automated via orchestration if canary shows regressions.- If rollback reintroduces vulnerability, revert to compensating-configs (disable modes) while waiting for mitigated patch.

**Communication**- Immediate internal alert to engineering, ops, legal, and product with clear actions and owner(s).- External: coordinated advisory to customers and downstream teams including CVE ID, affected modes, mitigations, expected timelines, and recommended actions (disable modes, rotate keys).- Provide FAQs, patch notes, and monitoring dashboards; schedule follow-up once patched.

**Longer-term supplier risk reduction**- Require semantic patch descriptions and reproducible tests from vendors.- Enforce SCA policies: pinned versions, SBOMs, and contract SLA for crypto fixes.- Adopt diverse/alternative vetted libraries, cryptographic abstraction layers to switch implementations, and periodic third-party crypto audits and fuzzing campaigns.

MediumTechnical

53 practiced

Your VPN product uses classical ECDH for key exchange. Design an attacker model and a practical migration plan to integrate a post-quantum KEM while maintaining interoperability and minimizing downtime. Address hybrid-mode design, handshake negotiation, performance impacts, client/server rollout order, and testing strategy for downgrade protections.

Sample Answer

**Threat model (attacker capabilities)** - Adversary with large-scale passive collection now and a future quantum adversary able to break classical ECDH later (harvest-now-decrypt-later). - Active MITM able to attempt handshake manipulation, injection, or downgrade during migration window. - Rogue client/server or compromised key material.

**Migration goals** - Preserve interoperability with existing clients/servers. - Provide immediate protection against harvest-now-decrypt-later via hybrid key agreement. - Minimize downtime and allow gradual roll-out/rollback.

**Hybrid-mode design** - Use an authenticated hybrid KEX: perform classical ECDH (P-256/P-384) AND a post-quantum KEM (e.g., Kyber512/768) and derive the shared secret by HKDF over both contributions plus transcript binding and certificates. - Transcript includes signed ServerKeyExchange and ClientKeyExchange and a clear "hybrid" indicator to prevent ambiguity. - Authenticate via existing certificate system; server certs continue to sign ECDH and a server-side PQ KEM encapsulation or include PQ public key in extension (short-lived PQ keys rotated).

**Handshake negotiation & downgrade protection** - Introduce new TLS-like extensions/cipher-suite identifiers: e.g., TLS_ECDHE_PQ_KYBER_WITH_AESGCM. - Clients advertise supported modes ordered by preference; servers select highest mutually supported. - Anti-downgrade: server includes an "anti-downgrade" sentinel in the signed transcript if it sees a client offering PQ-capable modes; clients reject connections where server unexpectedly chooses non-hybrid when PQ support was offered. - Strict mode configurable: operators can enforce hybrid-only, otherwise fall back with explicit logging and alerts.

**Performance considerations** - KEM encapsulation runs in parallel with ECDH to minimize latency; schedule crypto on separate threads or use async IO. - Choose PQ parameter sets balancing security/perf (Kyber512 for low-latency, Kyber768 for higher security). - Measure handshake CPU, memory, and packet-size increase (KEM ciphertexts) — optimize MTU and fragmentation policy. - Provide optional session resumption keyed to hybrid secret to avoid repeated PQ operations.

**Rollout plan (minimize downtime, order)** 1. Implement server-side support for hybrid suites and negotiation; default still accepts classical ECDH. 2. Early-beta clients (internal/users) ship with PQ-capable offers. 3. Gradual server fleet upgrade (canary → 10% → 50% → all) while monitoring metrics. 4. Once majority servers support hybrid, push client config to prefer hybrid; enable strict mode for high-security tenants. 5. Rotate PQ keys frequently; deprecate pure-ECDH after N months with broad telemetry showing compatibility.

**Testing strategy & downgrade validation** - Build comprehensive interop matrix: client versions × server versions × cipher-suite combos. - Automated fuzzing of handshake parser, extensions, and transcript signing. - Replay/record-and-replay tests to detect harvest-now-decrypt vulnerability. - Simulate active MITM downgrades: assert clients detect unexpected suite selection and reject when in strict or when server advertised PQ support earlier. - Performance/latency benchmarks and resource exhaustion tests. - Crypto review: formal verification of key derivation (transcript binding, KDF inputs) and threat-model-driven crypto design review.

**Roll-back and monitoring** - Telemetry for failed handshakes, chosen suites, latency regressions, and PQ key errors. - Safe rollback path: servers can disable PQ extension quickly via config management; clients keep backwards capability for phased rollback.

This plan provides immediate post-quantum resistance against record collection while preserving interoperability, minimizes downtime via parallelizable operations and staged rollout, and defends against downgrade/MITM via signed transcript indicators and strict negotiation rules.

EasyTechnical

41 practiced

Describe common side-channel classes (timing, cache, power, electromagnetic, branch-prediction) that affect cryptographic implementations. For each class provide one simple mitigation technique and give one realistic scenario where that mitigation could be insufficient.

Sample Answer

**Overview**I’ll describe each side‑channel class, give one simple mitigation, and a realistic scenario where that mitigation can fail.

**Timing**- What: Secret-dependent execution time (e.g., variable-time modular exponentiation).- Mitigation: Use constant-time algorithms and avoid secret-dependent branches.- Insufficient when: Microarchitectural features (out-of-order execution, instruction-level timing) leak residual differences, or network jitter hides small fixes but remote attackers exploit high-resolution timing to recover secrets.

**Cache**- What: Secrets inferred from cache hits/misses (Prime+Probe, Flush+Reload).- Mitigation: Use cache‑safe implementations (avoid secret-dependent memory accesses; prefetch or use constant-index tables).- Insufficient when: Shared environments (cloud VMs) allow cross‑VM attacks; prefetch patterns still leak via set-conflict behavior.

**Power**- What: Power consumption correlates with processed data (DPA/SPA).- Mitigation: Add noise or use masking (randomize intermediate values).- Insufficient when: High-SNR equipment and multi-trace analysis remove noise; improper masking (single-bit masks) allows higher-order attacks.

**Electromagnetic (EM)**- What: EM emissions carry correlated computation traces.- Mitigation: Shielding and filtering; random delays.- Insufficient when: Skilled attackers use near-field probes and signal-processing to separate emission components; shielding gaps or supply coupling leak signals.

**Branch‑prediction**- What: Speculative execution and misprediction side effects reveal secrets.- Mitigation: Use speculation-safe code (avoid secret-dependent branches) or serializing instructions.- Insufficient when: Hardware speculative effects (spectre-style) leak via microarchitectural state that software cannot fully control; mitigations degrade performance and may be bypassed on older CPUs.

I would in interviews emphasize layered defenses, rigorous testing (fault/instrumented lab attacks), and threat modelling for deployment context.

EasyTechnical

40 practiced

You are designing a threat model for a new end-to-end encrypted messaging application. Identify and categorize attacker capabilities relevant to cryptographic systems: include passive eavesdroppers, active network attackers, compromised-insiders, constrained/resource-limited adversaries, and advanced future adversaries (e.g., quantum-capable). For each capability explain what actions the adversary can perform, typical indicators, and why capability-based categorization matters for mitigation choices.

Sample Answer

**Overview — why capability-based categorization matters**Categorizing attackers by capability (what they can do vs. intent) guides cryptographic choices: algorithm strength, key management, forward secrecy, authentication, and post‑quantum planning. Mitigations map to capabilities rather than generic “attacker” labels.

**1) Passive eavesdropper**- Actions: Observe ciphertext, metadata (timing, sizes), traffic analysis; no packet modification.- Indicators: Unusual packet sniffing signatures, mirror ports, high-volume passive taps.- Mitigations: Strong IND‑CPA/CCA2 schemes, padding and cover traffic, metadata minimization, perfect forward secrecy (PFS) reduces value of recorded ciphertext.

**2) Active network attacker (MITM)**- Actions: Modify, drop, inject, replay packets; downgrade protocols; present forged keys/certificates.- Indicators: TLS alerts, unexpected handshakes, certificate changes, sequence anomalies.- Mitigations: Authenticated key exchange (e.g., SIGMA/IKE3), mutual auth, certificate pinning/TOFU, MACs, anti‑replay, robust handshake validation.

**3) Compromised insider**- Actions: Access keys, key material, user devices, servers; exfiltrate plaintext or signing keys.- Indicators: anomalous accesses, key usage from unusual hosts, privilege escalation logs.- Mitigations: Hardware-backed keys (HSM/TPM), threshold cryptography, key rotation, minimum privilege, secure enclaves, audit/logging, end‑to‑end encryption where server lacks plaintext.

**4) Constrained/resource-limited adversary**- Actions: Limited compute for bruteforce, short-lived active attacks, low-bandwidth interception.- Indicators: Low-rate probes, off‑hours scanning.- Mitigations: Increase computational cost (scrypt/Argon2 for KDFs where appropriate), rate limiting, adaptive cryptographic parameters.

**5) Advanced/future adversary (quantum-capable)**- Actions: Break asymmetric primitives (RSA, ECC), run Grover/ Shor attacks, large-scale offline decryption later.- Indicators: acquisition of quantum capability; speculative.- Mitigations: Hybrid key exchange combining classical and post‑quantum KEMs, crypto agility, longer symmetric keys, forward secrecy, phased migration plans.

Conclude: map each adversary to specific guarantees required (confidentiality, integrity, authenticity, forward secrecy) and choose layered defenses accordingly.

EasyTechnical

40 practiced

Explain 'crypto-agility'. Give two concrete design choices (one protocol-level and one implementation-level) that enable algorithm migration with minimal disruption, and describe how you would test a migration path end-to-end before rolling it out to production.

Unlock Full Question Bank

Get access to hundreds of Threat Modeling for Cryptographic Systems interview questions and detailed answers.

Join thousands of developers preparing for their dream job.