Entry-Level Cryptographer Interview Preparation Guide: FAANG Standard

Cryptographer

entry

6 rounds

Updated 6/22/2026

This guide is based on general FAANG interview practices and may not reflect specific company procedures.

Entry-level cryptographer positions at FAANG companies typically follow a structured 6-round interview process designed to assess foundational cryptographic knowledge, mathematical problem-solving abilities, coding proficiency, and cultural fit. The process emphasizes learning potential, clear communication, and ability to work on cryptographic problems with guidance. Entry-level candidates are not expected to have production-level cryptography experience; instead, interviews focus on strong fundamentals, mathematical reasoning, and potential to grow into the role.

Interview Rounds

Recruiter Screen

30 min3 focus topicsbehavioral

Technical Phone Screen

50 min3 focus topicstechnical

What to Expect

A 45-60 minute technical assessment conducted via phone or video with a senior engineer or cryptography specialist. This round assesses fundamental algorithmic thinking, basic understanding of cryptographic concepts, and coding ability. You'll be asked to solve 1-2 algorithmic problems (likely involving basic data structures, bit manipulation, or mathematical operations) and answer conceptual questions about cryptography fundamentals. This is a calibration round to ensure you have baseline technical competency before moving to deeper technical rounds.

Tips & Advice

Write clean, readable code—structure matters more than perfect optimization at this level. Talk through your approach before coding; explain your thinking process. For cryptography questions, focus on demonstrating foundational understanding rather than memorized details. If you don't know an answer, admit it and discuss what you'd do to learn. Practice explaining cryptographic concepts simply without jargon. Use the whiteboard or collaborative coding tool effectively. Test your code with examples before claiming it's complete. Time management is critical—solve the problem, not perfectly optimize it.

Focus Topics

Code Communication & Clarity

Writing clean code with meaningful variable names. Explaining your approach clearly before implementing. Discussing trade-offs and complexity. Asking clarifying questions.

Practice Interview

Study Questions

Algorithmic Problem-Solving Fundamentals

Solving basic algorithmic problems involving arrays, strings, mathematical operations, and bit manipulation. Understanding Big-O time and space complexity. Choosing appropriate data structures.

Practice Interview

Study Questions

Basic Cryptographic Concepts

High-level understanding of encryption vs. hashing, symmetric vs. asymmetric cryptography, digital signatures, and why cryptography matters. No deep mathematical knowledge required yet.

Practice Interview

Study Questions

Cryptography Fundamentals & Implementation

70 min5 focus topicstechnical

What to Expect

A deep-dive technical interview (60-75 minutes) focused on cryptographic concepts and basic implementation. You'll be asked to implement or modify cryptographic algorithms, explain how common encryption schemes work, analyze security properties, and solve cryptography-specific problems. This might include implementing key derivation, working with symmetric encryption, understanding hash functions, or designing simple secure protocols. Expect 1-2 problems with increasing complexity and several conceptual questions.

Tips & Advice

Understand the mathematical foundations—modular arithmetic, prime numbers, and bit operations will come up. Be able to implement or pseudocode basic cryptographic operations. Focus on explaining security properties and why certain approaches are used. For implementation problems, clarity and correctness matter more than optimization. Discuss attack vectors and how your implementation resists them. Ask questions about security requirements before implementing. Practice implementing simple ciphers like Caesar Cipher, Vigenère Cipher, or basic XOR operations before the interview.

Focus Topics

Cryptographic Implementation Basics

Secure coding practices in cryptography: avoiding timing attacks, proper random number generation, secure memory handling. Common implementation pitfalls and how to avoid them.

Practice Interview

Study Questions

Digital Signatures & Authentication

How digital signatures work conceptually. Relationship between hashing and signing. Why digital signatures provide both authentication and non-repudiation. Basic understanding of signature verification.

Practice Interview

Study Questions

Hash Functions & Integrity

Understanding cryptographic hash function properties: one-way, collision-resistant, deterministic. Common hash algorithms (SHA-256, SHA-3). Applications in digital signatures and password storage.

Practice Interview

Study Questions

Asymmetric Encryption & RSA Basics

Understanding public-key cryptography principles. How RSA works conceptually: key generation, encryption, decryption. Difference from symmetric encryption. When and why to use asymmetric vs. symmetric.

Practice Interview

Study Questions

Symmetric Encryption Fundamentals (AES, DES)

Understanding how symmetric encryption works, key concepts like block size and round functions. High-level operation of AES and DES without memorizing constants. Why symmetric encryption is fast and where it's used.

Practice Interview

Study Questions

Mathematical & Algorithm Problem-Solving

55 min4 focus topicstechnical

What to Expect

A focused technical interview (50-60 minutes) emphasizing mathematical problem-solving relevant to cryptography. This round assesses your mathematical reasoning, ability to work with number theory concepts, and algorithmic complexity analysis. Problems might involve: implementing modular arithmetic operations, working with prime numbers, analyzing algorithm efficiency, solving mathematical puzzles, or optimizing cryptographic operations. This round is designed for entry-level candidates to show mathematical maturity without requiring advanced degree-level mathematics.

Tips & Advice

Review modular arithmetic thoroughly—this is fundamental. Understand Big-O notation deeply and be able to analyze complexity. Practice working with binary representations and bitwise operations. Know basic number theory: GCD, prime checking, modular exponentiation. For each problem, explain your mathematical approach before coding. If you get stuck, talk through your thinking—partial credit for correct reasoning. Use examples to verify your logic. Don't overthink optimization; correctness and clarity are more important.

Focus Topics

Cryptographic Problem-Solving

Solving mathematical puzzles specific to cryptography: cracking simple ciphers, analyzing key space, understanding brute-force complexity, identifying algorithmic weaknesses.

Practice Interview

Study Questions

Bitwise Operations & Binary Representation

Working with binary representations, bitwise AND, OR, XOR operations. Bit shifting and manipulation. How bits are used in cryptographic operations like S-boxes and diffusion.

Practice Interview

Study Questions

Algorithm Complexity Analysis

Analyzing time and space complexity of algorithms. Understanding why certain cryptographic operations are computationally difficult. Comparing efficiency of different approaches. Big-O, Big-Theta, Big-Omega notation.

Practice Interview

Study Questions

Modular Arithmetic & Number Theory

Understanding modular arithmetic operations, modular exponentiation, finding modular inverse. Basic number theory: greatest common divisor (GCD), Euclidean algorithm, prime numbers. How these concepts appear in cryptographic algorithms.

Practice Interview

Study Questions

Cryptographic Protocol & System Design

55 min4 focus topicstechnical

What to Expect

A technical interview (50-60 minutes) assessing your ability to think about cryptographic protocols and small-scale system design. This round is lighter than traditional system design interviews for entry-level candidates. You might be asked to: design a simple secure communication protocol, explain how to securely exchange a session key, design authentication for a two-party system, or analyze existing protocols for vulnerabilities. The focus is on demonstrating understanding of cryptographic building blocks and how they fit together, not on large-scale distributed systems.

Tips & Advice

Start by understanding the requirements and threat model. Ask clarifying questions about what you're protecting against and who the parties are. Use well-known cryptographic primitives rather than inventing new ones. Discuss trade-offs: security vs. performance, complexity vs. usability. Draw diagrams to explain protocols. Discuss potential attacks on your design. Reference real protocols like TLS concepts if appropriate. Acknowledge where your entry-level design might be simplified compared to production systems. Focus on correctness and clear reasoning over complexity.

Focus Topics

Threat Modeling & Vulnerability Analysis

Identifying potential attacks on protocols: eavesdropping, man-in-the-middle, replay attacks. Analyzing how your design resists these threats. Understanding what you're protecting against.

Practice Interview

Study Questions

Authentication & Integrity Assurance

Using cryptographic techniques to ensure message authenticity. Digital signatures and message authentication codes (MACs) in protocols. How to design authentication into communication.

Practice Interview

Study Questions

Secure Key Exchange & Distribution

Conceptual understanding of key exchange problems. How symmetric keys are securely shared. Public Key Infrastructure (PKI) at a high level. Why certain approaches work and others don't.

Practice Interview

Study Questions

Cryptographic Protocol Design Basics

Understanding how to combine cryptographic primitives into protocols. Key agreement, authentication, and confidentiality in protocols. Threat models and security goals. Simple protocol design for entry-level scenarios (two-party communication, basic authentication).

Practice Interview

Study Questions

Behavioral & Cultural Fit Interview

40 min5 focus topicsbehavioral

What to Expect

A 30-45 minute interview focused on behavioral competencies, teamwork, learning ability, and alignment with company culture. This round is typically conducted by a hiring manager, team member, or senior engineer. You'll be asked situational questions about handling challenges, working in teams, learning from mistakes, and demonstrating company values. For entry-level positions, interviewers assess: coachability, growth mindset, ability to work with others, communication skills, and genuine interest in the field. This round is equally important as technical rounds—FAANG companies won't hire brilliant candidates who don't fit the culture.

Tips & Advice

Prepare 4-5 specific stories demonstrating: overcoming a technical challenge, learning from a mistake, collaborating effectively, handling feedback, and showing initiative. Use the STAR method (Situation, Task, Action, Result). For entry-level, focus on academic projects, internships, or personal projects—they count as experience. Be authentic and humble; entry-level candidates should show they're eager to learn, not already know everything. Research the company thoroughly and mention specific reasons you want to work there. Ask thoughtful questions about the team and projects. Discuss what interests you about cryptography long-term. Show enthusiasm and genuine curiosity.

Focus Topics

Passion for Cryptography & Security

Genuine interest in cryptography as a field. Why you're passionate about security. Side projects or research interests. Vision for career in cryptography.

Practice Interview

Study Questions

Company Culture & Values Alignment

Understanding the specific company's values and showing alignment. For Google: 'Think big', 'Focus on the user'; Amazon: 'Customer obsession', 'Ownership'; Meta: 'Move fast', 'Build awesome things'; Microsoft: 'Learn-it-all', 'Growth mindset'. Giving examples of how your approach aligns.

Practice Interview

Study Questions

Handling Challenges & Failure

Stories about overcoming technical obstacles, learning from mistakes, handling feedback constructively. How you debug problems. Persistence in solving difficult problems.

Practice Interview

Study Questions

Learning Agility & Growth Mindset

Stories demonstrating willingness to learn new topics, overcoming knowledge gaps, seeking mentorship. Examples of how you've grown technically. Comfort with not knowing something but ability to figure it out.

Practice Interview

Study Questions

Teamwork & Collaboration

Examples of collaborating with others, contributing to team success, supporting teammates. How you handle disagreements. Your role in group projects. Communication in technical settings.

Practice Interview

Study Questions

Frequently Asked Cryptographer Interview Questions

Secure Protocol Design and ImplementationHardTechnical

60 practiced

You audit a protocol using ECDSA signatures for authorization tokens. The implementation accepts non-canonical encodings and does not enforce low-S canonicalization. Explain how signature malleability could be exploited at the protocol layer (for example to create different valid tokens or transaction replay) and propose concrete fixes at both implementation and protocol levels.

Sample Answer

**Brief impact summary**ECDSA malleability (s -> n - s and non-canonical integer encodings) lets an attacker create different byte-for-byte-valid signatures for the same private key/message. If the protocol treats the raw signature bytes as part of token/transaction identity or as the nonce for deduplication, an attacker can: (1) produce alternate tokens that bypass uniqueness checks, (2) replay a transaction under a different signature-derived ID, or (3) confuse auditing/rollback systems that rely on signature equality.

**How it’s exploited (concrete examples)**- Protocol uses signature bytes as token ID: signing yields sig1; attacker computes sig2 with s' = n - s or strips/adds leading zeros in r/s. sig2 verifies but has different token ID → double-spend or duplicated permissions.- Transaction hash includes signature encoding: different encodings change tx hash; consensus / caching / anti-replay checks fail.- Replay across systems: one system accepts non-canonical forms, another canonicalizes; mismatched canonical rules let an attacker craft tokens accepted somewhere and replayed elsewhere.

**Implementation-level fixes (concrete)**- Enforce strict DER/ASN.1 parsing: reject non-minimal integer encodings, no leading zero bytes unless necessary, correct length fields.- Enforce low-S canonicalization: require s <= n/2; if s > n/2, either reject or normalize to s' = n - s and require submitter to use normalized signature.- Validate ranges: 1 <= r <= n-1 and 1 <= s <= n-1; reject zero values.- Fix recovery id behavior: if using v/recovery bits, standardize semantics and validate consistency with r,s and recovered public key.- Use well-reviewed library calls with strict signature verification modes (e.g., OpenSSL/LibreSSL strict DER check, BoringSSL’s X509_SIG parsing flags).

**Protocol-level fixes (concrete)**- Separate identity from raw signature bytes: do not derive token/tx IDs from raw sig bytes. Derive IDs from canonicalized payload + signer public key + nonce (e.g., id = H(canonical_payload || pubkey || nonce)).- Canonicalize serialization before signing/verification (canonical JSON or protobuf) and specify exact encoding in the spec.- Require signer to sign canonicalized payload and include signature scheme/version in payload to avoid cross-version ambiguity.- Anti-replay: include monotonic nonces / sequence numbers / timestamps in signed payload and implement server-side state (used nonces set) or use a deterministic per-signer counter stored on-chain.- Migration: during roll-out, accept only canonicalized signatures OR accept both but canonicalize and map alternatives to a single canonical ID server-side so duplicates are rejected.

**Trade-offs / operational notes**- Normalizing signatures at verification (accept-and-normalize) is practical but must be paired with canonical ID derivation to avoid transient duplicates.- Enforcing strict formats may break legacy clients—plan a deprecation/migration window and require re-signing for persistent tokens.- Low-S enforcement is low cost and strongly recommended immediately.

Applying both strict implementation checks and protocol-level canonicalization/anti-replay yields defense-in-depth: attackers cannot create alternate valid encodings, and even if they could, different encodings won’t change token/transaction identity or bypass replay protections.

Collaboration and Communication SkillsEasyTechnical

64 practiced

Security and legal disagree about whether using a strong cipher triggers export-control requirements that slow feature delivery. How would you facilitate a constructive conversation between these teams, identify acceptable technical and policy compromises, and produce a written decision and implementation plan?

Learning Agility and Growth MindsetEasyTechnical

54 practiced

Describe the steps you would take to reproduce the experimental results from a cryptography research paper (for example, throughput numbers for a new symmetric construction). Include how you'd find or reconstruct test vectors, set up a fair benchmark, verify correctness, and document divergences if results differ.

Sample Answer

**Overview — goal**Reproduce the paper’s throughput and correctness for a new symmetric construction reliably and transparently.

**Step 1 — gather materials**- Obtain paper, appendix, supplementary code/data, and cited references.- Search authors’ repos, GitHub, archived artifacts, and contact authors for missing test vectors or scripts.

**Step 2 — reconstruct test vectors**- Extract algorithm spec, parameters, IV/nonce rules, padding and AD handling.- If vectors aren’t provided, derive small deterministic vectors from pseudocode and verify algebraic properties (e.g., known-key/known-plaintext outputs, permutation invariants).- Cross-check against standard primitives (AES, ChaCha) used in comparisons.

**Step 3 — implement and verify correctness**- Implement in a safe language (C/Python/Go) with clear API; prefer reference (portable, simple) and optimized builds.- Validate with: - Unit tests using provided or reconstructed vectors. - Property tests (decrypt(encrypt(m)) == m, tag verification failures). - Cross-implementation checks (compare reference vs optimized).- Use formal checks where feasible (e.g., test against Sage or small-step symbolic tests).

**Step 4 — fair benchmarking**- Recreate target workload from paper (message sizes, IV reuse patterns, AAD).- Control variables: same CPU, compiler and flags, single-threaded vs parallel modes, CPU scaling governor off, isolated cores, disable turbo/Hz changes, warm-up iterations.- Measure wall-clock and CPU cycles (rdtsc/clock_gettime), cache effects, memory bandwidth.- Run many iterations, report median and 95% CI; collect throughput, latency, and variability.

**Step 5 — compare and document**- Reproduce paper’s plots/tables; if different, list divergences: - Implementation differences (algorithmic choices, constant-time trade-offs) - Environment (hardware, compiler/version, flags) - Benchmark methodology (message distribution, threading) - Optimizations missing/added- Provide reproducibility package: code, scripts, exact compiler flags, hardware specs, raw logs and analysis notebook.

**Example tools & best practices**- Tools: perf/pmu, valgrind/ASan, Git for provenance, Docker or GitHub Actions for CI reproducibility.- Best practices: seed PRNGs for deterministic runs, include statistical summary, be explicit about microarchitectural effects and constant-time considerations.

This process ensures correct cryptographic behavior, fair performance claims, and transparent documentation of any gaps between reproduced and reported results.

Secure Cryptographic ImplementationMediumSystem Design

60 practiced

Design a secure password-reset token mechanism for a web application. Include token generation (entropy length), storage (hashing vs plaintext), expiry and single-use enforcement, rate-limiting, and defenses against token prediction, reuse, and abuse. Also describe how you would log and monitor reset flows for abuse without leaking sensitive information.

Sample Answer

**Clarify goal & threat model**Protect against token prediction, replay, abuse (mass-reset), token disclosure; assume HTTPS, server compromise risk lower than DB leaks.

**Token generation**- Use 32 bytes (256 bits) of CSPRNG entropy: secure against brute-force for practical windows.- Token = base64url( 32 bytes ). Store only a server-side MAC/derivation: token_secret = HMAC-SHA256(K_server, token) or token_hash = Argon2id(token) if DB-only compromise considered.

**Storage & single-use**- Store token_hash (HMAC or slow hash) + user_id + created_at + expiry + used_flag.- On redeem: compute HMAC/Argon2 on presented token and compare constant-time; atomically set used_flag = true (DB transaction) to prevent race conditions.

**Expiry & rate-limiting**- Short lifetime: 15–60 minutes depending on risk. Enforce per-account TTL and global per-IP cooldowns.- Rate-limit generation: e.g., 3 resets per 24h per account, exponential backoff per IP, captcha after threshold.- Rate-limit verification attempts per token/IP to prevent online brute force.

**Defenses**- Token unpredictability via CSPRNG and 256-bit entropy.- Use keyed MAC (K_server rotated with key versioning) so DB leaks don't reveal valid tokens.- Bind token to context: include user-agent hash or partial IP checksum and require match for high-risk flows.- Use one-shot tokens; if token reused, reject and alert account owner.

**Logging & monitoring**- Log events: request, send, verify_success/failed, reuse_attempt with non-sensitive metadata: user_id (hashed), event type, timestamp, IP (anonymized/prefix), device fingerprint, failure reason code.- Do NOT log raw tokens, full IPs, or emails in plaintext. Use truncation/hashing with HMAC key to allow correlation without exposure.- Alerts: anomalous spikes (mass resets per IP/target), multiple failed verifications, token reuse — trigger automated mitigation (block IP, escalate to MFA).- Retain logs per policy and protect with access controls and audit.

As a cryptographer I'd prefer keyed HMAC + short TTL + Argon2 for DB-only threats, strict rate limits, atomic single-use enforcement, and careful telemetry that supports detection without leaking secrets.

Asymmetric Encryption and Key ExchangeHardTechnical

66 practiced

Model the CPU and latency cost of TLS handshakes at peak load for a server using three different certificate types: RSA-2048, ECDSA P-256, and Ed25519. Given requests per second and average client CPU, estimate server CPU cycles required per second and discuss why session resumption and hardware offload are commonly used to reduce cost.

Sample Answer

**Clarify assumptions**- Each full TLS handshake requires one server private-key operation (server signs or performs private RSA op) and some symmetric work (negligible vs. asymmetric). No client-initiated mutual auth.- Use typical private-op cycle estimates on modern x86 (single core @ 3.0 GHz): - RSA-2048 private op ≈ 2.5e6 cycles - ECDSA P-256 sign ≈ 2.0e5 cycles - Ed25519 sign ≈ 8.0e4 cycles - rps = peak requests per second (handshakes/sec). Server CPU cycles/sec required = rps * cycles_per_handshake.

Model (formula)

text

server_cycles_per_sec = rps  * cycles_per_private_op

Plain-English: multiply handshakes per second by cycles needed for each private key operation.

Concrete example (rps = 2,000)- RSA-2048: 2,000 * 2.5e6 = 5.0e9 cycles/sec ≈ needs 5.0e9 / 3.0e9 ≈ 1.67 CPU cores- ECDSA P-256: 2,000 * 2.0e5 = 4.0e8 cycles/sec ≈ 0.13 cores- Ed25519: 2,000 * 8.0e4 = 1.6e8 cycles/sec ≈ 0.05 cores

Notes on client CPU: clients bear verification costs (cheaper for ECDSA/Ed25519) — useful when estimating client-side battery/latency but does not reduce server cycles.

Why session resumption and hardware offload reduce cost- Session resumption (PSK, session tickets, TLS 1.3 0-RTT/1-RTT resumption) removes the need for the expensive server private-key op on subsequent connections — reduces asymmetric cost by ~100% for resumed sessions, leaving only symmetric crypto (AES/HMAC) which is orders of magnitude cheaper.- Hardware offload (TLS accelerators, HSMs, NIC TLS) moves private-key ops to specialized silicon or isolated modules, reducing host CPU cycles and improving latency/side-channel protection. Trade-offs: cost, management, latency to HSM, and limited algorithm support.

Edge cases & verification- Actual cycles vary by implementation, CPU generation, compiler and accelerating instructions (P-256 on CPUs with accelerated bigint/montgomery is faster). Measure with microbenchmarks for precise capacity planning.

Cryptanalysis and Security EvaluationHardTechnical

42 practiced

You're assigned a comprehensive security evaluation of a new hash function design. Draft a prioritized evaluation plan that covers collision and preimage attacks, differential path search, algebraic analysis, statistical randomness testing, implementation-level concerns (side-channels), and recommendations for conservative parameter choices. Include resource estimates for each major analysis task.

Sample Answer

**Clarify scope & goals**- Target security level (e.g., 128/192/256-bit), targeted platforms, performance constraints, and whether the design is sponge/Merkle–Damgård/HAIFA. Set acceptance criteria (no better-than-brute-force preimage; collision complexity ≥ 2^(n/2)).

**Prioritized evaluation plan (high → low)**1. Collision & preimage search (priority: highest) - Tasks: Build optimized byte/word-level implementations; adapt meet-in-the-middle, multi-block, and multi-target strategies; run heuristic birthday/parallellized searches. - Resources: 2 crypto engineers + 4 GPU nodes (e.g., 8×A100) for 6–8 weeks; expected wall-time depends on claimed security (e.g., to detect 2^(k) break, need O(2^k / GPUspeed)).2. Differential/linear/path search - Tasks: Automated differential path discovery (Trail search), truncated differentials, rotational/bitwise differentials; use MILP search, SAT-assisted pruning. - Resources: 1–2 cryptanalysts; 4–6 weeks; MILP/SAT runs require cluster access (16–64 cores).3. Algebraic & structural analysis - Tasks: Model as polynomial system, Gröbner-basis and XL attempts, algebraic degree growth, symmetry/group analysis. - Resources: 1 cryptographer + access to HPC (128 GB RAM nodes); 4–8 weeks depending on degree.4. Statistical randomness testing - Tasks: Avalanche, bit independence, NIST STS, Dieharder, entropy per-bit, frequency, compressibility. - Resources: 1 engineer; 1–2 weeks; datasets: 10^6–10^8 compression-length outputs.5. Implementation & side-channel audit - Tasks: Constant-time analysis, timing, cache, EM, fault injection vulnerability; review reference code and typical SDKs. - Resources: 1–2 engineers + hardware lab (oscilloscope, EM probe); 2–4 weeks.6. Cross-checks & conservative parameter recommendations - Tasks: Recommend output length ≥ 2× claimed security; internal state size ≥ 3× output for sponge; rounds margin (≥ 30–50% above those attacked). - Resources: consolidation: 1 week.

**Deliverables & timeline**- Interim reports at 2, 6, and 12 weeks; final report with attack descriptions, reproducible scripts, and parameter recommendations.

**Conservative recommendations**- If aiming 128-bit security: output ≥ 256 bits, state ≥ 384 bits, rounds increased by 30–50%, and per-byte S-boxes with no key-dependent branches.- Mandatory: reference constant-time implementation, test vectors, and reproducible tooling.

**Risk/uncertainty**- Algebraic and differential searches have high variance; provide probability-weighted estimates and record all failed but near-successful trails for caution.

Cryptographic Hash FunctionsMediumTechnical

119 practiced

Explain the role of hashing in key derivation for protocols like TLS or SSH. Describe how an HKDF extract-then-expand flow works and why extract is useful when the input keying material has variable entropy quality.

Sample Answer

**Brief answer (role: Cryptographer)**

**Role of hashing in KDFs for TLS/SSH**- Hash functions provide mixing, domain separation, and a PRF-like output from potentially weak or structured secrets.- In protocol KDFs they ensure outputs are pseudorandom, non-malleable across labels/contexts, and efficient to compute.

**HKDF extract-then-expand flow**1. Extract: compute a fixed-length pseudorandom key (PRK) by HMAC using a salt:

text

PRK = HMAC(salt, IKM)

Intuition: condenses IKM (input keying material) into uniform-strength keying material.2. Expand: derive application keys using HMAC-DRBG style iterates with info and counter:

text

T(1) = HMAC(PRK, info || 0x01)
T(2) = HMAC(PRK, T(1) || info || 0x02)
OKM = T(1) || T(2) || ...

**Why extract is useful with variable entropy**- When IKM has unknown or low entropy (passwords, Diffie-Hellman with biased sampling, or concatenated non-uniform inputs), extract: - Acts as an entropy condenser/universal extractor under HMAC assumptions, producing a near-uniform PRK. - Allows reuse of a fixed PRK for multiple deterministic expansions with domain separation (info), preventing cross-protocol/key leakage.- Salt provides salting/nonce to avoid reuse attacks and improves entropy mixing when available.

**Security notes**- Choose salt non-secret if none available; using a zero salt reduces extractor strength.- HMAC security reduces to hash properties; prefer proven constructions (HKDF-SHA256/512).

Hash Functions and Digital SignaturesMediumTechnical

99 practiced

Explain why using H(secret || message) as a MAC is insecure when the hash is a Merkle–Damgård construction (e.g., MD5/SHA-1) and describe the length-extension attack. Show the attack idea and then explain how HMAC fixes it, including why HMAC resists length-extension and what properties of the underlying hash it relies on.

Sample Answer

**Answer (structured)**

**Why H(secret || message) is insecure (Merkle–Damgård length-extension)** Merkle–Damgård hashes (MD5/SHA-1) process input as iterated compression: initial IV → compress(block1) → ... → final H. If MAC = H(K || M), an attacker who knows M and MAC = H(K || M) obtains the *internal chaining value* after processing K || M. Because the compression can be continued, the attacker can append additional data X and compute H(K || M || pad(K||M) || X) without knowing K. This produces a valid MAC for the longer message.

Attack idea (concrete): attacker knows MAC = h_n = H(K || M). They choose suffix X and simulate padding for unknown |K| (try plausible lengths). They then feed h_n as initial chaining value and compress X (with proper padding) to get MAC' = H(K || M || pad || X). Server verifying H(K || M || pad || X) will accept.

**Why HMAC fixes it** HMAC = H( (K ⊕ opad) || H((K ⊕ ipad) || M) ). Two-layer structure prevents length-extension because the attacker only sees outer H output; the inner hash result is keyed and its chaining value depends on K ⊕ ipad. Crucially the attacker cannot set the internal state to that value and continue hashing arbitrary data because the outer hash inputs are fixed-length: the outer hash starts from IV and processes (K ⊕ opad) || inner_hash. There is no way to append data to that outer input without knowing K.

**Properties HMAC relies on**- The compression function should be collision-resistant and behave like a PRF when keyed (i.e., inner keyed hash unpredictable to attacker).- The fixed block-size padding and use of two distinct keys (ipad/opad) prevents simple manipulations.- HMAC security proofs assume the underlying hash is a PRF or at least that the compression function is secure under keyed usage.

In short: H(K||M) leaks a chaining value enabling length-extension. HMAC encapsulates the keyed value inside a nested keyed hash so an attacker cannot continue the internal state, preventing length-extension while relying on standard hash-function properties.

Secure Protocol Design and ImplementationEasyTechnical

82 practiced

List common side-channel attack vectors for cryptographic implementations on embedded devices (timing, cache, power, electromagnetic), and for each provide at least one practical mitigation. For modular exponentiation specifically, describe a blinding or masking technique to reduce leakage.

Sample Answer

**Common side‑channel vectors & practical mitigations**

- **Timing** - Issue: secret-dependent branches or variable-time arithmetic leak info. - Mitigation: constant-time algorithms (avoid secret-dependent branches/lookup), use constant-time libraries, ensure modular reductions and multiplications are time-invariant.

- **Cache** - Issue: cache hits/misses reveal access patterns (flush+reload, prime+probe). - Mitigation: data-oblivious memory access, prefetch/flush deterministic patterns, partition or disable shared caches for crypto, use scatter‑store table lookups (or avoid table lookups entirely).

- **Power (SPA/DPA)** - Issue: instantaneous or averaged power correlates with processed data. - Mitigation: first-order masking (randomize intermediates), higher-order masking for stronger attacks, current/clock noise injection, balanced logic/dual-rail, and robust leakage-resilient implementations.

- **Electromagnetic (EM)** - Issue: EM emanations carry same leakage as power or bus activity. - Mitigation: shielding, filtering, hardware grounding, randomized execution/timing and the same algorithmic countermeasures as power (masking/blinding).

**Modular exponentiation — blinding / masking techniques**

- RSA message blinding (multiplicative blinding): pick random r coprime to N. Compute m' = (m * r^e) mod N c' = (m')^d mod N c = (c' * r^{-1}) mod N This removes leakage tied to m during exponentiation.

- Exponent (scalar) blinding: pick random k, compute d' = d + k * phi(N) (or for ECC: k' = k + r*order) and use d' — changes intermediate sequence without changing result.

- Masking for modular multiply: split secret s into s0 ⊕ s1 (or additive mod p), operate on masked shares with masked arithmetic and refresh masks to defeat DPA.

Why these work: blinding introduces randomness orthogonal to the secret so side-channel traces become uncorrelated with the true secret; masking splits secrets so single-point leakage reveals only random shares. Combined with constant-time code and hardware protections, they substantially reduce practical leakage.

Collaboration and Communication SkillsHardTechnical

69 practiced

Your review uncovers a subtle timing side-channel in a widely used open-source crypto library your product depends on, and product cannot immediately stop using it. Explain how you would coordinate responsible disclosure with maintainers, design temporary mitigations for your deployments, conduct internal communication under embargo constraints, and plan customer notification and remediation once a fix is available.

Sample Answer

**Situation summary (one line)** I discover a subtle timing side‑channel in a widely used crypto library we depend on; we cannot drop it immediately.

**Responsible disclosure with maintainers**- Promptly prepare a reproducible report: PoC (minimal), test vectors, scope, exploitability, and suggested mitigations (constant‑time refactor, blinding, removal of branch/data‑dependent ops).- Use encrypted channel (PGP) to contact lead maintainer and project security contact; include CVE request recommendation.- Agree on embargo timeline and coordinated release date; offer assistance and test patches.

**Temporary mitigations for our deployments**- Implement in‑process compensations: enforce constant‑time wrappers around affected primitives, introduce algorithmic blinding (random nonce XOR, masking), and add fixed‑time padding to sensitive operations.- Reduce attack surface: rotate and segregate keys, limit access to crypto APIs, apply rate‑limiting and noise/jitter at network edge to reduce measurement fidelity.- Deploy mitigations behind feature flags and canary to measure perf/compatibility.

**Internal communication under embargo**- Create a need‑to‑know group: CISO, engineering leads, legal, incident response, and product security. Use encrypted internal channels and limit documentation access.- Provide clear playbook: what to test, rollout schedule, rollback criteria, and monitoring metrics (timing variance, error rates).- Prepare PR/legal talking points and embargoed FAQ.

**Customer notification & remediation**- Coordinate with maintainers on public advisory and CVE. Prepare staged customer communication: private notice to high‑risk customers first (with remediation steps), then public advisory on agreed date.- Offer mitigations: configuration guidance, SDK updates, recommended key rotations, and patch timeline.- Post‑release: provide CVE details, technical writeup, telemetry evidence, and support for forensics and mitigation verification.

**Lessons & follow‑up**- Integrate regression tests for constant‑time properties, add CI side‑channel fuzzing, and pursue upstream fixes and sponsorship if required.

Practice Cryptographer questions across all topics

Additional Information

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Cryptographer jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Entry-Level Cryptographer Interview Preparation Guide: FAANG Standard

Interview Process Overview

Interview Rounds

Recruiter Screen

What to Expect

Tips & Advice

Focus Topics

FAANG Culture & Values Alignment

Practice Interview

Study Questions

Communication of Technical Concepts

Practice Interview

Study Questions

Professional Background & Motivation

Practice Interview

Study Questions

Technical Phone Screen

What to Expect

Tips & Advice

Focus Topics

Code Communication & Clarity

Practice Interview

Study Questions

Algorithmic Problem-Solving Fundamentals

Practice Interview

Study Questions

Basic Cryptographic Concepts

Practice Interview

Study Questions

Cryptography Fundamentals & Implementation

What to Expect

Tips & Advice

Focus Topics

Cryptographic Implementation Basics

Practice Interview

Study Questions

Digital Signatures & Authentication

Practice Interview

Study Questions

Hash Functions & Integrity

Practice Interview

Study Questions

Asymmetric Encryption & RSA Basics

Practice Interview

Study Questions

Symmetric Encryption Fundamentals (AES, DES)

Practice Interview

Study Questions

Mathematical & Algorithm Problem-Solving

What to Expect

Tips & Advice

Focus Topics

Cryptographic Problem-Solving

Practice Interview

Study Questions

Bitwise Operations & Binary Representation

Practice Interview

Study Questions

Algorithm Complexity Analysis

Practice Interview

Study Questions

Modular Arithmetic & Number Theory

Practice Interview

Study Questions

Cryptographic Protocol & System Design

What to Expect

Tips & Advice

Focus Topics

Threat Modeling & Vulnerability Analysis

Practice Interview

Study Questions

Authentication & Integrity Assurance

Practice Interview

Study Questions

Secure Key Exchange & Distribution

Practice Interview

Study Questions

Cryptographic Protocol Design Basics

Practice Interview

Study Questions