Applied Cryptography Check

Your application encrypts millions of files, each with a unique Data Encryption Key (DEK). The DEKs are encrypted by a master Key Encryption Key (KEK) stored in a KMS. When the KEK is rotated, what must be re-encrypted? All files must be decrypted and re-encrypted with new DEKs Only the DEKs — each DEK is re-encrypted with the new KEK, but the files themselves are untouched Nothing — the old KEK continues to decrypt existing DEKs while the new KEK is used for new files The KMS handles re-encryption automatically and no action is needed

Envelope encryption separates key management from data encryption. The KEK encrypts the DEKs, not the data. When the KEK rotates, you re-encrypt each DEK with the new KEK — a fast operation on small keys. The underlying files, encrypted with their individual DEKs, never need to be touched. Option C describes a valid operational strategy (sometimes called "key versioning") but does not address the re-encryption question. Option D assumes capabilities that depend on the specific KMS implementation and deployment.

A user registers a passkey on their phone for a banking website. An attacker creates a convincing phishing site at a similar domain and tricks the user into attempting to log in. What prevents the attacker from capturing a valid authentication assertion? The passkey is protected by the phone's biometric sensor and cannot be used without a fingerprint The passkey is encrypted in the phone's secure enclave and cannot be exported The authenticator signs over the requesting origin — the phishing domain does not match the relying party the credential was registered with, so no valid assertion is produced The browser detects the phishing domain and blocks the WebAuthn API call

WebAuthn's phishing resistance comes from origin binding. The authenticator includes the origin (the full domain) in the data it signs. A credential registered for `https://bank.example.com` will not produce a valid assertion for `https://bank-example.com` — the origins do not match. Biometric protection (A) prevents unauthorized local use but does not address phishing. Secure enclave storage (B) protects the private key but is not the mechanism that defeats phishing. Browser phishing detection (D) exists but is heuristic-based and bypassable — origin binding is cryptographic and absolute.

A zero-knowledge proof system has completeness and soundness but lacks the zero-knowledge property. What can go wrong? A dishonest prover can convince the verifier of a false statement An honest prover will sometimes fail to prove a true statement The verifier learns information about the prover's secret beyond the truth of the statement The proof cannot be converted from interactive to non-interactive

The zero-knowledge property specifically guarantees that the verifier learns nothing beyond the statement's truth. Without it, the proof transcript may leak information about the witness (the secret). Completeness ensures honest provers succeed (so B describes a completeness failure). Soundness ensures dishonest provers fail (so A describes a soundness failure). The Fiat-Shamir transformation (D) is a separate technique unrelated to the zero-knowledge property.

An organization is planning its post-quantum cryptography migration. Which class of currently deployed algorithms does Shor's algorithm break? Symmetric ciphers like AES-256 and ChaCha20 Hash functions like SHA-256 and SHA-3 Message authentication codes like HMAC-SHA-256 Public-key algorithms based on integer factorization and discrete logarithms — RSA, ECDH, ECDSA, EdDSA

Shor's algorithm efficiently solves integer factorization and the discrete logarithm problem, breaking RSA (factoring), Diffie-Hellman (discrete log in finite fields), and elliptic curve cryptography (discrete log on curves). Symmetric ciphers, hash functions, and MACs are affected by Grover's algorithm, which provides only a quadratic speedup — manageable by doubling key sizes. The post-quantum migration primarily targets the replacement of public-key algorithms with lattice-based (ML-KEM, ML-DSA) or hash-based (SLH-DSA) alternatives.

A web application verifies API request signatures by comparing the received HMAC tag to the expected tag using a standard byte-by-byte equality check that returns `false` at the first mismatched byte. What attack does this enable? A replay attack — the attacker resubmits a previously valid request A padding oracle attack — the attacker learns whether decryption padding is valid A timing attack — the attacker measures response times to determine the correct tag byte by byte A length extension attack — the attacker appends data to the message without knowing the key

An early-exit byte comparison leaks timing information: a tag with the first byte correct takes slightly longer to reject than one with the first byte wrong. By measuring response times across many requests, an attacker determines each byte of the correct tag sequentially — reducing a 2^128 brute-force attack to roughly 256 * 16 = 4,096 guesses for a 16-byte tag. The fix is constant-time comparison (e.g., `hmac.compare_digest()` in Python or `crypto/subtle.ConstantTimeCompare()` in Go), which processes all bytes regardless of match status.