Cryptographic Techniques and Trends Questions

Broad knowledge of contemporary and emerging cryptographic primitives, protocols, and research directions. Includes understanding of authenticated encryption with associated data and why it is preferred over legacy constructions, password based key derivation functions such as PBKDF2, Argon2, and scrypt and the role of salting and key stretching, elliptic curve cryptography design and trade offs, and an awareness of post quantum cryptography candidates including lattice based, multivariate, and hash based approaches. Also encompasses familiarity with the modern threat landscape such as quantum computing risks, how cryptographic research progresses into standards and real world practice, how to follow relevant conferences and journals, and the ability to synthesize research findings into practical recommendations for design, migration, and policy decisions.

HardTechnical

87 practiced

Given black-box access to a signing server that returns ECDSA signatures on chosen messages, design a fault-injection attack that would allow recovery of the private key under realistic fault models. Describe the fault model, the steps to induce and collect faulty signatures, the mathematical reasoning to recover the key from one or more faulty signatures, and recommend robust mitigations such as deterministic nonces, signature verification redundancy, and fault sensors.

Sample Answer

**Summary / goal**Design a realistic fault-injection that recovers an ECDSA private key d from a signing oracle by inducing faults in the ephemeral nonce generation or in k used during scalar multiplication. I describe the fault model, collection steps, mathematical recovery from faulty signatures, and practical mitigations.

**Fault model**- Localized transient fault during nonce generation or scalar multiplication (e.g., EM fault, laser, clock glitch).- Faults flip or zero a small subset of nonce bits, or truncate/replace k with k' = k + Δ where Δ is small or sparse.- Attacker can query the signing oracle on chosen messages before/after inducing faults and obtain both correct and faulty signatures.

**Collection steps**1. Obtain baseline correct signature (r, s) on message m with hash z.2. Induce fault during next signing; collect faulty signature (r', s') on same or chosen m'.3. Repeat to get multiple faulty signatures with different Δ patterns if needed.

**Mathematical reasoning**ECDSA: signature satisfies

text

s = k^{-1} ( z + d * r )  mod n

text

d = ( s * k - z ) * r^{-1}  mod n

If k' = k + Δ and we observe (r', s') and we know k partially (e.g., high bits unchanged) or Δ small, then rearrange:

text

s' = (k')^{-1} ( z' + d * r' )  mod n

From correct (r, s) and faulty (r', s') on same z, eliminate d to get linear relation in k and Δ. Practical recovery methods:- If nonce reuse (k = k'), recover d directly: standard two-sig reuse attack.- If Δ small and known sign/size: turn modular equation into integer inequality and solve via lattice (Bleichenbacher-style or Howgrave-Graham lattice) to recover k and thus d.- If low bits zeroed: use Coppersmith/lattice to recover unknown high bits by modeling k = k_high * 2^t and solving for k_high.- With multiple faulty samples having different small Δ, solve for k via multiple linear equations (CRT-style or lattice) to get d.

Key formula used when same message and known Δ:

text

s' * (k + Δ) - s * k  = (z' + d r') - (z + d r)  mod n

Which yields linear equations in d and k; eliminate k to solve for d or reduce to short-basis lattice problem.

**Practical considerations**- Need enough faulty signatures to make lattice dimension manageable (typically < 6–10).- Ensure r vs r' behavior: faults that alter scalar mult often change r; if r unchanged, recovery simpler.- Noise and modular wrap require treating equations as integer equations with bounded error.

**Mitigations**- Deterministic nonces per RFC 6979 or keyed-PRF (HMAC-DRBG) with integrity-protected seed eliminates RNG faults.- Compute nonce and signature twice (redundant computation) with independent hardware/clocks and compare before release.- Verify produced signature locally before output using pubkey; do not leak on verification failure.- Fault sensors / tamper detection: voltage, clock, laser, EM detectors with safe-fail on trigger.- Use constant-time, atomic scalar multiplication with countermeasures (blinding: k' = k + v*n, point blinding, scalar blinding).- Secure boot and hardware security module (HSM) enforcing physical protections.

I would choose lattice-based recovery in a lab to validate attack parameters, then recommend implementing deterministic nonces plus signature verification redundancy as highest-impact defenses.

MediumTechnical

154 practiced

You maintain a signing system using RSA-PSS and must migrate to post-quantum signature algorithms. Outline a practical migration strategy that includes backward compatibility, hybrid signing mechanisms, certificate and key lifecycle changes, performance evaluation, test vectors/KATs, rollout phases, and compatibility testing to ensure clients and servers can interoperate during transition.

Sample Answer

**Migration goal & constraints**Move from RSA-PSS to PQC signatures while preserving interoperability with legacy clients/servers, minimizing risk and meeting FIPS/NIST guidance (e.g., hybrid signatures) and certificate lifecycle requirements.

**High-level strategy**- Adopt hybrid signatures: sign messages with RSA-PSS and a chosen PQC algorithm (e.g., Dilithium / Falcon / SPHINCS+) and verify both; accept signatures that verify under either or both depending on policy.- Phased rollout: lab → canary → limited production → full rollout with rollback gates.

**Backward compatibility & certificates**- Issuing: issue certificates containing both classical key (RSA) and PQ public key in separate extensions (RFC 8555-style or new OIDs); advertise supported algorithms via TLS Certificate Extensions/AltCert.- Key lifecycle: provision PQ keys with same lifetime as RSA; maintain separate key stores; rotate PQ keys more frequently while monitoring maturity.- CRL/OCSP: ensure revocation supports both key types.

**Hybrid mechanism & implementation**- Sign flow: compute PQ_sig = PQ.Sign(message), RSA_sig = RSA-PSS.Sign(message); bundle as {RSA_sig, PQ_sig, alg_ids, cert_chain}.- Verify flow: try strict dual-verify (require both) for maximum security; for compatibility, allow single-verify with policy flags.- Keep deterministic encoding (CBOR/ASN.1) and length prefixes to avoid ambiguity.

**Performance evaluation**- Benchmark signing/verification latency, keygen, signature sizes, and memory/CPU across representative hardware (servers, embedded clients).- Measure network impact (larger certs/signatures) and storage for logs/archives.- Identify hardware acceleration needs and optimize stack.

**Test vectors & KATs**- Create Known Answer Tests for PQ algorithms and hybrid bundles covering edge cases (max message size, malformed sig, truncation).- Integrate KATs into CI; require hardware-in-the-loop tests for HSMs; fuzz input parsing.

**Rollout phases & compatibility testing**- Lab: interop tests between new and legacy implementations; TLS handshake variations; negative tests.- Canary: enable hybrid verify-only on subset of servers; collect telemetry (failure rates, latency).- Limited production: issue PQ-capable certs but continue accepting RSA-only clients.- Full: require PQ verification for high-sensitivity endpoints; monitor fallback usage.

**Monitoring, audit & rollback**- Instrument verification outcomes, error categories, and cryptographic library versions.- Maintain rollback plan: ability to revert to RSA-only policy and revoke PQ certs if needed.

**Risk & trade-offs**- Increased signature/cert size vs security; complexity in key management; HSM support lag—mitigate via staged testing and vendor coordination.

This plan balances security, interoperability, and operational practicality while enabling transition to post-quantum signatures.

HardTechnical

86 practiced

You are handed an implementation of a candidate lattice-based signature scheme. Create a comprehensive test plan to validate correctness, parameter safety, randomness/sampler quality, and resistance to side-channel and fault attacks. Include unit tests, known-answer tests (KATs), statistical tests for samplers, fuzzing targets, and simulated fault-injection and timing analyses appropriate for PQ primitives.

Sample Answer

**Overview & goals**

Validate correctness, parameter safety, sampler randomness, and robustness to side-channel and fault attacks for a lattice signature (e.g., Dilithium-style). Cover unit/KATs, statistical tests, fuzzing, timing/side-channel, and fault-injection.

**Unit tests & KATs**- Deterministic KATs: load official vectors (seed, keys, msgs, sigs). Verify keygen->sign->verify equality and signature canonical form.- API unit tests: invalid inputs, serialization round-trip, boundary params (max msg size, empty msg).- Parameter safety checks: verify modulus, norm bounds, successful rejection-sampling rates within expected thresholds.

**Sampler & RNG statistical tests**- Validate sampler distribution (discrete Gaussian or centered binomial): - Collect large samples; run Chi-squared, Kolmogorov–Smirnov, and compute mean/variance vs theoretical. - Run NIST STS / Dieharder on RNG outputs; test entropy with FIPS 140-2 style checks.- Rejection-sampling diagnostics: empirical acceptance probability; histogram of output magnitudes.

**Fuzzing & robustness**- Unit-level fuzzing: mutate seeds, sk, pk, messages, signature bytes; check crashes, UB, memory leaks (ASAN/MSAN).- Protocol-level fuzzing: corrupt wire formats, sequence numbers, truncated sigs, extra trailing bytes.- Coverage-guided fuzzing (libFuzzer): targets keygen/sign/verify code paths, include harnesses that assert constant-time branches.

**Side-channel & timing analyses**- Constant-time checks: static scan for data-dependent branches and memory accesses; compile with -fsanitize=address/time where supported.- Microbench timing: collect many cycles-per-op samples for keygen/sign/verify; compute timing distributions, CV, and t-tests comparing different secret-dependent input classes.- Cache attacks simulation: flush+reload traces for buffer indices dependent on secrets.

**Fault-injection & differential-fault tests**- Simulated faults: instruction-skip, bit-flips in secret key, RNG state, memory; assert verify rejects forged signatures or that secret leakage occurs only within modeled bounds.- Glitch models: flip random bits in signature generation inner loops, detect if faulty sigs pass verification (DFA risk).- Redundancy checks: implement/validate internal consistency (double-compute hash, checksum on randomness) and test that they detect faults.

**Expectations & thresholds**- KAT: 100% pass.- Sampler stats: p-values > 0.01 (no systematic deviation); acceptance rate within ±5% of theoretical.- Timing: no statistically significant difference (p>0.01) across secret classes after mitigation.- Fuzz: zero crashes, zero ASAN/MSAN errors after fixed-duration runs.

**Deliverables**- Test harness (libFuzzer + deterministic runners), KAT vectors, statistical reports, side‑channel measurement scripts, fault-injection harness, CI integration with nightly long-run statistical suites and sanitizer-enabled builds.

EasyTechnical

100 practiced

Explain the KEM-DEM (Key Encapsulation Mechanism + Data Encapsulation Mechanism) hybrid encryption paradigm. Describe the responsibilities of the KEM and the DEM, show a high-level message flow for encrypting a large message, and explain why hybrid encryption is used in practical systems such as TLS or email encryption. Provide an example of how a KEM-DEM composition can help achieve CCA security.

MediumTechnical

80 practiced

Outline the core ideas behind lattice-based cryptography. Describe the Learning With Errors (LWE) and Short Integer Solution (SIS) problems at a conceptual level, explain the role of noise/error and how it is used to build primitives, and summarize how parameter choices (dimension, modulus, error distribution) influence both security and performance.

Sample Answer

**Core ideas (high-level)** Lattice-based cryptography builds hardness on integer lattices — discrete additive subgroups of R^n — whose worst-case problems (e.g., Shortest Vector Problem) are conjectured to be hard even for quantum computers. Constructions reduce security of schemes to these lattice problems, enabling a wide range of primitives (encryption, signatures, KEMs) with post-quantum assurances.

**LWE and SIS (conceptual definitions)** - LWE: given many samples of the form

text

A · s + e  =  b   (mod q)

where A is public, s is a secret vector, and e is a small error vector, distinguishing (A,b) from uniform is hard. Learning s from noisy inner products is the core challenge. - SIS: given a random matrix A, find a short non-zero integer vector z such that

text

A · z  =  0   (mod q)

Finding short linear relations modulo q is hard; SIS is a natural basis for collision-resistant hashes and signatures.

**Role of noise/error** Noise e hides linear structure: without it, solving for s reduces to linear algebra. Small randomized errors create average-case hardness and allow reductions from worst-case lattice problems. In schemes, controlled noise enables correctness (decrypts despite error) and security (prevents attackers from solving the underlying linear equations).

**How primitives use noise** - Encryption/KEMs: encode message into LWE sample; decryption recovers message by cancelling small error. - Signatures: use SIS to produce short preimages; rejection sampling or bounded noise ensures unforgeability and correctness.

**Parameter trade-offs (dimension n, modulus q, error distribution χ)** - Dimension n: increases security (harder lattice problems) but costs computation and larger keys/ciphertexts. - Modulus q: larger q eases correctness for larger noise but can weaken reductions if too large; small q restricts noise magnitude. - Error distribution χ (e.g., discrete Gaussian with std σ): must be large enough for hardness reductions yet small enough to allow correct decryption/signing. Tail bounds matter — choose σ so failure probability is negligible. Security estimates combine lattice reduction complexity (BKZ) with root-Hermite factor; practical selection balances desired classical/quantum work factors against bandwidth and performance.

**Takeaway (as a cryptographer)** I choose parameters by targeting concrete attack costs (BKZ with realistic sieving), setting n, q, σ to meet security margins while keeping error-induced failure negligible and performance acceptable; I validate choices against latest lattice reduction benchmarks and conservative quantum assumptions.

Unlock Full Question Bank

Get access to hundreds of Cryptographic Techniques and Trends interview questions and detailed answers.

Join thousands of developers preparing for their dream job.