Sample questions
As Crypto Implementation PitfallsDifficulty 1
Why is reusing the same IV (initialization vector) with the same key in CBC mode a security problem?
- aIt slows down encryption because the cipher has to recompute the key schedule
- bIt causes the ciphertext to be shorter than the plaintext, breaking the format
- cIt only affects decryption speed, not confidentiality
- dIdentical plaintext blocks encrypted under the same key/IV pair produce identical ciphertext blocks, leaking structure✓
Explanation:The IV is meant to randomize the first block's input so that identical plaintexts encrypt differently each time. Reusing the same IV with the same key removes that randomization, so an attacker who sees two ciphertexts produced under the same key/IV pair can detect when the underlying plaintext blocks matched.
As Crypto Implementation PitfallsDifficulty 1
Why is ECB (Electronic Codebook) mode considered unsafe for encrypting most real-world data?
- aECB mode requires a separate key for every block, making key management unmanageable
- bEach plaintext block is encrypted independently, so identical blocks always produce identical ciphertext, revealing patterns✓
- cECB mode cannot be implemented with AES, only with legacy ciphers like DES
- dECB mode always doubles the size of the output ciphertext compared to the input
Explanation:ECB encrypts each fixed-size block independently with no chaining or randomization, so identical plaintext blocks always map to identical ciphertext blocks. This lets an attacker who only sees ciphertext infer structural patterns in the original data, which is why the classic 'encrypted image still shows the outline' example illustrates the flaw.
As Crypto Implementation PitfallsDifficulty 1
A developer hardcodes an AES encryption key as a string literal directly in the application source code. What is the main risk?
- aAES keys stored as string literals are automatically truncated by most compilers
- bAnyone with access to the source code or compiled binary can extract the key and decrypt all protected data✓
- cHardcoded keys make the encryption algorithm run slower than reading from a config file
- dThe application will fail to compile because encryption keys cannot be represented as strings, and most languages reserve string literals exclusively for user-facing text.
Explanation:A key embedded in source code is not a secret — it ships with every copy of the code or binary, is visible in version control history, and can be extracted by anyone who can read or decompile the artifact. Keys belong in a secrets manager or KMS, not in source.
As Crypto Implementation PitfallsDifficulty 1
A team encodes sensitive data with Base64 before storing it and calls this 'encrypting' the data. What is wrong with this claim?
- aBase64 is a reversible encoding with no secret key involved, so anyone can decode it back to plaintext without needing a key✓
- bBase64 output cannot be stored in a text-based database column
- cBase64 is only reversible if the original data was already encrypted first
- dBase64 changes the byte length of the data, which technically counts as encryption
Explanation:Base64 is an encoding scheme for representing binary data as text — it has no key and no confidentiality goal. Anyone who sees Base64 text can decode it in one line, so it provides zero protection against disclosure, unlike encryption which requires a secret key to reverse.
As Crypto Implementation PitfallsDifficulty 2
Why should encryption keys and session tokens be generated using a cryptographically secure pseudo-random number generator (CSPRNG) instead of a standard library random function like Math.random()?
- aStandard PRNGs optimize for statistical distribution, not unpredictability, so attackers can sometimes predict their output.✓
- bCSPRNGs always produce shorter output than standard PRNGs, saving storage
- cStandard library random functions cannot generate numbers larger than 32 bits
- dCSPRNGs are required by law in most countries for any application handling user data
Explanation:General-purpose PRNGs like Math.random() optimize for speed and statistical distribution, not for resistance to prediction. Some are seeded or implemented such that observing enough output (or the seed) lets an attacker predict future values, which is catastrophic if that output becomes a session token or key. CSPRNGs are specifically designed so past output gives no advantage in predicting future output.
As Crypto Implementation PitfallsDifficulty 2
Two parties need to establish a shared symmetric key over an untrusted network without ever having met in person. Which approach solves this securely?
- aOne party picks a symmetric key and sends it in plaintext, relying on the network being 'probably safe'
- bEncode the key with Base64 before transmitting it so only technical staff can read it
- cBoth parties independently generate the same key by hashing the current date, since both clocks are synchronized
- dUse asymmetric cryptography to encrypt the symmetric key with the recipient's public key, or perform a key-exchange protocol like Diffie-Hellman✓
Explanation:Because asymmetric encryption only requires the recipient's public key (which can be shared openly), it lets a sender protect a symmetric key in transit without a prior shared secret. Key-exchange protocols like Diffie-Hellman achieve the same goal by letting both sides derive a shared secret without ever transmitting it directly.