MediumTechnical

33 practiced

Provide Python pseudocode for an AES-GCM encrypt/decrypt wrapper that correctly handles nonce generation, associated data (AAD), and tag verification. Explain your chosen nonce strategy and how you would avoid or detect nonce reuse across distributed encryptors, including monitoring and alerting approaches.

Sample Answer

**Approach (brief)**

Use AES-GCM (AEAD) with a deterministic construction for nonce: per-key counter combined with unique per-process random prefix (96-bit nonce). Protect against reuse by persistent monotonic counters, leader election for distributed writers, and telemetry to detect duplicates.

**Pseudocode (Python-like)**

python

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os, struct

class AESGCMWrapper:
    def __init__(self, key: bytes, prefix: bytes=None, counter_store=None):
        self.aesgcm = AESGCM(key)
        self.prefix = prefix or os.urandom(8)    # 64-bit random prefix
        self.counter_store = counter_store or PersistentCounter()
        # nonce = prefix(8) || counter(4) => 96 bits

    def _next_nonce(self):
        counter = self.counter_store.increment_and_get()  # persist and atomic
        if counter >= (1 << 32):
            raise RuntimeError("counter exhausted")
        return self.prefix + struct.pack(">I", counter)

    def encrypt(self, plaintext: bytes, aad: bytes=b""):
        nonce = self._next_nonce()
        ct = self.aesgcm.encrypt(nonce, plaintext, aad)
        return nonce + ct   # store nonce with ciphertext

    def decrypt(self, packaged: bytes, aad: bytes=b""):
        nonce = packaged[:12]
        ct = packaged[12:]
        return self.aesgcm.decrypt(nonce, ct, aad)

**Nonce strategy rationale**

- 96-bit nonces maximize AES-GCM efficiency.- Prefix = per-process random 64-bit to separate writers; counter = 32-bit monotonic persisted value.- Persist counter atomically (e.g., durable DB record or consensus-backed lease) to avoid reuse after restart.

**Avoid/detect nonce reuse in distributed systems**

- Use lease or leader election so only one writer advances the counter per prefix.- Assign unique prefixes per instance (derive from stable instance id signed by KMS).- Persist counters in durable store (e.g., etcd/SQL) with atomic increment.- On boot, verify persisted counter > last used; if rollback detected, refuse to encrypt.

**Monitoring & alerting**

- Emit metrics: current counter value, counter increments/sec, counter resets, failed encrypt attempts.- Log events when prefix or key rotates, or when counter rollback detected.- Run periodic scans of ciphertext store to detect duplicate nonces per key (hash nonce+key id). Alert on duplicates and trigger key rotation + forensic investigation.- Alert thresholds: any counter rollback, duplicate-nonce detection, or unexpected rapid counter advance.

This design balances performance and provable nonce-uniqueness with practical distributed coordination and observable controls suitable for a cryptographer's threat model.

EasyTechnical

29 practiced

Describe common sources of entropy on servers and embedded devices, how to evaluate pseudorandom generator (PRNG) quality, and practical steps to mitigate low-entropy failures. Include how you would instrument and monitor entropy health in production.

Sample Answer

**Situation / Scope** I’ll describe entropy sources, PRNG evaluation, mitigation steps, and production monitoring from a cryptographer’s perspective.

**Common entropy sources**- Hardware TRNGs: ring oscillators, jitter in oscillators, avalanche diode noise. - Environmental: thermal noise, timing jitter from interrupts, network packet arrival times, user events (keyboard/mouse) — less relevant on headless servers/embedded. - Platform sources: /dev/random, hardware RNG peripherals (RNG_CTRL), TPM RNG.

**Evaluating PRNG/DRBG quality**- Statistical tests: NIST SP 800‑22, Dieharder, TestU01 for output randomness. - Entropy estimation: NIST SP 800‑90B for min-entropy of raw entropy sources. - Health tests: continuous health checks per NIST SP 800‑90A/90B (repetition count, adaptive proportion). - Cryptanalysis: verify construction (CTR-DRBG, HMAC-DRBG, Hash-DRBG) and proper seeding/reseeding.

**Mitigation for low-entropy**- Use a hybrid approach: XOR TRNG output into DRBG seed; fall back to hardware RNG + reseed frequently. - Seed from TPM or secure enclave at boot; postpone crypto ops until sufficient entropy collected. - Implement entropy whitening and conditioning (SP 800‑90B approved conditioners). - Rate-limit crypto key generation, and persist reseed material securely.

**Instrumentation & Monitoring**- Export entropy pool metrics: available entropy estimate (where provided), TRNG health status, reseed timestamps, failure counters. - Alerts: entropy below threshold, repeated health-test failures, unexpected reseed intervals. - Dashboards & logs: Grafana/Prometheus metrics (entropy_available, trng_health_failures, last_reseed_seconds). - Automated tests: CI fuzzing of RNG interfaces and periodic statistical tests on sampled outputs.

**Example metrics** - entropy_available (bits), trng_health_failures (count), last_reseed_seconds (gauge).

These practices ensure robust randomness suitable for cryptographic use in servers and constrained embedded devices.

EasyTechnical

36 practiced

What is an AEAD cipher? Explain the guarantees AEAD provides compared to separate encryption and MAC constructions. Give two examples of AEAD algorithms and explain when you would choose AEAD over encrypt-then-MAC and vice versa.

HardTechnical

30 practiced

You are responsible for migrating a large financial institution to post-quantum-safe cryptography. Propose a high-level migration plan that includes inventory of cryptographic assets, prioritization (what to migrate first), hybrid deployments, testing and interoperability, vendor coordination, regulatory/compliance considerations, performance testing, and rollback strategies.

Sample Answer

**High-level goal**Replace vulnerable primitives with PQ-safe alternatives while preserving availability, compliance, and cryptographic agility.

**1. Inventory**- Catalog keys, certificates, protocols (TLS, SSH, S/MIME, code signing), HSMs, firmware, VPNs, PKI, archival data.- Record algorithm, key usage, owner, expiry, crypto provider, performance profile, and regulatory requirements.

**2. Prioritization**- Tier 1: Internet-facing TLS, interbank APIs, transaction signing, HSM-protected keys.- Tier 2: Internal authentication, backups, archives with long secrecy requirements.- Tier 3: Low-risk telemetry, dev/test.

**3. Hybrid deployments**- Deploy hybrid (classical + PQ) signatures and KEMs for TLS, code signing, and key exchange to gain immediate protection and retain fallback.- Use crypto-agility wrappers and policy-based selection in clients/servers.

**4. Testing & interoperability**- Create a PQ testbed simulating production load; validate protocol negotiation, cert chains, chain-of-trust with hybrid certs.- Functional, FIPS-equivalence, and negative tests; interoperability matrix across OS, browsers, HSMs, and gateways.

**5. Vendor coordination**- Inventory vendor crypto stacks; require PQ-support roadmaps and FIPS/PQ-approvals in SLAs.- Define testing harness and conformance tests for vendor deliverables.

**6. Compliance & governance**- Map regulatory requirements (PCI, GLBA, SEC, local central bank); engage legal/compliance early.- Update crypto policy, key-rotation schedules, audit trails, and incident response playbooks.

**7. Performance**- Benchmark latency, CPU, memory, and HSM throughput; optimize by offloading, batching, or selective hardware acceleration.- Plan capacity upgrades where needed.

**8. Rollback & risk control**- Maintain dual-key/cert ecosystems and feature flags for graceful rollback.- Staged rollout (canary → pilot → phased global) with clear rollback triggers and automated reconfiguration.

**9. Timeline & metrics**- Define short (pilot), medium (partial migration), long (full) milestones; track success via interoperability pass rate, latency impact, and key replacement ratio.

As a cryptographer I’d own algorithm selection rationale, security proofs assumptions, and validation criteria while coordinating engineers, vendors, and compliance to execute the plan.

HardTechnical

31 practiced

An engineering team proposes a new proprietary block cipher tailored to a product. As the lead cryptographer, outline a formal review plan: mathematical analysis steps, security proof attempts or reductions, required test vectors and implementation tests, external review/challenge process, performance benchmarking, and acceptance/rejection criteria.

Sample Answer

**Overview / Goal**I would run a staged, evidence-driven review to determine if the proprietary block cipher is cryptographically sound, implementable, performant, and maintainable for production use.

**1. Mathematical analysis**- Collect formal specification: primitives, round function, key schedule, modes.- Conduct differential/linear cryptanalysis, boomerang, integral, slide, meet-in-the-middle, related-key analyses; estimate bounds for advantage vs rounds.- Search for structural weaknesses (symmetries, weak keys, low-diffusion components).- Produce attackability matrices with assumed attack models (black/white box, chosen-plaintext/ciphertext).

**2. Security proofs / reductions**- Attempt provable reductions where feasible (PRP/PRF under idealized assumptions).- Formalize goal (IND-CPA/CCA, pseudorandomness) and state assumptions (ideal S-box, random permutation).- Use automated tools (CryptoVerif/ProVerif) for protocol-layer proofs when cipher integrates into a mode.

**3. Test vectors & implementation tests**- Provide canonical vectors: key sizes, IVs, edge cases, KATs, MCTs.- Fuzzing, differential fault injection, side-channel leakage tests (power, timing).- Reference constant-time implementations in C/assembly with test harness and CI checks.

**4. External review & challenge**- Run public 90-day cryptanalysis challenge; invite academia and red teams.- Commission independent cryptographers for focused audits; require reproducible reports.

**5. Performance benchmarking**- Microbenchmarks (cycles/byte, latency) across target platforms; memory and throughput profiles.- Compare to AES/GCM and lightweight ciphers for similar security levels.

**6. Acceptance / rejection criteria**- Accept if: no practical attacks (advantage << 2^-64), provable reductions or sound heuristic arguments, passed side-channel tests, independent audits with no fatal findings, and performance meets product constraints.- Reject or iterate if: structural fatal flaws, feasible attacks, failed side-channel protections, or unacceptable implementation complexity.- If borderline: require design changes, additional proofs, or mandated external validation before deployment.

I would document all findings, sign-off conditions, and a mitigation roadmap before approval.

Cryptography Background Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank