Google Cryptography, PKI & TLS interview questions

The most common screen question in security. The answer that scores sorts all four by one property: whether there is a key, and who holds it.

The trap is answering 'which is better'. Every protocol you use daily runs both, each doing the job the other cannot.

Message names are table stakes. The interviewer is listening for why CertificateVerify exists and what Finished actually checks.

Checking the signature is one step of seven. The bugs that matter live in the other six, and in code that switches validation off.

SHA-256 with a salt sounds right and fails. The answer that scores explains the attacker's economics and names the parameters.

Both detect tampering. The difference is who else could have made the tag, and that decides webhooks, tokens and audit evidence.

The question behind the question: if your server's private key leaks next year, what happens to the traffic someone recorded today?

'Yes, always' is the right default and the wrong answer. The interviewer wants the list of attackers it does nothing against.

Encryption without integrity has been exploited for decades. Nonce reuse under GCM is worse than most candidates think: it breaks integrity too.

Data keys, key-encryption keys, tenant isolation, rotation and crypto-shredding. The design is standard; the trade-offs at each level are the interview.

mTLS authenticates both ends, but only as well as your private CA and identity scheme. The scored answer designs issuance, identity, rotation and authorisation, and contrasts it with the public web.

Any trusted CA can issue a certificate for your domain. The scored answer explains how public logs make that visible and how to turn the logs into an alert.

Revocation asks every client to check a third party on every connection, and most clients quietly do not. The scored answer explains each mechanism's failure mode and why the industry is moving to short lifetimes.

A classic that tests whether you know how hash functions work inside. The scored answer explains length extension, the nested HMAC construction, and how to verify a MAC safely.

Encryption hides content, not length. The scored answer shows how compression turns length into a leak when secrets and attacker text share a message, and where that bites today.

Most cryptographic failures are misuse of good primitives, not broken algorithms. The scored answer has a checklist that catches the common ones and a strong default to replace them.

Cryptography assumes unpredictable numbers, and real systems have repeatedly failed to supply them. The scored answer gives the causes, the famous failures, and the rules that prevent repeats.

Both keep keys out of application memory; they differ in who you must trust and what you can prove. The scored answer chooses by threat model and requirement, not by fashion.

Encryption at rest is the easy part; weights must be decrypted somewhere to be used. The scored answer controls where decryption happens, who can cause it, and how fast misuse is noticed.

Trusted execution moves the trust boundary from the operator to the hardware and the attested code. The scored answer is precise about what that protects, what it assumes, and what it leaves open.

Using one key for several purposes quietly couples their security. The scored answer explains extract and expand, shows key separation by context, and says when HKDF is the wrong tool.

Data encrypted today can be recorded and decrypted when a capable quantum computer exists. The scored answer prioritises by how long data must stay secret, starts with key exchange, and builds crypto agility.

A small root hash that commits to millions of entries. The scored answer builds an inclusion proof, explains consistency proofs, and names the systems that depend on them.

TLS protects bytes on the wire between two endpoints. The scored answer lists what lies outside that boundary, so nobody mistakes 'we use HTTPS' for a security design.

The response differs sharply between a signing key and an encryption key. The scored answer contains use, rotates, revokes trust, assesses what the attacker could forge or read, and repairs what depended on it.

Preimage, second preimage and collision resistance sound alike and protect different things. The birthday bound explains why the last one costs half the bits.

Issuing a certificate is easy. Knowing every certificate you issued, renewing them before they expire, and surviving the day a CA key leaks is the design.

Being able to switch algorithms is essential. Letting an attacker choose which algorithm you switch to is a vulnerability with a long history.

Most candidates can recite TLS 1.3. Interviewers ask for 1.2 because it is still everywhere, and because every change in 1.3 is the fix for an attack on 1.2.

A certificate is a signed statement with a short list of claims: this key, these names, these uses, this period, issued by this CA. Every validation failure you have seen is one of those claims not holding.

There is no single list of trusted roots. Browsers, operating systems, language runtimes and container images each carry their own, updated on their own schedules, and production outages follow from the differences.

Domain-validated certificates prove one thing: whoever asked could answer a challenge on that domain at that moment. Every attack on issuance is a way to answer that challenge without owning the domain.

Mutual TLS proves who connected to whatever terminated the TLS. If that is a load balancer, the application only knows what a header tells it, and headers can be forged.

An HSM's promise is narrow and strong: the key cannot leave in plaintext. Everything else, including who may ask the HSM to use the key, is your design.

They all promise 'hardware security'. They protect different things from different attackers, and choosing well means knowing who you are defending against.

OpenSSL is two libraries and a command-line tool. Most TLS failures blamed on it are applications that never asked it to check the hostname, or told it to stop checking at all.

A certificate is a CA's signature over a structured statement about your key. Each step from key to padlock exists to stop one specific lie.

The root key is the one thing you can never easily replace, so it signs almost nothing. Everything about intermediates follows from that.