Sample questions
Security Cryptography BasicsDifficulty 1
What is the core difference between symmetric and asymmetric encryption?
- aSymmetric encryption can only encrypt text, asymmetric can encrypt any binary data
- bSymmetric uses the same key both ways; asymmetric uses a related key pair✓
- cSymmetric encryption is always weaker and should never be used in production
- dAsymmetric encryption does not require any key at all
Explanation:Symmetric algorithms encrypt and decrypt with the same shared secret key. Asymmetric algorithms use a key pair — a public key for one operation and a mathematically related private key for the other — so no shared secret has to travel between parties.
Security Cryptography BasicsDifficulty 1
What does it mean for a cryptographic hash function to be 'one-way'?
- aRecovering the input from a hash output is computationally infeasible✓
- bThe function can only be run once per input value
- cIt only accepts input in one direction, such as left-to-right byte order
- dThe output can be decrypted back to the input using the same function
Explanation:One-wayness (preimage resistance) means that given a hash output, finding an input that produces it should be computationally infeasible. Hashing has no inverse/decrypt operation, unlike encryption.
Security Cryptography BasicsDifficulty 2
Why is it a mistake to describe password hashing as 'encrypting' the password?
- aBecause hashing is always slower than encryption, so the terms aren't interchangeable performance-wise
- bBecause hash functions require a public/private key pair while encryption does not
- cBecause hashing is one-way with no decrypt step, while encryption is meant to be reversed with a key✓
- dBecause encryption produces fixed-length output while hashing does not
Explanation:Encryption is designed to be reversible: someone holding the correct key can decrypt ciphertext back to plaintext. Hashing has no decrypt counterpart by design, so calling it 'encrypting a password' wrongly suggests a reversal path that shouldn't exist for stored password hashes.
Security Cryptography BasicsDifficulty 1
Encrypting a large multi-gigabyte file directly with an asymmetric algorithm is far slower than using a symmetric algorithm for the same data. Why is asymmetric encryption still used at all in secure communication then?
- aIt isn't — asymmetric encryption is never actually used for real data protection
- bAsymmetric algorithms become faster than symmetric ones once the data exceeds a few hundred megabytes
- cSymmetric algorithms cannot handle binary file formats, only text
- dAsymmetric encryption exchanges a symmetric session key, which then encrypts the bulk data✓
Explanation:Asymmetric operations are computationally expensive relative to symmetric ones, so protocols typically use asymmetric encryption only for a small piece of data — exchanging or wrapping a symmetric session key — then switch to fast symmetric encryption for the actual bulk data. This hybrid approach gets the key-distribution benefit of asymmetric crypto without paying its cost on large payloads.
Security Cryptography BasicsDifficulty 2
Two users pick the identical password. Without salting, their stored password hashes would be identical, making them vulnerable to a precomputed lookup-table attack. What does adding a unique salt per user actually change?
- aIdentical passwords still hash differently per user, since salt is mixed in first✓
- bThe salt encrypts the resulting hash so it can't be reversed at all
- cThe salt replaces the password entirely, so the original password is never hashed
- dThe salt makes the hash function reversible for authorized verification only
Explanation:A per-user salt is combined with the password before hashing, so identical passwords produce different hash outputs across users. This defeats precomputed lookup tables built against unsalted hashes, since an attacker would need a separate table per salt value.
Security Cryptography BasicsDifficulty 1
How does a 'pepper' differ from a 'salt' in password hashing?
- aA pepper is stored alongside each password hash in the same database row, exactly like a salt
- bA pepper is unique per user, while a salt is shared across the whole system
- cA pepper is a separate secret; a salt is stored with the hash and isn't secret✓
- dA pepper replaces hashing entirely, using encryption instead
Explanation:A salt is stored next to the hash and isn't meant to be secret — its job is uniqueness, not confidentiality. A pepper is an additional secret value, typically shared across the system and stored separately (e.g., in application configuration or a secrets manager), so that a database-only breach doesn't expose it.