Q266: Web Crypto Hashing Encryption and Key Handling

What Interviewers Want To Evaluate

Interviewers want to know whether you can talk about browser cryptography without inventing unsafe schemes.

They are checking whether you know when Web Crypto is useful, what it cannot solve, and why key handling is usually the hard part.

They also want to hear practical boundaries: hashing, random values, encryption, signatures, token storage, and server-side trust.

Short Interview Answer

The Web Crypto API gives browsers access to secure random values, hashing, signing, verification, encryption, decryption, and key import/export operations. I use it for well-defined browser-side cryptographic tasks, such as generating random bytes, hashing public data, verifying signatures, or encrypting local data when the key model is clear. I do not invent custom crypto, store high-value keys casually in JavaScript-readable storage, or treat client-side encryption as a replacement for server authorization.

Detailed Interview Answer

Web Crypto is exposed through:

window.crypto
crypto.getRandomValues
crypto.subtle

It is asynchronous for most heavy operations and implemented by the browser.

That is better than hand-written JavaScript cryptography.

But the API being secure does not automatically make the system secure.

The architecture still has to answer:

who creates the key?
where is the key stored?
who can read the key?
when is the key rotated?
what happens on logout?
what happens across devices?
what threat does encryption actually reduce?

Secure Random Values

Use crypto.getRandomValues for browser randomness.

Do not use Math.random for security-sensitive values.

Security-sensitive values include:

state parameters
nonce values
PKCE verifiers
CSRF tokens
temporary secrets
invite codes

Randomness is a foundation.

Weak randomness can break otherwise reasonable protocols.

Hashing

Hashing turns input into a fixed-length digest.

Common uses:

integrity checks
deduplication
cache keys
public fingerprints
non-secret comparisons

Hashing is not encryption.

You cannot "decrypt" a hash.

Also, hashing a low-entropy secret is not automatically safe.

Passwords need slow password hashing on the server, not plain browser SHA-256.

Encryption

Encryption protects data confidentiality only if the key is protected.

Browser-side encryption can help for:

local encrypted drafts
end-to-end encrypted content
temporary protected exports
client-side file preparation

But if the key is stored next to the encrypted data in JavaScript-readable storage, XSS may read both.

That reduces the value of encryption.

Signatures

Signatures prove that data came from a holder of a private key.

Verification can happen in the browser when the browser has the public key.

Use cases:

verify downloaded manifest
verify signed content package
verify challenge response

Do not confuse signatures with secrecy.

Signed data can still be public.

Key Handling

Key handling is usually the hardest part.

Questions:

is the key extractable?
is it stored in IndexedDB?
is it derived from user input?
is it backed by platform credentials?
is it rotated?
is it recoverable?
does logout clear it?

If the answer is vague, the security claim is probably vague too.

Client Crypto Boundaries

Client-side crypto cannot fix:

server authorization bugs
XSS that controls the page
malicious dependencies
phishing
weak account recovery
bad key management

It can still be valuable when the threat model is specific.

For example, end-to-end encryption can protect data from the server, but only if keys are not available to the server.

Interview Example

If asked, "Should we encrypt localStorage?"

Answer:

"Only if we have a meaningful key model. If the encryption key is also stored in localStorage or derived from code shipped to the browser, XSS can likely read both. I would first avoid storing sensitive data there, then consider browser-side encryption only for a clear threat model and key lifecycle."

Common Mistakes

Common mistakes include:

using Math.random for tokens
calling hashes encryption
inventing custom algorithms
storing keys next to encrypted data
assuming client crypto replaces auth
not planning key rotation
not clearing keys on logout
ignoring XSS in the threat model

Senior-Level Framing

The senior framing:

"I use Web Crypto for standard primitives and focus most of the design effort on key ownership, storage, rotation, and threat modeling. Crypto is useful only when the key model matches the risk."

Practice Prompt

Design crypto handling for:

PKCE verifier
signed content manifest
local encrypted draft
download integrity check
end-to-end encrypted note

For each, identify the primitive, key owner, storage location, and failure mode.

Final Mental Model

Web Crypto gives you strong building blocks.

It does not give you a finished security architecture.

The senior question is rarely "can you call the API?"

It is "does your key model make the protection real?"