Cryptography Quiz

Encryption, hashing, and the cryptographic primitives that keep data confidential and verifiable.

This category currently has 100 questions in the SERVBG quiz bank. Below are a few sample questions — the full interactive quiz shuffles through the whole set with instant scoring.

Sample questions

A developer encrypts each record in a database using AES-GCM with a fixed 96-bit nonce hardcoded in the application. After 2^32 records, what is the primary security failure?

Fixed nonces cause GCM's GHASH polynomial to overflow, producing corrupt ciphertext that decrypts incorrectly.
The 96-bit nonce is too short for AES-256; a 128-bit nonce is required to prevent birthday attacks.
AES-GCM keys wear out after 2^32 encryptions and must be rotated regardless of nonce uniqueness.
Nonce reuse breaks AES-GCM's security guarantees, allowing an attacker to recover the authentication key and potentially recover plaintexts.
After 2^32 records the GCM counter wraps and re-encrypts earlier plaintexts, producing detectable duplicate ciphertexts but no key compromise.

You need an AEAD cipher resistant to nonce misuse. Your threat model includes accidental nonce repetition by distributed services. Which construction is specifically designed for nonce-misuse resistance?

ChaCha20-Poly1305, because its 96-bit nonce space is large enough that accidental repeats are statistically impossible in distributed systems.
AES-OCB3 with a randomly generated 128-bit nonce per message, as OCB's parallelism prevents nonce-reuse attacks.
AES-GCM-SIV, which uses a synthetic IV derived from plaintext and AAD, providing misuse resistance at the cost of not supporting streaming encryption.
AES-256-GCM with a monotonic counter nonce, as counter nonces are guaranteed unique and thus inherently misuse-resistant across distributed nodes.
AES-CBC with HMAC-SHA256 in an Encrypt-then-MAC construction, which is nonce-misuse resistant by design.

A legacy system uses AES-128-ECB to encrypt 16-byte user tokens. An auditor flags this. Which attack directly exploits ECB mode's deterministic block encryption?

IV recovery attacks that extract the implicit initialization vector embedded in the first ECB ciphertext block.
Block pattern analysis: identical plaintext blocks produce identical ciphertext blocks, leaking structural information and enabling chosen-plaintext substitution attacks.
Chosen-key attacks that recover the AES-128 key by comparing pairs of plaintext and ciphertext blocks using meet-in-the-middle techniques.
Padding oracle attacks that exploit PKCS#7 padding validation errors to decrypt arbitrary ciphertexts one byte at a time.
Bit-flipping attacks that flip bits in a ciphertext block to predictably alter the corresponding plaintext block.

An API uses ChaCha20-Poly1305 with a randomly generated 96-bit nonce per message. The service processes 10 billion messages per key. Approximately what is the probability of a nonce collision, and what is the recommended mitigation?

Nonce collisions in ChaCha20-Poly1305 are not exploitable because Poly1305 authentication tags bind each nonce to its ciphertext, preventing reuse attacks.
By the birthday bound, ~10^18 / 2^96 ≈ 1.2×10^-10 collision probability; mitigate by rotating keys well before 2^32 messages or using XChaCha20-Poly1305 with its 192-bit nonce.
Collision probability is negligible because ChaCha20's nonce is derived from a CSPRNG; no mitigation needed below 2^64 messages.
Birthday collisions are irrelevant for 96-bit nonces below 2^48 messages; at 10 billion (≈2^33) messages no mitigation is required under current NIST guidance.
At 10 billion messages the collision risk is ~50%, requiring immediate key rotation; switch to AES-256-GCM which has a larger effective nonce space.

Which property distinguishes AES-OCB from AES-GCM in terms of patent history and adoption barriers, despite OCB having similar or better performance?

OCB was covered by patents held by Philip Rogaway; although royalty-free licenses exist for open-source use, patent uncertainty historically slowed adoption versus the unencumbered AES-GCM.
OCB was withdrawn from the CAESAR competition due to a published forgery attack, making it unsuitable for production use regardless of patent status.
OCB requires a 256-bit key and does not support 128-bit key sizes, making it incompatible with FIPS 140-2 validated modules that mandate AES-128 support.
OCB is not NIST-approved and cannot be used in federal systems, while AES-GCM is mandated by FIPS 197 for all government applications.
OCB lacks authentication of additional data (AAD), making it unsuitable for protocols like TLS that require authenticated headers.

Start the full quiz ›