Cryptographic Standards and Compliance Questions

Compliance and standards governing the use of cryptography: approved algorithms and key lengths, FIPS 140 validation, key management standards, and regulatory expectations for encryption of data at rest and in transit. Covers how cryptographic choices are constrained by standards and how to demonstrate cryptographic compliance. Standards-and-governance view of crypto, not cryptographic design or attacks.

HardTechnical

43 practiced

You must migrate encrypted backups that were encrypted with an old key to a new KMS, but you cannot decrypt them in-place without risking integrity. Propose a safe migration path detailing verification steps, staging approach, downtime expectations, rollback criteria, and how you will validate post-migration integrity.

Sample Answer

Situation & constraints: Backups are encrypted with a legacy master key (old KMS). We cannot decrypt in-place (risking integrity/availability). Goal: move backups to be encrypted under new KMS with zero or controlled downtime and verifiable integrity + clear rollback.

High‑level approach (staged, safe rewrap):1. Preparation- Inventory all backup objects (IDs, locations, sizes, metadata, encryption headers, timestamps).- Confirm backups use envelope/encrypted-data-key model. If they store ciphertext + encrypted DEK, plan to rewrap DEKs instead of full decrypt where possible.- Establish an immutable staging area (separate bucket/namespace) with versioning and WORM where rewrapped files will land.- Create validation tooling (hashing, HMAC, header checks) and test on sample set.

2. Migration method- Preferred: Key‑rewrap (recommended): Use KMS to decrypt only the encrypted DEK with old KMS and immediately encrypt that DEK with new KMS, leaving bulk ciphertext untouched. This avoids full plaintext exposure.- If DEK not separable: perform streaming decrypt → streaming re-encrypt to staging location using ephemeral buffers (never write full plaintext to disk). Use TLS, memory limits, and process isolation.

3. Verification steps (per object)- Compute original ciphertext fingerprint (e.g., SHA-256 of ciphertext) and store.- After rewrap/re-encrypt, compute: a) hash of new ciphertext, b) validate metadata (IV, AEAD tag), c) run decryption test using new KMS on a sample chunk or whole object in-memory to confirm successful recovery.- For each migrated object store an audit record: original object id, original ciphertext hash, new object id, new ciphertext hash, rewrap method, timestamp, operator.

4. Staging & rollout- Run migration against a small sample set first (smoke test) — e.g., 0.1% including largest and smallest files.- Progress to bulk in waves (by age, priority, or bucket). Keep originals intact and immutable until verification complete.- No production downtime is required if backups are only for DR; otherwise schedule short windows for final cutover of active backup pointers.

5. Downtime expectations- For production restore paths: none during migration; final pointer/symlink update may require a short maintenance window (minutes) to switch read paths.- For large one-off migrations or if compliance requires atomic switch, schedule a maintenance window proportional to verification throughput.

6. Rollback criteria & procedure- If >X% (e.g., 1%) of objects in a wave fail verification, pause migration.- Rollback is simply: keep consumers pointed to original backups; remove or quarantine staged objects until fixes applied. Do not delete originals until full end-to-end validation completed and retention window passed.

7. Post-migration integrity validation- Randomized full restores: perform restores from staged backups for a statistically significant sample (and from all high-priority backups), validate application-level data and cryptographic checksums.- Run end-to-end restore tests into a sandbox, compare recovered data against known-good baselines (file hashes, DB checksums, row counts).- Audit and logging: ensure KMS audit trails show successful rewrap operations; correlate with migration audit records.- Final sign-off: after N days and passing all tests, retire old copies per retention policy and rotate/delete old KMS keys following policy.

Security controls- Use least privilege service accounts, KMS key policies for rewrap only, and isolated migration hosts.- Limit plaintext exposure: prefer rewrap, use in-memory streaming otherwise, enable OS-level memzero, encrypt swap, and log only metadata (never plaintext).

This plan minimizes plaintext exposure, provides staged verification, clear rollback, and measurable integrity validation for an auditable migration to the new KMS.

HardTechnical

46 practiced

A client requires encryption of all data in transit and at rest across regions and hybrid-cloud connectivity. Design the architecture and operational processes for encryption and key management: KMS selection, key hierarchy and rotation, cross-region key access (wrapping vs replication), performance implications, compliance reporting, and how to rotate keys with minimal service disruption.

Sample Answer

Requirements clarification:- Encrypt all data in transit and at rest across regions and hybrid-cloud; support regulatory auditing, key rotation with minimal downtime, and cross-region/hybrid access.

High-level design:- Use a cloud-native KMS per cloud provider (AWS KMS, Azure Key Vault, GCP KMS) as authoritative root-of-trust; introduce a centralized enterprise Key Management Service (enterprise KMS) that acts as policy/rotation controller and audits operations. For hybrid VMs/on-prem, deploy an HSM-backed gateway (e.g., AWS CloudHSM or Thales Luna as appliance) with KMIP support.

Key hierarchy:- Root Master Key (HSM-protected, rarely used) → Regional/Cloud CMKs (customer-managed keys) → Data Encryption Keys (DEKs, envelope keys) for objects/volumes → Per-tenant/per-application DEKs.- Use envelope encryption: services encrypt data with DEKs; DEKs are wrapped (encrypted) with CMKs.

Cross-region & hybrid access (wrapping vs replication):- Prefer wrapping + cross-region CMK replication only when required by latency/regulatory constraints. - Option A (wrapping): Store wrapped DEKs in object metadata; when a remote region needs the DEK, call source-region KMS to unwrap (requires network access and IAM cross-account roles). Pros: single key lifecycle, strong control. Cons: cross-region latency, dependency on network connectivity. - Option B (replication): Replicate CMKs or provision separate CMKs in each region and re-wrap DEKs per region (suitable when regional autonomy or KMS outage resilience required). Use secure key replication APIs with strict access controls and audit.- For hybrid, use HSM-backed gateway that proxies wrap/unwrap operations to enterprise KMS or caches short-lived unwrapped DEKs in secure memory.

Key rotation and minimal disruption:- Rotate CMKs on a schedule but avoid immediate re-encryption of all data. Use “rotate-wrapping-keys” pattern: 1. Generate new CMK, mark as primary for wrapping new DEKs. 2. Continue accepting old wrapped DEKs; services can unwrap with either key (support key version metadata). 3. Gradually rewrap hot DEKs by reading, unwrapping with old CMK, wrapping with new CMK during routine access or background batch rewrap jobs. 4. After all DEKs wrapped by old CMK are migrated and logs show no usage, schedule retire/destroy per retention policy.- For DEK rotation: issue new DEKs and re-encrypt active objects during maintenance windows; use lazy re-encryption for cold data.

Performance considerations:- Use envelope encryption to minimize KMS calls (one KMS op per DEK lifecycle rather than per I/O).- Cache DEKs in secure caches (in-memory, bounded TTL) in application or HSM gateway; ensure cache is encrypted and evicted on failover.- Monitor KMS API quotas and latency; provision dedicated HSMs for high-throughput workloads.

Security & compliance:- HSM-backed CMKs, strict IAM roles, least privilege, mutual TLS for hybrid connections, KMIP for appliance integration.- Maintain immutable audit trails: KMS audit logs, gateway logs, key rotation events, rewrap jobs with checkedums and timestamps. Integrate into SIEM and produce automated compliance reports (who/when/unwrapped/wrapped/rotated, region).- Data classification mapping to key policy: high-sensitivity data uses dedicated CMKs and stricter rotation/retention rules.

Operational processes:- Key lifecycle runbook: create → enable → rotate → retire → destroy with approvals and automated playbooks (IaC + CI/CD).- Incident playbooks: emergency key revocation, cross-region failover (use replicated keys or temporary wrap-until-failover).- Periodic audits and penetration tests; implement key usage alerts and anomaly detection.

Trade-offs:- Wrapping centralizes control and auditing but increases cross-region latency and availability risk. Replication improves locality and availability but increases attack surface and complexity of synchronization.- HSMs increase cost but required for high-compliance environments.

This architecture balances security, performance, and compliance while enabling phased rotation with minimal service disruption.

HardTechnical

42 practiced

You're leading a project to implement end-to-end encrypted messaging across web and mobile clients. Explain protocol choices (for example, double-ratchet), key exchange mechanisms, forward secrecy, replay protection, client key storage models, user experience trade-offs (account recovery vs security), and a phased rollout plan that ensures backward compatibility.

Sample Answer

Requirements clarification: secure E2E text (and attachments), cross-device (web + mobile), low latency, offline support, account recovery optional, gradual rollout with backward compatibility.

Protocol choices:- Use Signal Protocol (X3DH for initial key agreement + Double Ratchet for message confidentiality/integrity and post-compromise recovery). It’s well-audited, supports asynchronous delivery and multi-device via per-device sessions.- For attachments/large payloads: hybrid approach — encrypt file with symmetric AES-GCM, upload to server; send encrypted symmetric key via Double Ratchet.

Key exchange & sessions:- Use X3DH: identity keys (long-term, stored securely), signed pre-keys, and ephemeral one-time pre-keys to establish initial shared secret.- After X3DH, derive root key -> initialize Double Ratchet. For multi-device, maintain per-device identity and pre-key bundles.

Forward secrecy & replay protection:- Forward secrecy: ensured by ephemeral Diffie-Hellman in X3DH + continuous DH ratchets in Double Ratchet.- Future secrecy (post-compromise): symmetric-key ratchet (hash chains) and periodic re-keys.- Replay protection: include message counters, ratchet state with message indexes, and use AEAD with associated data (session IDs). Reject messages with old/duplicated counters and allow limited window for out-of-order delivery.

Client key storage models:- Mobile: use OS secure enclaves/keystores (iOS Keychain with Secure Enclave, Android Keystore) + hardware-backed keys where available.- Web: use WebCrypto + IndexedDB; protect private keys with client-side encryption derived from a passphrase or platform auth (WebAuthn). Consider using platform attestation for device binding.- For multi-device UX, store per-device private keys locally; server only stores public identity and pre-keys.

Account recovery vs security (UX trade-offs):- No recovery (maximum security): losing device = lost keys/messages. Good for high-security apps.- Social/escrow recovery: split-key escrow using Shamir + optional trusted contacts — increases attack surface.- Passphrase-based recovery: derive key from scrypt/PBKDF2 with strong iteration; protect against offline guessing but vulnerable if passphrase weak.- Recommended: offer opt-in, well-explained recovery with strong UX (progressive disclosure) and warn about trade-offs. Allow export/import of key backups encrypted with user passphrase and optionally backed up to cloud with client-side encryption.

Phased rollout & backward compatibility:1. Pilot: opt-in beta with power users; implement core Signal stack for 1:1.2. Multi-device & groups: add per-device sessions and group messaging (sender keys or the MLS model later).3. Web client: use end-to-end via browser sync; for browsers without Secure Enclave, require passphrase-unlock or WebAuthn.4. Attachment streaming + performance optimizations.5. Recovery features (opt-in) and enterprise policies (e.g., KMS-managed recovery for enterprise customers).Backward compatibility: support legacy non-E2E clients by gatewaying with clear UX (labels: “Not E2E”) and server-side transitional proxies. Provide migration tooling: server keeps pre-key bundles for new clients while maintaining compatibility flags.

Operational considerations:- Thorough threat modeling, audits, and open-source crypto libs.- Telemetry limited to metadata; no key material on servers.- Monitoring for abuse and key-rotation policies.- Legal/compliance paths for enterprise recovery.

This design balances strong cryptographic guarantees (Signal/X3DH+Double Ratchet) with pragmatic UX and a controlled, reversible rollout path.

Unlock Full Question Bank

Get access to hundreds of Cryptographic Standards and Compliance interview questions and detailed answers.

Join thousands of developers preparing for their dream job.