Mid-Level Cryptographer Interview Preparation Guide for Google

Cryptographer

Google

Mid Level

6 rounds

Updated 6/23/2026

Google's interview process for mid-level technical roles typically consists of an initial recruiter screening, one to two technical phone screens, and four to five onsite interview rounds conducted over one day. The process evaluates technical depth in cryptography, problem-solving ability, system design thinking, security mindset, and cultural fit with Google's collaborative engineering practices. Expect questions ranging from foundational cryptographic concepts to applied implementations, security analysis, and designing cryptographic systems for real-world constraints.

Interview Rounds

Recruiter Screening

30 min4 focus topicsculture fit

Technical Phone Screen 1: Cryptographic Fundamentals

45 min5 focus topicstechnical

What to Expect

First virtual technical interview focused on foundational and applied cryptographic knowledge. An engineer will ask questions about symmetric encryption, asymmetric cryptography, hashing, and their real-world applications. Expect both conceptual questions (e.g., explain the difference between encryption and hashing) and practical scenarios (e.g., how would you securely implement a session token generation system). You may be asked to write pseudocode or discuss implementation details. This round assesses your depth of understanding and ability to articulate cryptographic concepts clearly.

Tips & Advice

Start with clear explanations of core concepts before diving into details. Use concrete examples (e.g., TLS for asymmetric encryption, AES for symmetric). Be ready to discuss when to use each type of encryption and why. Practice explaining the trade-offs between different approaches (e.g., AES-128 vs AES-256, RSA vs Elliptic Curve). If asked to code, focus on correctness and security best practices—use proper libraries, avoid hardcoded keys, and discuss entropy requirements. If you're unsure about a question, ask clarifying questions rather than guessing. Mention relevant standards (NIST, IETF, FIPS) when appropriate. Show awareness of deprecated algorithms (MD5, SHA-1, DES) and why they're no longer acceptable.

Focus Topics

Secure random number generation

CSPRNG, entropy sources, why /dev/urandom is preferred over /dev/random, using cryptographic libraries for randomness, entropy health checks

Practice Interview

Study Questions

Deprecated algorithms and vulnerability awareness

Why MD5, SHA-1, DES, RC4 are no longer acceptable; migration strategies; awareness of current threats

Practice Interview

Study Questions

Hashing and message authentication

SHA-256, SHA-3, HMAC, difference between hashing and encryption, collision resistance, and password storage practices

Practice Interview

Study Questions

Symmetric encryption algorithms and modes

AES, ChaCha20, encryption modes (CBC, GCM, CTR), when to use each, key sizes, and IV/nonce requirements

Practice Interview

Study Questions

Asymmetric encryption and key exchange

RSA, Elliptic Curve Cryptography, Diffie-Hellman, ECDH, public-key infrastructure, and appropriate use cases

Practice Interview

Study Questions

Technical Phone Screen 2: Cryptographic Implementation and Security Analysis

50 min5 focus topicstechnical

What to Expect

Second virtual technical interview diving deeper into cryptographic implementation details, security analysis, and real-world problem-solving. You may review code snippets with cryptographic vulnerabilities, discuss implementation pitfalls, or design a cryptographic system for a specific scenario. Questions might include key management approaches, auditing existing implementations, securing APIs, or analyzing potential side-channel attacks. This round assesses your ability to translate cryptographic theory into secure, practical implementations and identify weaknesses in existing designs.

Tips & Advice

When reviewing code, look for common mistakes: hardcoded keys, using weak randomness, timing vulnerabilities, improper mode of operation, missing authentication, and inadequate key storage. Discuss fixes methodically and explain why each matters. For design questions, follow the SALT framework (Scope, Assets, Layers, Tradeoffs) from the search results: clarify requirements, identify what needs protection, layer defenses (authentication, encryption, monitoring), and discuss performance/security tradeoffs. For key management discussions, reference hierarchical key structures, HSMs, and Shamir's Secret Sharing when appropriate. Be familiar with cryptographic libraries (OpenSSL, libsodium, NaCl, WebCrypto) and their best practices. If asked about side-channel attacks, discuss timing attacks, power analysis, and differential fault analysis at a high level. Show awareness of FIPS and NIST standards.

Focus Topics

Cryptographic protocols for real-world scenarios

TLS/SSL, certificate-based authentication, secure session management, OAuth and OpenID Connect basics, and protocol-level security considerations

Practice Interview

Study Questions

Post-quantum cryptography readiness

NIST post-quantum cryptography standardization, lattice-based cryptography (CRYSTALS-Kyber), quantum-resistant algorithm selection, migration planning

Practice Interview

Study Questions

Common implementation vulnerabilities

Side-channel attacks (timing, power analysis), buffer overflows in crypto code, improper randomness, hardcoded secrets, missing authentication, and mitigation strategies

Practice Interview

Study Questions

Key management system design

Hierarchical key structures, hardware security modules (HSMs), key generation with CSPRNGs, key rotation strategies, backup/recovery procedures, and multi-party authorization

Practice Interview

Study Questions

Auditing and reviewing cryptographic implementations

Algorithm selection and currency, appropriate key sizes, mode of operation correctness, identifying deprecated or vulnerable patterns, and systematic vulnerability assessment

Practice Interview

Study Questions

Onsite Technical Interview 1: Algorithm and Protocol Design

60 min5 focus topicstechnical

What to Expect

First onsite interview focusing on your ability to design and reason about cryptographic algorithms and protocols. You may be asked to design a secure communication protocol, propose an authentication scheme, or outline a cryptographic algorithm for a specific use case. The interviewer will evaluate how you balance security, performance, and practicality. Expect whiteboarding or discussion-based problem-solving where you explain your reasoning, consider threat models, and discuss trade-offs. This assesses your depth in cryptographic theory and design intuition.

Tips & Advice

When designing a protocol, explicitly state your threat model and security goals. Use whiteboarding to sketch out the flow. Discuss each component's security properties. For example, if designing a key exchange, explain why Diffie-Hellman or ECDH protects against eavesdropping but requires authentication. Be prepared to defend your choices and adjust if the interviewer introduces constraints (e.g., low-power devices, high throughput). Show familiarity with established protocols (TLS 1.3, Signal Protocol) and explain what makes them secure. If asked to design something novel, acknowledge when you're approaching unproven territory and what additional analysis would be needed. Use proper cryptographic notation and terminology. Discuss performance implications of your design choices. Be honest about limitations and areas where you'd need to consult research or experts. For mid-level roles, balance innovation with pragmatism—show you can both design new approaches and recognize when to use proven solutions.

Focus Topics

Cryptographic assumptions and mathematical foundations

Understanding the mathematical basis of cryptography (discrete log, factoring, lattice problems), security reductions, and assumptions underlying algorithms

Practice Interview

Study Questions

Zero-knowledge proofs and advanced cryptography

Zero-knowledge proof concepts, applications to privacy-preserving identity systems, practical implementation considerations

Practice Interview

Study Questions

Performance and scalability in cryptographic design

Optimizing for throughput, latency, and resource constraints; understanding trade-offs between security strength and performance

Practice Interview

Study Questions

Authentication systems and mechanisms

Password-based authentication, multi-factor authentication, FIDO2/WebAuthn, certificate-based authentication, and zero-knowledge proofs

Practice Interview

Study Questions

Secure protocol design and threat modeling

Identifying threats, defining security properties, designing protocol flows, and verifying security guarantees against threat models

Practice Interview

Study Questions

Onsite Technical Interview 2: System Design and Applied Cryptography

60 min5 focus topicssystem design

What to Expect

Second onsite technical interview focused on system-level thinking and applying cryptography to complex real-world systems. You may design a secure data protection system for an enterprise, plan cryptographic infrastructure for a distributed service, or improve the security of an existing system at scale. This round evaluates your ability to think about cryptography in context—integrating it with authentication, key management, monitoring, and compliance requirements. You'll discuss trade-offs between security, performance, cost (e.g., HSM vs. cloud KMS), and usability. This is more applied and systems-oriented than algorithm design.

Tips & Advice

Use the SALT framework: Scope (understand requirements—scale, data sensitivity, compliance), Assets (what needs protection), Layers (defense in depth: authentication, encryption, monitoring, audit logs), Tradeoffs (discuss security vs. performance, cost, usability). For enterprise systems, discuss key management explicitly—where keys are generated, stored, rotated, and who has access. Mention monitoring and logging for cryptographic operations. For distributed systems, address data in transit (TLS), data at rest (encryption), and key distribution. Be practical about constraints: a startup can't deploy HSMs everywhere, a financial services company must. Show awareness of compliance (GDPR, HIPAA, SOC 2) and how it influences cryptographic choices. Discuss incident response if keys are compromised. Ask clarifying questions about scale, sensitivity, and timeline. For mid-level engineers, demonstrate experience with architectural decisions, not just implementation. Reference lessons from real projects you've worked on. Be comfortable saying 'we'd need to assess this further' when appropriate, but first offer your reasoning.

Focus Topics

Compliance and standards in cryptography

NIST standards, FIPS 140-2, industry regulations (GDPR, HIPAA, PCI-DSS), and how they influence algorithm selection and key management

Practice Interview

Study Questions

Cryptographic monitoring, auditing, and incident response

Logging cryptographic operations, monitoring for misuse, audit trails, detecting compromised keys, and incident response procedures

Practice Interview

Study Questions

Data protection across system layers

Data encryption at rest (database-level, file-level), in transit (TLS), and in use; choosing algorithms and modes for different layers; balancing security with operational requirements

Practice Interview

Study Questions

Cryptographic system tradeoffs and constraints

Security vs. performance, security vs. cost (HSM vs. software KMS), security vs. usability (MFA friction), regulatory requirements, and resource limitations

Practice Interview

Study Questions

Enterprise cryptographic infrastructure design

Designing secure key management systems at scale, HSM selection and deployment, hierarchical key structures, key lifecycle management, and integrating with cloud services

Practice Interview

Study Questions

Onsite Behavioral and Culture Fit Interview

45 min5 focus topicsbehavioral

What to Expect

Final onsite interview assessing fit with Google's culture, collaboration style, and values. An experienced Google engineer will ask behavioral questions about your experience working in teams, handling disagreements, learning from failures, and contributing to engineering excellence. Expect questions like 'Tell me about a time you mentored a junior engineer', 'Describe a project that failed and what you learned', or 'How do you approach learning new cryptographic techniques'. This round evaluates your communication, growth mindset, collaboration, and alignment with Google's engineering culture. For mid-level candidates, focus on demonstrating ownership, mentoring ability, and continuous learning.

Tips & Advice

Use the STAR method (Situation, Task, Action, Result) for behavioral questions. For a mid-level cryptographer, prepare 3-4 stories demonstrating: (1) owning a non-trivial cryptographic project, (2) mentoring or helping junior engineers, (3) learning something new or dealing with failure, and (4) collaborating cross-functionally or handling disagreement. Be specific with metrics and outcomes when possible. Show genuine interest in security and cryptography—discuss papers you've read, conferences you follow, or personal learning projects. Discuss how you stay current with cryptographic research. Mention specific Google products or security practices you admire. Be authentic and avoid generic answers. Ask thoughtful questions about the team's culture, cryptographic challenges they face, and growth opportunities. For mid-level roles, emphasize that you're ready to take on larger projects and mentor others, not that you're seeking individual contributor work. Discuss balance—yes, security is important, but also shipping products, collaborating with product teams, and practical constraints. Show that you're not just a cryptography purist but understand Google's business needs.

Focus Topics

Google culture and values alignment

Understanding Google's approach to security, research focus, engineering excellence, and openness to different perspectives

Practice Interview

Study Questions

Learning from failure and continuous growth

Projects that didn't succeed as planned, what you learned, how you approached improving, and evolution of your cryptographic expertise over time

Practice Interview

Study Questions

Cross-functional collaboration and communication

Working with product teams, security teams, or other engineers; explaining cryptographic concepts to non-experts; handling disagreement constructively

Practice Interview

Study Questions

Mentoring and developing junior engineers

Instances where you helped junior team members grow, taught cryptographic concepts, or grew someone's security expertise

Practice Interview

Study Questions

Ownership and project leadership

Examples of cryptographic projects you owned end-to-end, decisions you made, challenges faced, and outcomes delivered

Practice Interview

Study Questions

Frequently Asked Cryptographer Interview Questions

Post Quantum Cryptography Transition and AdaptationEasyTechnical

64 practiced

Define the roles and differences between a Key Encapsulation Mechanism (KEM), a public-key Key Exchange (KEX), and a digital signature in the context of post-quantum cryptography. For each, describe where they are used in protocols such as TLS and code signing and how their post-quantum counterparts differ operationally from RSA/ECDSA.

Sample Answer

**Definition & core role**

- Key Encapsulation Mechanism (KEM): asymmetric primitive that encapsulates a symmetric key for a recipient’s public key. Provides key-transport (often IND-CCA security) — sender produces ciphertext + shared secret; recipient decapsulates.- Public‑key Key Exchange (KEX): interactive protocol where two parties jointly derive a shared secret (classic: Diffie‑Hellman). KEX yields forward secrecy when ephemeral keys are used.- Digital signature: provides non‑repudiation, integrity and authenticity by signing messages with a private key; verifier checks with the public key.

**Where used (TLS 1.3, code signing)**

- TLS 1.3: - KEX: used during the handshake to establish ephemeral shared secrets (replaces/augments ECDHE). In PQ TLS this is often implemented via KEMs or KEX hybrids (PQ + classical) to get forward secrecy and quantum resilience. - KEM: often used as a non‑interactive way to deliver an ephemeral session key (encapsulate/decapsulate) or as part of a hybrid KEX. - Signatures: used for certificate authentication and CertificateVerify messages (server/client asserts possession of certificate private key).- Code signing: - Uses digital signatures exclusively to authenticate artifacts; KEM/KEX are not used.

**How PQ counterparts differ operationally vs RSA/ECDSA**

- Primitive choices: PQ KEMs/KEXs use lattice/NTRU/LWE families (e.g., Kyber, NTRU) for key‑encapsulation or KEX; PQ signatures use lattice/hash-based schemes (e.g., Dilithium, Falcon, SPHINCS+).- Key/ciphertext/signature sizes: PQ schemes typically have much larger public keys, ciphertexts or signatures (affects certificate size, network MTU, storage for code signing artifacts).- Performance: often different CPU/memory profiles — some PQ signatures (Dilithium) are fast to verify; hash‑based (SPHINCS+) have large signatures and slower signing.- Forward secrecy model: classical ECDHE is ephemeral DH; many PQ KEMs are non‑interactive and require hybrid designs to retain comparable forward secrecy guarantees and defense-in-depth during migration.- Security assumptions: move from discrete-log/RSA hardness to lattice/LWE/hashing assumptions; implementations must mitigate new side channels and parameter choices.- Interoperability/migration: TLS deployments typically use hybrid KEX (classical + PQ KEM) to combine properties and ease transition; code signing may require new distribution of PQ public keys and larger signatures, and consideration for verifier updates.

As a cryptographer I would design PQ integration focusing on hybrid handshakes for TLS, signing algorithm selection based on verifier constraints (size vs speed), and careful implementation to avoid new failure modes (padding, side channels, chosen‑ciphertext attacks).

Threat Modeling for Cryptographic SystemsHardTechnical

44 practiced

An internal storage product mistakenly reused a CTR-mode keystream across different files due to a nonce generation bug. Analyze the security consequences for confidentiality and integrity, show how an attacker could exploit keystream reuse with a concrete illustrative example (ciphertext XORs), and propose a remediation plan including detection, recovery (re-encryption), and prevention steps.

Sample Answer

**Definition & immediate consequences**- CTR mode: keystream S = AES_K(counter||nonce); reuse of (nonce,counter) across files makes S identical. Confidentiality is severely broken: XOR of two ciphertexts cancels keystream and yields XOR of plaintexts. Integrity/authenticity: CTR is not an authenticated mode — nonce reuse also breaks any attempt to detect tampering; an attacker can flip bits in ciphertext to produce predictable plaintext changes.

**Core formula (keystream reuse)**

text

C1 = P1 XOR S
C2 = P2 XOR S
C1 XOR C2 = P1 XOR P2

Plain-English: XORing two ciphertexts eliminates S, revealing P1 XOR P2.

**Concrete exploit (illustrative)**- Suppose attacker obtains: C1 = 0x6b 0x20 0x3f 0x11 C2 = 0x2f 0x65 0x1b 0x7a- Compute C1 XOR C2 = 0x44 0x45 0x24 0x6b- If attacker guesses segment of P1 = "HTTP" (0x48 0x54 0x54 0x50), XOR with C1 XOR C2 gives candidate P2: P2 = (P1 XOR (C1 XOR C2)) -> recovers bytes; iterative crib-dragging yields both plaintexts.

This is practical: known headers, predictable fields, or language redundancy allow recovery of large portions of P1/P2.

**Forensics & detection**- Scan storage for repeated nonces/counters per key; cluster ciphertexts by detected nonce and length.- Compute pairwise XORs within clusters; high-entropy reduction or presence of ASCII patterns indicates leakage.- Check logs for RNG failures or nonce-generation code paths and firmware versions.

**Recovery / remediation**1. Immediately revoke the affected keys.2. Re-encrypt files with a fresh key and a robust nonce scheme (unique, unpredictable per encryption) after recovering plaintext where possible: - If plaintext recovered fully → verify integrity and re-encrypt. - If partial → try automated crib-dragging and human review; treat unrecoverable data as compromised and follow data breach policy.3. Maintain secure backups; avoid reusing compromised ciphertexts.

**Prevention (design + operational)**- Use a construction that resists nonce misuse: AES-GCM-SIV, SIV mode, or Encrypt-then-MAC with deterministic IV derivation; SIV provides misuse-resistance to nonce reuse.- Derive per-file nonces from a monotonic counter or unique file ID via a KDF: nonce = HMAC_KDF(key2, file_id || counter).- Add authenticated encryption (AEAD). Do not rely on CTR alone.- Harden RNG/nonce code: unit tests, fuzzing, property-based tests verifying uniqueness across scale.- Implement telemetry/alerts for repeated nonces, key usage metrics, and automated rekey workflows.

**Trade-offs**- SIV/deterministic AEAD increases ciphertext size and complexity but eliminates catastrophic leakage on nonce reuse.- Operational changes (rekeying, re-encrypting) are expensive but necessary for confidentiality guarantees.

This plan identifies exposure, enables practical recovery where possible, and prescribes both short-term fixes and long-term cryptographic design changes to prevent recurrence.

Cryptographic Key Management and InfrastructureMediumSystem Design

44 practiced

Design an automated key rotation system for thousands of service keys used by microservices with minimal downtime. Describe the orchestration, how you coordinate atomic key swaps, deal with cached keys and long-lived sessions, implement rollback, and provide safety checks and test strategies to avoid service disruption.

Sample Answer

**Overview & goals**Rotate thousands of service keys with zero/near-zero downtime, cryptographic safety (no key leakage), atomic swap semantics per service, rollback capability, and automated verification.

**Architecture & orchestration**- Central KMS/HSM cluster (FIPS 140-2/3) issues versioned keys K:v. Use key identifiers + v to allow multi-version use.- Orchestrator service (KMS controller + scheduler) coordinates per-environment rollout using canary → staged → global phases.- Each microservice exposes a key-provider API to fetch keys by id+version and to accept a “prepare” then “commit” command from controller.

**Atomic key swap**- Two-phase commit per service: 1. Prepare: controller pushes new K:v+1 to service (validated, cached but not used), service verifies signature and stores as standby. 2. Commit: controller requests atomic switch to v+1; service switches lookup table pointer atomically (CAS or write barrier) so new operations use new key, while in-flight ops continue using previous key handle.- Use versioned key IDs in protocols and AEAD nonces to allow both v and v+1 verification.

**Cached keys & long-lived sessions**- Allow existing sessions to continue with previous key for a bounded grace period (TTL), enforce session-level rekey on next handshake.- For stateful tokens signed with old key, include key version in token; validate against stored public key set; set short expiry for tokens pre-rotation.- Provide online key cache invalidation API; services opportunistically refresh caches.

**Rollback**- Controller can issue revert commit to switch pointer back to previous v atomically; maintain previous keys in HSM for rollback window.- Logs and nonce counters preserved to prevent replay; if nonces overlap, force session termination and rekey.

**Safety checks & tests**- Pre-commit: signature verification, HSM health, KDF checksums, entropy audits.- Canary stage with synthetic traffic & cryptographic integration tests: sign/verify roundtrips, AEAD decrypts, replay-resistance tests.- Chaos tests: force network partitions, HSM failover, rollback drills.- Monitoring: metrics for error rates, verification failures, token rejections; automated abort if thresholds exceeded.

**Cryptographer considerations**- Prefer key derivation (HKDF) to limit key material exposure; rotate symmetric wrapping keys frequently; use asymmetric keys for signing with short-lived symmetric session keys.- Use forward secrecy where possible; log minimal material; enforce strict access policies and M-of-N HSM operations for master key actions.

Secure Protocol Design and ImplementationEasyTechnical

50 practiced

Sketch a simple three-message handshake between a client and a server that achieves mutual authentication and key confirmation using ephemeral Diffie-Hellman and long-term signatures. Describe which transcript elements are signed, how the shared session key is derived at a high level (for example HKDF over DH outputs and nonces), and what replay protection the design uses.

Sample Answer

**Overview (3-message flow)**

- Msg 1 (C → S): C, g^x, nonce_C - Msg 2 (S → C): S, g^y, nonce_S, Sig_S(Transcript2) - Msg 3 (C → S): Sig_C(Transcript3), MAC_Kconfirm("KC")

**What is signed / why**

- Sig_S covers: {S, C, g^x, g^y, nonce_C, nonce_S, role=S} — binds server long-term key to its ephemeral g^y and both nonces. - Sig_C covers: {C, S, g^x, g^y, nonce_C, nonce_S, role=C} — binds client long-term key to the same transcript. Signing the full transcript prevents cut-and-paste between sessions and binds identities, nonces, and ephemeral keys.

**Session-key derivation (high level)**

- Raw DH secret: Z = DH(g^x, g^y) (e.g., x * y on curve) - Derive with HKDF using nonces and transcript as salt/info to ensure domain separation and freshness:

text

SK = HKDF-Extract(salt = nonce_C || nonce_S, IKM = Z)
SessionKeys = HKDF-Expand(SK, info = "handshake" || Transcript, L)

- Split SessionKeys into confidentiality, integrity, and K_confirm keys. The MAC in Msg 3 proves key confirmation (client shows it can derive K_confirm).

**Replay protection & freshness**

- Ephemeral DH values (x,y) provide forward secrecy and ensure per-session randomness. - Nonces prevent replay when ephemeral reuse is possible and serve as HKDF salt. - Signatures bind ephemeral keys and nonces to long-term identities, preventing an attacker from replaying/relaying an old transcript between different peers. - Optional: include short-lived sequence IDs or timestamps in transcript to further limit replay window.

**Key-confirmation**

- Server verifies Sig_C in Msg 3 and verifies MAC_Kconfirm to ensure client actually derived the same K_confirm; client verified Sig_S from Msg 2 earlier. Mutual authentication + key confirmation achieved.

Cryptographic Vulnerabilities and AttacksHardTechnical

57 practiced

Explain the ROCA-style weak key vulnerability where a flawed key generation algorithm produces RSA moduli with predictable structure that allows factoring. Describe how you would detect such weak keys at scale in a large key repository, what mathematical tests or fingerprints to use, and what mitigation and remediation steps should follow detection.

Sample Answer

**Brief summary of the vulnerability**ROCA arises when a deterministic/primes-with-structure generator (Infineon-style) produces primes p that lie in a small subset of residues modulo a fixed integer M: p ≡ r(a) (mod M) where r(a) = g^a mod M for a small set of a. As a result N = p·q can only take a small set of residues modulo M; this massively reduces entropy and enables fast factoring.

**Detection at scale**- Precompute the residue set S = { r(a1)·r(a2) mod M : a1,a2 allowed } for the vulnerable library/version and bit-lengths.- For each modulus N in the repository compute t = N mod M (fast, O(1) per N). If t ∉ S then N is safe from this specific flaw.- Implement as a streaming/batch job: compute N mod M in parallel (multicore/GPU) and test membership via a hash table or Bloom filter for memory efficiency.- Flagged set size is tiny; follow with secondary checks (verify public exponent patterns, certificate metadata, issuer/TPM vendor strings) to reduce false positives.

**Mathematical fingerprint & tests**- Primary test: modular-residue membership- Secondary: check that N bit-length and known library parameters match vulnerable profiles; attempt small-order sieving of N modulo powers of small primes for additional correlation.- Optional: run targeted factoring (Pollard p−1 / ECM) seeded by potential p ≡ r mod M to actually recover p — this converts detection into definitive break.

**Mitigation & remediation**- Treat detected keys as effectively compromised. Prioritize keys in high-risk roles (CA roots, TLS leafs, SSH keys).- Immediate actions: revoke/replace keys, reissue certs, rotate credentials, update software stacks (replace flawed RNG/primality routine).- Investigate generation provenance (TPM firmware, smartcards, vendor builds). Notify affected vendors and customers, publish advisory if needed.- Long term: enforce good key generation policies (CSPRNG, randomized prime search), include repository scanning in CI, and set policy to reject keys from known-bad vendors/firmware.

**Operational notes**- False positives extremely rare if S is correct; always attempt to factor flagged N to confirm.- Complexity: detection O(1) per key; factoring confirmation varies (ECM cost) but is feasible for many flagged keys because reduced search space speeds attacks.

Symmetric Cryptography FundamentalsEasyTechnical

42 practiced

Describe the high-level internal structure of the Advanced Encryption Standard (AES). Cover the following in your explanation: 1) round structure including SubBytes, ShiftRows, MixColumns, AddRoundKey; 2) key schedule basics for 128/192/256-bit keys; 3) the number of rounds and how they relate to key size; 4) why AES is designed as an SPN rather than a Feistel cipher. Keep the explanation high-level (no full code required).

Post Quantum Cryptography Transition and AdaptationMediumTechnical

60 practiced

Quantify the performance impact of replacing ECDSA signatures with a PQ signature (for example Dilithium) on a code-signing server and on devices verifying signatures in a bootloader. What benchmarks would you collect, and what mitigations can you propose for increased signing or verification times and larger signature sizes?

Threat Modeling for Cryptographic SystemsMediumSystem Design

75 practiced

You are assessing an online healthcare records system (mobile clients, API gateway, app servers, DB with encrypted fields, analytics pipeline). Create a threat model emphasizing cryptographic exposure points and possible exfiltration paths, including how analytics-derived metadata can re-identify patients. Outline practical mitigations, verification steps, and indicators of compromise.

Sample Answer

**Scope & assets**- Mobile clients, API gateway, app servers, DB (encrypted fields), analytics pipeline, logs, KMS/HSM, key material, telemetry/metadata.

**Cryptographic exposure points**- In-flight: TLS endpoints (mobile↔gateway, gateway↔apps, apps↔analytics). Risk: misconfigured TLS, weak ciphers, absent mutual auth.- At-rest field encryption: DB encrypted fields (deterministic vs randomized). Risk: deterministic leakage (equality, frequency), poorly separated keys.- Key management: KMS/HSM access, key rotation, backup exports.- Analytics transforms: decrypted data or partially encrypted aggregates in pipeline; cryptographic joins (hashes) used for linking.- Clients: local caches, key material in device storage, insecure key wrapping.

**Exfiltration paths**- Compromised API credentials/Bearer tokens → large downloads of encrypted blobs plus keys via KMS API abuse.- Compromised app server → decrypt-at-rest fields and push to analytics.- Side channels: timing/size of encrypted fields, deterministic-encrypted identifiers reveal frequencies.- Analytics pipeline / third-party BI services → aggregated outputs and metadata leaks (timestamps, cohort IDs).- Logs and telemetry (stack traces, request IDs) containing PHI.

**Metadata re-identification via analytics**- Combinations: timestamp + ZIP + medication history + visit intervals can triangulate individuals.- Deterministic hashes of identifiers allow linkage across datasets.- High-cardinality features (rare diagnoses) act as quasi-identifiers.- Example: analytics bucket shows 1 person with unique combination; cross-reference public registries re-identifies.

**Practical mitigations**- Envelope encryption with HSM-backed KEKs; strict separation KEK<->DEKs; rotate keys regularly; audit KMS.- Field-level randomized (AEAD) encryption for sensitive fields; use deterministic only when strictly needed (and then salt per-tenant).- Use authenticated encryption (AEAD) with associated data (AAD) binding record IDs to context.- TLS with mutual auth + certificate pinning on clients; enforce TLS1.3, forward secrecy.- Minimize plaintext in analytics: perform secure aggregation, differential privacy, or federated analytics; use MPC or HE for joins when feasible.- Tokenization/pseudonymization with token vault; avoid hashing raw identifiers without salts.- Least privilege for services; strict egress filtering; data loss prevention (DLP) on pipelines and logs.- Protect logs & telemetry (redact PHI) and encrypt at rest & in transit.- Device hardening: secure keystore, short-lived tokens, remote wipe.

**Verification steps**- Crypto review: verify use of AEAD (e.g., AES-GCM/ChaCha20-Poly1305), correct nonce handling, key lengths, RNG tests.- Key lifecycle tests: rotation drills, key compromise simulation, HSM access logs correlation.- Threat emulation: red-team exfiltration attempts, misuse of KMS APIs, side-channel probes (size/timing).- Privacy risk assessment: re-identification risk analysis on analytics outputs; run k-anonymity, l-diversity, and differential privacy epsilon evaluations.- Code & config audits: TLS ciphers, certificate chains, client pinning, deterministic encryption usage.- Pen-test analytics pipeline and third-party connectors.

**Indicators of compromise (IOCs)**- Unusual KMS/HSM access patterns (off-hours, multi-region).- Large or abnormal volume of DB reads for encrypted fields, especially followed by KMS GetKey calls.- Spike in aggregated exports or unfamiliar destinations in analytics.- Multiple failed authentication attempts, sudden creation of service principals or roles.- New or modified encryption configs, unexpected key rotations.- Presence of plaintext PHI in logs or unredacted telemetry.- Abnormal latency/size patterns consistent with bulk downloads of encrypted blobs.

**Trade-offs / notes**- Differential privacy reduces utility; MPC/HE increases cost/latency. Prioritize risk-based: high-risk analyses should use private computation; operational telemetry should be minimized and redacted.

Cryptographic Key Management and InfrastructureMediumSystem Design

36 practiced

Design an automated certificate lifecycle system that handles issuance and renewal for internal mTLS certificates and public TLS certificates. Include ACME integration where appropriate, CI/CD hooks, load-balancer and service discovery integration, revocation and emergency reissue handling, and operational metrics to ensure certificate health.

Sample Answer

**Requirements & Threat Model**- Internal mTLS: short-lived leaf certs issued by internal CA with PKI chain; automated rotation.- Public TLS: ACME-capable public CA for internet-facing endpoints.- Goals: automated issuance/renewal, secure key handling, rapid revocation/reissue, LB/service-discovery integration, observable health, defend against key compromise and MITM.

**High-level architecture**- Certificate Authority Layer: Internal CA (HSM-backed or KMS-backed keys) + ACME client module for public certs.- Orchestrator: central certificate-manager service (k8s Operator or standalone) with policy engine (TTL, SANs, allowed principals).- Secret Store: encrypted KMS-backed vault (e.g., HashiCorp Vault) for private keys and certs.- Integration points: CI/CD hooks, LB controllers (Ingress/Envoy/HAProxy), service discovery (Consul/k8s DNS), OCSP stapling responders.

**Flows**- Issuance: Policy -> CSR generation (agent side; key never leaves host if required) -> submit to internal CA or ACME -> store cert+chain in Vault -> push to endpoint via LB/sidecar.- Renewal: watcher checks validity and metrics; renew at safety margin (e.g., 25% lifespan left); ACME challenge automated via LB ACME solver or DNS provider API.- CI/CD: pipeline job calls cert-manager API to request certs for new services; hooks to inject certs into containers/secrets and trigger rolling deploy.- Revocation/emergency reissue: upon compromise, operator issues CRL/OCSP entries; orchestrator forces reissue and pushes new keys; immediate LB/sidecar reload; use short lifetimes to reduce impact.- OCSP/CRL: internal OCSP responder and CRL distribution points; public certs rely on CA OCSP/OCSP stapling at LB.

**Security controls (cryptographer focus)**- Key protection: HSM/KMS for CA keys; ED25519 or ECDSA P-256 for leaf keys where appropriate; AEAD encryption for stored keys.- Key generation: deterministic vs true-random—use CSPRNG; consider hardware RNG and attestations.- Certificate lifetimes: short-lived mTLS certs (hours/days) to limit exposure.- Auditability: signed audit logs of issuance and revocation; threshold signing for CA operations.

**Operational metrics**- Per-cert: days-to-expiry, last-renewal, validity chain status.- System: ACME failure rate, issuance latency, OCSP responder latency, revocation propagation lag, secret-store access errors.- Alerts: expiry < X days, ACME challenge failure rate spike, HSM unavailability.

**Trade-offs**- Short lifetimes reduce revocation needs but increase renewals/operational overhead.- HSM adds assurance but cost/latency; KMS is pragmatic alternative.- Push vs pull distribution: push faster but requires orchestration; pull (agent) simplifies rotation locality.

This design balances cryptographic assurance (HSM, key generation, short lifetimes, audit) with operational automation (ACME, CI/CD hooks, LB/service discovery integration) and supports rapid revocation and measurable certificate health.

Secure Protocol Design and ImplementationMediumTechnical

55 practiced

Describe practical mitigations to prevent protocol version negotiation downgrade attacks, where a man-in-the-middle tries to force the client and server to use an older vulnerable version. Include at least one mechanism used by TLS 1.3 and two additional defense-in-depth strategies an implementer should adopt.

Sample Answer

Situation — I would answer this as a cryptographer responsible for protocol hardening.

Primary TLS 1.3 mechanism- TLS 1.3 binds version negotiation into the authenticated handshake and adds explicit downgrade sentinels: the ServerHello random contains a special 8‑byte pattern when the server selected TLS 1.2 or lower for compatibility. That pattern is then covered by the transcript that feeds the key schedule and Finished MACs/signatures, so any MitM try to suppress a real TLS 1.3 ServerHello will be detected (the client checks the sentinel and the transcript binding).

Additional defense‑in‑depth strategies (implementer actions)- Fallback SCSV / explicit downgrade guards: implement the TLS_FALLBACK_SCSV token (or equivalent) so a client retrying at lower versions signals that it previously attempted a higher version; servers that see it and also support higher versions reject the connection rather than silently accept a downgraded session.- Strict version policy + deprecation/hardening: disable obsolete protocol versions and ciphers in builds; implement configurable minimum-version enforcement and maintain rollout policies (e.g., gradual feature flags, telemetry) so clients/servers refuse connections below policy.- Transcript binding / authenticated negotiation: ensure the negotiated version is included in the handshake transcript that is MACed/signed (for custom protocols: include supported_versions extension and sign the transcript or use an authenticated key‑exchange that binds version fields), preventing undetected on‑the‑wire modification.- Monitoring and telemetry: detect anomalous spikes in legacy‑version usage (indicating active downgrade attempts) and trigger alarms or block IP ranges; correlate with client‑side logs for forensic validation.

Why these work- Downgrade sentinels + transcript binding convert an implicit negotiation into an authenticated, integrity‑protected value. Fallback SCSV and strict policy avoid accidental or attacker‑induced fallbacks. Monitoring gives operational detection and response.

Short concrete takeaways- Rely on TLS 1.3’s authenticated transcript + downgrade sentinel.- Add fallback tokens (SCSV), enforce minimum versions, and bind version in the authenticated transcript.- Combine protocol fixes with operational telemetry and strict configuration for robust protection.

Practice Cryptographer questions across all topics

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

Mid-Level Cryptographer Interview Preparation Guide for Google

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Mentoring and collaboration examples

Practice Interview

Study Questions

Motivation for Google and the specific role

Practice Interview

Study Questions

Career trajectory and cryptography background

Practice Interview

Study Questions

Project ownership and impact

Practice Interview

Study Questions

Technical Phone Screen 1: Cryptographic Fundamentals

What to Expect

Tips & Advice

Focus Topics

Secure random number generation

Practice Interview

Study Questions

Deprecated algorithms and vulnerability awareness

Practice Interview

Study Questions

Hashing and message authentication

Practice Interview

Study Questions

Symmetric encryption algorithms and modes

Practice Interview

Study Questions

Asymmetric encryption and key exchange

Practice Interview

Study Questions

Technical Phone Screen 2: Cryptographic Implementation and Security Analysis

What to Expect

Tips & Advice

Focus Topics

Cryptographic protocols for real-world scenarios

Practice Interview

Study Questions

Post-quantum cryptography readiness

Practice Interview

Study Questions

Common implementation vulnerabilities

Practice Interview

Study Questions

Key management system design

Practice Interview

Study Questions

Auditing and reviewing cryptographic implementations

Practice Interview

Study Questions

Onsite Technical Interview 1: Algorithm and Protocol Design

What to Expect

Tips & Advice

Focus Topics

Cryptographic assumptions and mathematical foundations

Practice Interview

Study Questions

Zero-knowledge proofs and advanced cryptography

Practice Interview

Study Questions

Performance and scalability in cryptographic design

Practice Interview

Study Questions

Authentication systems and mechanisms

Practice Interview

Study Questions

Secure protocol design and threat modeling

Practice Interview

Study Questions

Onsite Technical Interview 2: System Design and Applied Cryptography

What to Expect

Tips & Advice

Focus Topics