Cryptography and Encryption Fundamentals Questions

Comprehensive understanding of modern cryptography and encryption principles used to build secure systems. Candidates should be able to explain the differences between symmetric and asymmetric encryption, appropriate use cases for each, and common algorithms by full name such as Advanced Encryption Standard and Data Encryption Standard for symmetric ciphers and Rivest Shamir Adleman and elliptic curve based algorithms such as Elliptic Curve Digital Signature Algorithm and Elliptic Curve Diffie Hellman for public key operations. Describe hybrid encryption patterns in which asymmetric cryptography is used to protect a symmetric session key, and discuss block cipher modes of operation including cipher block chaining and authenticated encryption modes such as Galois Counter Mode, as well as the role of initialization vectors and nonces. Cover hash functions and integrity checks with properties such as collision resistance and preimage resistance, message authentication codes, authenticated encryption, and digital signatures for authentication and nonrepudiation. Include high level Public Key Infrastructure concepts including certificates and certificate authorities and how certificates are used to establish trust, together with foundational Transport Layer Security and Secure Sockets Layer principles without requiring deep certificate lifecycle management knowledge. Emphasize key management and operational concerns including secure key generation, secure storage, rotation and compromise handling, randomness and entropy sources, recommended key lengths and algorithm lifecycle considerations, and performance and scalability trade offs. Be prepared to discuss common implementation pitfalls and failures such as weak key sizes, poor random number generation, improper key reuse, and lack of authenticated encryption, plus threat models and practical applications including encrypting data at rest and in transit, secure channels, and signing and verification. Avoid deep mathematical proofs unless specifically requested, but be ready to reason about practical trade offs, algorithm selection, and secure implementation patterns.

HardTechnical

52 practiced

A closed-source HSM-backed crypto library from a vendor is suspected of using poor entropy sources. As the security analyst, outline how you would validate the randomness, what tests and evidence you would collect (entropy estimation, statistical tests), interim mitigations to reduce risk, and long-term vendor-evaluation criteria.

Sample Answer

**Approach Summary**As the InfoSec analyst I’d perform an evidence-driven validation of the RNG, apply immediate mitigations to limit exposure, and define vendor-evaluation criteria to resolve risk long-term.

**Validation & Evidence to Collect**- Collect raw RNG outputs (multiple gigabytes if possible) with timestamps and context (calls per process, thread, operation). - Gather HSM logs, RNG self-test/health reports, firmware versions, and configuration (entropy sources, seeds, reseed intervals). - Document HSM model, firmware, FIPS/CC certifications, vendor RNG spec, and API usage (which RNG function used). - Evidence chain: capture network traffic and key generation requests to map real-world usage.

**Entropy Estimation & Statistical Tests**- Entropy estimation: run NIST SP 800-90B min-entropy estimators, perform collision tests, and conditional min-entropy modeling (identify biases, state recovery risk). - Statistical suites: NIST SP 800-22 / STS, Dieharder, TestU01 (SmallCrush/Crush/BigCrush), ENT (entropy, chi-square, serial correlation), autocorrelation and spectral analysis. - Additional checks: FIPS 140-3 / AIS 31 online tests, chi-square/time-series for timing-based leaks, Markov and compression tests to detect structure. - Record test parameters, sample sizes, and p-values; preserve seed material and test scripts as reproducible evidence.

**Interim Mitigations**- Immediately: restrict production use of the vendor RNG for new key material; isolate and quarantine sensitive operations. - Augment entropy: feed proven external entropy (e.g., NTP-less sources, TPM/HSM internal AND external entropy mixing via XOR or HKDF) at key generation time. - Rotate keys/credentials generated with suspect RNG, prioritize high-value keys. - Harden logging/alerting: enable HSM health alarms, increase audit frequency, and monitor RNG failure counters. - Apply compensating crypto: use deterministic key-wrapping with hardware-protected keys and multi-party generation if feasible.

**Long-term Vendor Evaluation Criteria**- Transparency: ability to review RNG design, source code or whitebox analysis, reproducible test vectors. - Certification & testing: current FIPS 140-3 level, third-party entropy audits, independent cryptanalysis. - Operational controls: documented entropy sources, reseed policy (intervals, sources), safe failure behavior, and robust health tests. - Support & SLAs: patch cadence, incident response, contractual right to audit and to receive forensic data. - Alternatives: consider vendors with open RNG designs or HSMs supporting customer-supplied entropy, or implement multi-vendor key ceremonies.

**Reasoning**Combining statistical testing with system-level evidence and operational controls reveals whether randomness failure is theoretical or exploitable in practice. Interim controls reduce immediate risk while vendor-level transparency and certification address root cause.

EasyTechnical

62 practiced

State recommended key length guidance for common algorithms: AES (symmetric), RSA (classical public-key), and elliptic curve algorithms (ECDSA/ECDH). Explain why key length matters and what operational considerations (performance, lifespan, algorithm migration) influence your choice of length.

HardTechnical

63 practiced

Discuss common side-channel attacks (timing attacks, cache attacks, power analysis) relevant to cryptographic operations in cloud environments. For each, describe detection techniques, mitigation strategies for deployed libraries (constant-time implementations, blinding, hardware isolation), and pragmatically how you'd prioritize fixes in production.

Sample Answer

**Situation & scope (brief)** As an InfoSec Analyst I focus on cryptographic side-channels in cloud tenants: timing, cache, and power/EM (for co‑located hardware or managed HSMs). I detect them, recommend library fixes, and prioritize production remediations.

**Timing attacks** - Detection: monitor anomalous response-time distributions per endpoint, use statistical tests (t‑tests, KS) on API latencies; instrument crypto libraries with high-resolution timers in staging. - Mitigation: deploy constant-time crypto (libs vetted for constant-time), avoid secret-dependent branches, use constant-time compare functions. For deployed libraries, backport patches or replace with maintained implementations (e.g., libsodium, BoringSSL). - Priority: high for authentication, token signing, key-derivation endpoints.

**Cache attacks (Prime+Probe, Flush+Reload)** - Detection: unusual cache-miss patterns from co‑tenant VMs (perf counters), elevated L3 evictions, IDS rules for frequent context-switch patterns. Behavioral alerts from SIEM correlating CPU affinity changes. - Mitigation: use constant-time algorithms, avoid secret-dependent memory access patterns, enable process/VM isolation (dedicated cores, pinning), use hardware features (Intel MKTME, cache allocation) or migrate to separate tenancy/HSM. Update libraries to constant-memory-access versions. - Priority: critical where multi-tenant compute handles keys (KMS, signing services); isolate or patch before wide rollout.

**Power/EM analysis** - Detection: unlikely from remote cloud tenant but monitor for co‑located hardware access (tenancy logs), and abnormal peripheral/management plane activity; in private DC, use side-channel sensors. - Mitigation: use HSMs, blinding (RSA blinding, scalar blinding), noise injection, constant-power modes; ensure cloud-managed HSMs are used for high-value keys. - Priority: highest for keys in hardware; migrate keys to HSM and apply blinding.

**Pragmatic prioritization & rollout** 1. Inventory critical crypto endpoints and key locations. 2. Patch/replace vulnerable libs for authentication and signing first. 3. Short-term: isolate affected services (dedicated hosts, CPU pinning), enable HSMs. 4. Medium-term: recompile with constant-time libs, add blinding. 5. Long-term: add telemetry (perf counters, latency distributions) into SIEM and include side-channel tests in CI.

I would communicate risk and planned mitigations to ops, schedule emergency patches for auth/key services, and track remediation through ticketing.

HardTechnical

58 practiced

You are auditing an application that uses AES-GCM but concatenates ciphertexts produced over time with the same key and a simple 32-bit integer nonce that rolls over. Explain the risks, how to demonstrate the exploitability of nonce reuse, and propose a safe remediation strategy suitable for a high-throughput service.

Sample Answer

**Risks (what’s wrong and why it matters)**

- AES‑GCM requires a unique nonce per key. Reusing a nonce (IV) with the same key causes keystream reuse: C1 = P1 ⊕ S, C2 = P2 ⊕ S ⇒ C1 ⊕ C2 = P1 ⊕ P2, enabling plaintext recovery when one plaintext is known/guessable.- Reuse also breaks authenticity: GCM’s GHASH tag can be forged more easily under nonce reuse, enabling tampering.- A 32‑bit rolling nonce will inevitably collide at high throughput → catastrophic confidentiality and integrity failure.

**How to demonstrate exploitability (practical proof-of-concept)**

- Gather two ciphertexts C1||T1 and C2||T2 that used same nonce/key (concatenation makes detection easy).- Compute X = C1 ⊕ C2; if attacker knows or can guess parts of P1 (headers, JSON structure), derive P2 bytes from X.- Write a short script to: - Read file of concatenated records, parse fixed-size tag and length, find equal IVs or infer reuse by position. - For a known plaintext header (e.g., "HTTP/1.1"), XOR to recover the other plaintext.- Demonstrate forgery: construct modified ciphertext C2' = C2 ⊕ (P2 ⊕ P2') and submit with original tag; often detected but with repeated nonces many forgeries succeed—include in PoC to show integrity risk.

**Safe remediation strategy for high‑throughput service**

- Stop using 32‑bit nonce. Adopt 96‑bit nonces (recommended) and ensure uniqueness per key.- Prefer deterministic unique nonces: combine a per‑connection 32/64‑bit counter with a 64/32‑bit random per‑key prefix (nonce = prefix || counter). Store counter atomically; persist across restarts or use high‑availability coord.- If atomic counters are a bottleneck, use per-worker unique prefix (derived from secure RNG or HKDF(key, worker_id)) plus local counter to avoid global locking.- Consider AES‑GCM‑SIV or ChaCha20‑Poly1305 (Deterministic AEAD) which resist nonce misuse.- Implement key rotation and limits: enforce maximum plaintext per key and rotate keys before nonce space exhaustion; log metrics into SIEM and alert on reuse or high counter utilization.- Add associated-data sequence numbers and replay protection; include nonce in audited logs.- Test: deploy in staging, run load tests to verify throughput and that no counter collisions occur, then deploy with monitoring.

This approach restores confidentiality and integrity while remaining practical for high throughput.

HardSystem Design

51 practiced

Design a secure audit logging architecture for cryptographic operations: key access, envelope encryption/decryption, key rotation, and admin operations. Ensure the audit trail preserves necessary forensic detail while protecting sensitive key material, supports tamper-evidence, and meets compliance requirements for retention and access control.

Sample Answer

**Clarify goals & constraints**- Must capture key access, envelope encrypt/decrypt, key rotation, admin ops.- Preserve forensic detail (who, what, when, where, why, context) while never logging secret key material.- Provide tamper-evidence, retention & RBAC for compliance (e.g., SOX, PCI-DSS), integrate with SIEM.

**High-level architecture**- Clients/apps -> KMS (HSM-backed) + Audit Agent -> Immut. Audit Store -> SIEM/Forensic DB -> Long-term WORM archive- HSM/KMS enforces no-key-export; Audit Agent runs inside KMS boundary to emit events.

**Core components & responsibilities**- KMS/HSM: enforce crypto ops; emit structured audit events (see schema).- Audit Agent: signs events with KMS audit-signing key (stored in HSM), strips/never emits secret material, attaches key_id, key_version, envelope_id, operation_type, input_hash.- Immutable Audit Store: append-only log (write-once S3 with Object Lock in governance/compliance mode or dedicated ledger DB). Each record includes signature and chain-hash.- Timestamping & notarization: sync to NTP+TLS; periodically anchor batch log hash to external timestamping service or ledger (blockchain or public RFC 3161 timestamping) for stronger tamper-evidence.- SIEM/Forensic DB: indexed, role-restricted views; alerting rules and case management.- WORM archive: for required retention periods.

**Event schema (example fields)**- timestamp (RFC3339), event_id, actor_id (user/service), actor_auth_method, operation (ENCRYPT/DECRYPT/KEY_ROTATE/ADMIN), key_id, key_version, envelope_id, input_hash (SHA-256 of plaintext or ciphertext where allowed), output_meta (size, algorithm), purpose, source_ip, request_id, signature, prev_chain_hash

Note: input_hash does not reveal plaintext; never log plaintext/key_material/kek.

**Tamper-evidence & integrity**- Each event signed by HSM audit-signing key; chain-hash links records:

text

chain_hash = SHA256(prev_chain_hash || event_serialized)

- Periodic anchoring: publish root hash to external immutable service; store RFC3161 timestamp.

**Access control & separation of duties**- RBAC + MFA for log access; SIEM analysts get indexed metadata; forensic team can request sealed access to full logs via ticketing/Audit Board.- Dual-control for export of raw audit data; all accesses to logs themselves are audited.

**Retention & compliance**- Retention policy per regulation; immutable WORM storage; automated lifecycle: hot -> cold -> WORM -> delete only via legal hold.- Regular retention audits; manifest checksums and anchor proofs for each retention epoch.

**Forensics & alerting**- Real-time streaming of critical events to SIEM (key access, failed decrypts, rotation failures, admin changes).- Correlate with identity provider logs, network logs, and host logs for context.- Playbooks: immediate key disable, revocation, forensic capture of HSM console, legal hold.

**Risk mitigations / threats**- Insider threat: split roles, HSM-auth enforced signing, separate audit-signing key, keystore access controls.- Log tampering: chain-hash + external anchoring + WORM.- Sensitive leakage: strict schema, hashing vs storing data, redaction, automated PII/key detectors.

**Why this design**- Preserves necessary forensic detail while never exposing secrets.- Multiple layers of tamper-evidence (signatures, chaining, external anchors, WORM) satisfy strong audit integrity requirements.- Integrates with SIEM and operational workflows for timely detection and forensic readiness.

Unlock Full Question Bank

Get access to hundreds of Cryptography and Encryption Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.