Comprehensive knowledge of key management and key derivation functions, including how to derive cryptographic keys from passwords and from random entropy using algorithms such as PBKDF2, scrypt, bcrypt, and Argon2, and how to choose and tune parameters like salt, work factor, memory cost, and time cost. Understanding of secure key generation practices, entropy sources, and techniques for protecting key material in memory and at rest including use of hardware security modules, key wrapping, and encrypted key stores. Familiarity with key lifecycle management including generation, storage, access control, rotation policies, secure deletion, archival, and disposal, as well as key escrow and key recovery considerations. Experience assessing threats and mitigations such as weak KDF selection, brute force and offline attacks, side channel exposures, accidental leakage, and compromise response procedures. Knowledge of multi party and distributed system concerns including key agreement protocols, threshold cryptography, distributed key management, secure distribution and provisioning, auditing, and operational best practices for integrating key management into applications and infrastructure.
HardTechnical
49 practiced
Design a deterministic derivation scheme to produce per-record encryption keys from a master key such that compromise of some derived keys does not enable recovery of other derived keys or the master key. Specify algorithms or KDFs to use, domain separation, inclusion of record-specific metadata, and analyze forward/selected-key compromise resistance.
Sample Answer
**Answer (cryptographer perspective)**Situation and goal: derive a unique deterministic per-record encryption key K_rec from a single master Key_M such that compromise of some K_rec values does not recover Key_M or other K_rec (key-isolation, selected-key compromise resistance); support domain separation and include record metadata.Design (algorithm + parameters)- Use HKDF with a secure hash (HKDF-SHA256) per RFC 5869.- Master key = Key_M (entropy >= 256 bits). Use HKDF-Extract once at system bootstrap with a global salt (optional) to yield PRK.- For each record, derive:
Plain-English: info is a domain-separated context: fixed label "rec-key-v1" ensures protocol/version separation; NUL separators avoid ambiguity; include record_id (unique), record_version/timestamp, and a hash (e.g., SHA256) of any variable metadata.Recommendations- L = 32 bytes (256-bit symmetric key), use AES-256-GCM or ChaCha20-Poly1305.- system_salt: random per-deployment and stored/rotated under KMS.- Use explicit versioned label to allow algorithm upgrades.Security analysis- Key isolation: HKDF is a pseudorandom function family; without Key_M or PRK an attacker cannot compute other K_rec from observed ones.- Master secrecy: HKDF-Extract/Expand is one-way; compromise of K_rec does not reveal PRK or Key_M (preimage resistance of HMAC/SHA256).- Selected-key compromise resistance: knowing multiple K_rec values gives no advantage recovering PRK/Key_M or other K_rec beyond brute force.- Forward security caveat: this scheme is not forward-secure across Key_M compromise (if Key_M is later compromised, all past/future K_rec are derivable). For forward secrecy, combine with forward-secure key rotation: periodically rotate Key_M via an evolving KDF tree (e.g., use a one-way ratchet to derive new Key_M_i and delete old Key_M).- Metadata inclusion prevents key reuse across records with same ID in different contexts and protects against chosen-record collisions.Operational notes- Protect PRK/Key_M in HSM/KMS; limit derived-key exposure; log and rotate system_salt and Key_M per policy.- Test with Wycheproof/cryptographic library validations.This provides deterministic, domain-separated, metadata-bound per-record keys with strong selected-key compromise resistance; add rotation/ratchet if forward secrecy is required.
EasyTechnical
63 practiced
What is key wrapping and how does it differ from encrypting arbitrary data? Describe common key wrapping algorithms (e.g., AES-KW / RFC 3394, AES-GCM wrapping) and explain why integrity/authentication and atomic unwrap semantics are important in key management systems.
Sample Answer
**Answer (concise, role: Cryptographer)****What key wrapping is vs arbitrary-data encryption**- Key wrapping is a specialized primitive for protecting cryptographic keys: confidentiality plus strong integrity/authentication and well-defined unwrap semantics. Unlike encrypting arbitrary data with AES-CBC or AES-GCM, key wrapping assumes fixed-length key material, and the API/semantics must prevent subtle misuse (e.g., partial decryption, key substitution, replay).**Common algorithms**- AES-KW (RFC 3394): deterministic block-based wrap using AES in a Feistel-like construction with an integrity check embedded (initial value). Designed specifically for key-encryption; concise, fast, but lacks explicit AEAD tag—integrity comes from the construction and IV check.- AES-KWP (RFC 5649): extension to support arbitrary lengths and explicit length field.- AES-GCM wrapping: uses AES-GCM (AEAD) to wrap keys—produces ciphertext + tag, supports AAD for metadata (key IDs, usage policies). Simpler to reason about because of standard AEAD security.**Why integrity/authentication matter & atomic unwrap**- Keys are high-value: a single-bit flip can change a key to another valid key yielding silent compromise. Integrity prevents tampering and substitution.- Atomic unwrap semantics: unwrap must be all-or-nothing. Partial output or disclosure on integrity failure leads to key-corruption or oracle-style leaks. Systems must reject on any integrity failure and avoid side-channels (timing, error messages).- Practical concerns: include AAD (usage, key-ID), replay protection, and clear failure handling in KMS APIs.I would choose AES-GCM-wrapped AEAD where possible for clarity; use RFC 3394 where compatibility/legacy is required, and always enforce atomic, authenticated unwrap and strict metadata binding.
MediumSystem Design
56 practiced
Design a scheme using HKDF to derive multiple independent keys (encryption key, MAC key, IV/nonce seed, and key-encryption-key) from a single per-tenant master secret for a multi-tenant SaaS environment. Specify use of extract and expand, salts, info/context strings, label separation, and how you would handle per-tenant rotation and forward/backward compatibility.
Sample Answer
**Clarify goal & primitives**Derive independent cryptographic materials (enc key, MAC key, IV/nonce seed, KEK) from one per-tenant master secret using HKDF (HMAC-SHA256). Use HKDF-Extract to normalize entropy and HKDF-Expand with distinct labeled contexts to get independent outputs.**Derivation scheme**- Inputs: - MSK_t = tenant master secret (high-entropy, stored in KMS/HSM) - salt_t,v = per-tenant, per-rotation random salt (v = version) - hkdf = HKDF(HMAC-SHA256)- Step 1 (extract): - PRK_t,v = HKDF-Extract(salt_t,v, MSK_t) - Use non-empty, random salt to protect against low-entropy MSK and to enable rotations.- Step 2 (expand) — produce each key with separate labeled info: - EncKey = HKDF-Expand(PRK_t,v, info = "tenant|v|enc|purpose|AES-GCM-256", L=32) - MACKey = HKDF-Expand(PRK_t,v, info = "tenant|v|mac|purpose|HMAC-SHA256", L=32) - NonceSeed = HKDF-Expand(PRK_t,v, info = "tenant|v|nonce-seed", L=16) - KEK = HKDF-Expand(PRK_t,v, info = "tenant|v|kek|wrap|AES-KW-256", L=32)- Info strings include tenant identifier, version, and explicit label; treat each info as context separation to guarantee independence (different info => independent HKDF outputs).**Nonce/IV handling**- Derive NonceSeed once per-tenant-version, then generate per-object nonces by combining NonceSeed with object-specific nonce counter or unique object ID using a KDF or XOR, or use AES-CTR on seed to produce per-object nonces. Ensure AEAD requirement: never reuse nonce for same key.**Rotation & versioning**- Rotation = create new salt_t,v+1 and optionally new MSK_t'. Compute new PRK and new derived keys with v+1 in info.- Backward compatibility: - Keep prior salts and PRKs (or ability to re-derive using archived salt + MSK) to decrypt old data until re-encryption. - Use KEK-based envelope encryption: data encrypted with DEK (derived EncKey); DEK is wrapped with KEK and stored; to rotate without immediate re-encryption of ciphertexts, re-wrap DEKs under new KEK (rewrap) or keep old KEKs for decryption.- Forward secrecy-like behavior: if MSK rotated with destruction of old MSK, maintain ability to rewrap existing DEKs by having KEK escrow or HSM policy; otherwise, plan re-encryption windows.**Security notes & best practices**- Use unique, random salt per rotation; never reuse salt across tenants.- Use long, explicit info labels (include algorithm, length, tenant ID, version).- Limit derived-key lifetime and rotate regularly.- Perform all HKDF operations inside HSM when possible; never expose raw MSK.- Validate lengths (L) match algorithm requirements and zeroize keys after use.This yields independent, auditable key materials, supports safe rotation/versioning, and lets you use envelope encryption to minimize live-data re-encryption.
MediumTechnical
48 practiced
Compare Argon2i, Argon2d, and Argon2id. For each variant specify whether it is data-dependent or data-independent in memory access, its suitability vs side-channel attacks, and recommended uses (e.g., password hashing vs key derivation vs keyed use). Why is Argon2id often recommended for general password hashing?
Sample Answer
**Overview — quick definitions**Argon2 is a memory-hard password-hashing family with three variants: Argon2d, Argon2i, Argon2id. The difference is how memory blocks are addressed (data-dependent vs data-independent), which impacts resistance to GPU/ASIC attacks and side channels.**Variant comparison**- Argon2d - Memory access: data-dependent - Side-channel resistance: weak (branching depends on secret-derived data) - Recommended uses: keyed hashing, cryptocurrency (where side-channels less relevant), high-resistance to GPU/ASIC attackers- Argon2i - Memory access: data-independent (reads are independent of input) - Side-channel resistance: strong (no secret-dependent memory accesses) - Recommended uses: password hashing in hostile environments, KDFs where side-channel attacks are a concern- Argon2id - Memory access: hybrid (initial passes data-independent, later passes data-dependent) - Side-channel resistance: balanced — much better than pure Argon2d, slightly weaker than pure Argon2i - Recommended uses: general-purpose password hashing and key derivation; suitable when both GPU-resistance and side-channel mitigation matter**Why Argon2id for general password hashing**Argon2id combines the best of both: initial data-independent passes reduce timing/side-channel leakage, while later data-dependent mixing increases resistance to GPU/ASIC and tradeoff attacks. For most applications where attackers may have remote or local capability and side-channels are a concern, Argon2id provides a pragmatic, conservative default.
MediumTechnical
58 practiced
Explain common side-channel risks in KDF implementations: timing leaks, cache-based attacks, memory access pattern leakage, and power analysis. For each risk, provide concrete coding and deployment mitigations, including which KDFs are naturally safer and what runtime/hardware mitigations you would deploy in a multi-tenant cloud.
Sample Answer
**Overview**Briefly: KDF side-channels leak secrets via observable non-functional behaviour. Mitigations combine algorithm choice, constant-time coding, memory-hard designs, and deployment/hardware controls in multi-tenant clouds.**Timing leaks**- Risk: variable branches or early exits (e.g., key-dependent loop counts) reveal iterations.- Coding mitigations: constant-time loops, avoid data-dependent branches. Example: use fixed-iteration loops and a constant-time compare for verifiers.
- Safer KDFs: HMAC-based PBKDF2 implemented constant-time; Argon2i (data-independent) preferred over Argon2d for timing resistance.- Deployment: pin CPU cores, disable turbo/clock scaling to reduce microarchitectural variability.**Cache-based attacks & memory access pattern leakage**- Risk: attackers infer secrets from cache hits/misses or pointer-dependent memory access.- Coding mitigations: use data-independent memory access KDF variants (Argon2i/Argon2id with appropriate parameters), avoid lookup tables (use arithmetic), align and touch whole pages.- Safer KDFs: Argon2i/Argon2id, scrypt with careful constant-time implementations.- Deployment: isolate via CPU cgroups, dedicated VMs/containers, disable hyper-threading, use cache partitioning (CAT) and page coloring if available.**Power analysis**- Risk: side-channel from power traces (more physical).- Coding mitigations: mask intermediate values, avoid secret-dependent switching in loops.- Safer KDFs: same as above; software alone limited.- Deployment/hardware: use secure enclaves (SGX with caution), HSMs or dedicated hardware, power noise generation, and tamper-resistant hardware.**Cloud-specific runtime/hardware controls**- Enforce tenant isolation (dedicated instances for sensitive crypto), hyper-threading off, CPU pinning, use CPUs with cache partitioning, use constant-time cryptographic libraries, monitor performance anomalies, and prefer HSMs or confidential computing offerings for high-value keys.**Trade-offs**- Memory-hard and data-independent KDFs cost more resources; tune parameters for threat model and multi-tenant constraints.
Unlock Full Question Bank
Get access to hundreds of Key Management and Key Derivation interview questions and detailed answers.
