CEH Cryptography: 35 practice questions

12 of the 35 Cryptography questions in the Certsqill CEH bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CEH? Take the free 5-min readiness check →

1. Symmetric encryption using AES-256: Which approach is MOST appropriate?

1. Symmetric encryption using AES-256 ✓

   Correct. Symmetric encryption (AES) uses a single key for both encryption and decryption and is extremely fast — hardware-accelerated AES can process gigabytes per second, making it ideal for bulk data encryption.
2. Asymmetric encryption using RSA-4096

   Incorrect. RSA is computationally expensive for bulk data — it is typically 1000x slower than AES for the same data volume. RSA is used for key exchange and digital signatures, not bulk data encryption.
3. Hashing using SHA-256

   Incorrect. SHA-256 is a one-way hash function — it cannot decrypt data. Hashing provides integrity verification, not confidentiality protection.
4. Asymmetric encryption using ECC-256

   Incorrect. ECC is more efficient than RSA for asymmetric operations but is still significantly slower than symmetric AES for bulk data encryption. ECC is used for key agreement and digital signatures.

Symmetric encryption (AES-256) is the right choice for bulk data at rest — it is orders of magnitude faster than asymmetric encryption for large data volumes.

2. Certificate Authority and the certificate chain: Which PKI component provides the chain of trust that allows t

1. Certificate Authority (CA) and the certificate chain (root CA → intermediate CA → server certificate) ✓

   Correct. The CA hierarchy provides the chain of trust. The browser validates the server certificate by verifying the signature of the issuing intermediate CA, then the intermediate CA's certificate against the root CA, which is pre-trusted in the browser's trust store.
2. The server's private key stored securely on the web server

   Incorrect. The server's private key proves ownership of the certificate during the TLS handshake (via key exchange), but it is not the source of the chain of trust — the CA signatures provide the trust chain.
3. OCSP (Online Certificate Status Protocol) server

   Incorrect. OCSP checks whether a specific certificate has been revoked. It verifies currency/revocation status, not the original authenticity of the certificate. OCSP is one step in certificate validation, not the source of the chain of trust.
4. The server's public key embedded in the certificate

   Incorrect. The server's public key is what's being certified. The CA's signature on the certificate vouches for the public key's association with the server. The public key itself does not establish the chain of trust.

The PKI chain of trust flows from a pre-trusted root CA through intermediate CAs to the server certificate. The browser validates each signature in the chain against its built-in root CA trust store.

3. Known-plaintext attack: What type of cryptanalytic attack is this?

1. Known-plaintext attack (KPA) ✓

   Correct. A known-plaintext attack uses pairs of known plaintext and the corresponding ciphertext to deduce the key or algorithm. The attacker has both plaintext and ciphertext but did not choose the plaintext.
2. Chosen-plaintext attack (CPA)

   Incorrect. In a chosen-plaintext attack, the attacker can choose which plaintexts get encrypted and observe the resulting ciphertexts. In the described scenario, the attacker only has samples — they did not choose the messages.
3. Ciphertext-only attack (COA)

   Incorrect. A ciphertext-only attack uses only ciphertext samples with no corresponding plaintexts. The described attacker has both — ruling out COA.
4. Differential cryptanalysis

   Incorrect. Differential cryptanalysis is a chosen-plaintext technique that studies how differences in plaintext affect differences in ciphertext to reveal key information. It is a specific algorithm-analysis technique, not the general category described.

Known-plaintext attacks use known plaintext/ciphertext pairs to deduce the encryption key. The analyst has matching pairs but did not choose the plaintexts.

4. SSL stripping: What is the attacker doing, and what control would prevent this attack?

1. SSL stripping — downgrading HTTPS to HTTP by intercepting the redirect; HSTS (HTTP Strict Transport Security) with preloading prevents this ✓

   Correct. SSL stripping intercepts the initial HTTP→HTTPS redirect, making the attacker-victim connection HTTP while maintaining HTTPS to the server. HSTS instructs browsers to always use HTTPS, refusing HTTP connections — preventing the downgrade.
2. Certificate spoofing — presenting a fake SSL certificate; certificate pinning prevents this

   Incorrect. Certificate spoofing replaces the server's certificate with a fake one — browsers show certificate warnings. SSL stripping removes HTTPS entirely rather than spoofing the certificate.
3. DNS hijacking — redirecting the domain to an attacker-controlled IP; DNSSEC prevents this

   Incorrect. DNS hijacking changes which server the victim connects to. SSL stripping operates at the protocol layer between an already-connected victim and server — DNS is not manipulated.
4. SSL inspection — the attacker acts as a transparent proxy; mutual TLS (mTLS) prevents this

   Incorrect. SSL inspection (man-in-the-middle TLS proxy) maintains HTTPS connections on both sides while decrypting in the middle — the victim sees HTTPS, not HTTP. SSL stripping specifically downgrades to HTTP.

SSL stripping removes HTTPS by intercepting HTTP→HTTPS redirects in a MITM position, serving HTTP to the victim while maintaining HTTPS to the server. HSTS preloading prevents downgrade by enforcing HTTPS in the browser.

5. Collision resistance: What cryptographic property of MD5 has been broken, and why is this a security concern f

1. Collision resistance — an attacker can substitute a malicious document that shares a hash with the legitimate one, forging a digital signature ✓

   Correct. A collision means two different messages have the same hash. If a digital signature signs a hash, an attacker can craft a malicious document with the same MD5 hash as the signed legitimate document — the signature validates both.
2. Pre-image resistance — the attacker can reverse the hash to recover the original plaintext

   Incorrect. Pre-image resistance means it's computationally infeasible to find an input that produces a specific hash. MD5 collision attacks produce two DIFFERENT inputs with the SAME hash — this is a collision attack, not a pre-image attack.
3. Avalanche effect — small changes in input no longer produce large changes in output

   Incorrect. The avalanche effect is about output sensitivity to small input changes. MD5's collision vulnerability is that different inputs produce the same output — unrelated to the avalanche effect property.
4. Key derivation — the hash cannot be used to derive cryptographic keys

   Incorrect. Key derivation is a function of key derivation functions (PBKDF2, bcrypt) — not a property of basic hash functions. MD5's security concern is collision resistance failure, not key derivation.

MD5's broken collision resistance means two different documents can have the same hash — allowing signature forgery by substituting a malicious document with the same MD5 as a legitimately signed one.

6. LSB steganography: What does this indicate, and what tool could have created this?

1. LSB steganography — tools like Steghide or OpenStego embed data in LSBs, creating detectable patterns when the LSB distribution is more uniform than natural images ✓

   Correct. LSB steganography replaces pixel LSBs with message bits, creating an artificially uniform LSB distribution. Natural images have LSBs clustered around certain values; embedded data creates pseudo-random LSB patterns detectable by chi-squared analysis.
2. Image compression artifacts — JPEG compression causing statistical anomalies in PNG images

   Incorrect. PNG uses lossless compression and would not have JPEG compression artifacts. LSB distribution anomalies in PNG images are more indicative of steganographic embedding than compression.
3. Digital watermarking by the camera manufacturer

   Incorrect. Camera manufacturer watermarks are typically embedded in EXIF metadata or use DCT-based watermarking, not LSB manipulation. LSB anomalies specifically suggest active data embedding.
4. File format corruption — the PNG was saved incorrectly by the originating software

   Incorrect. File format corruption would cause random errors across multiple data fields, not a systematic statistical anomaly in the LSB distribution specifically.

LSB steganography creates detectable statistical patterns in image LSBs. Chi-squared analysis and RS analysis detect the pseudo-random LSB distribution created by data embedding tools like Steghide.

7. Perfect Forward Secrecy: What security property does this provide that RSA key exchange (used in older TLS ver

1. Perfect Forward Secrecy (PFS) — if the server's long-term private key is compromised, previously captured encrypted sessions cannot be decrypted ✓

   Correct. DHE/ECDHE generates a new ephemeral key pair for each session. Session keys are not derived from the long-term private key — compromising the server certificate private key cannot decrypt past sessions.
2. Stronger encryption — DHE uses 2048-bit keys compared to RSA's 1024-bit keys

   Incorrect. Key length is a separate security property from forward secrecy. RSA can use 4096-bit keys — key length is not the differentiating property. PFS (session key independence from long-term keys) is what DHE provides that RSA key exchange doesn't.
3. Faster handshake — DHE reduces round-trip time compared to RSA key exchange

   Incorrect. DHE key exchange is computationally more expensive than RSA key exchange for the same security level. Performance is not the reason TLS 1.3 mandates DHE — PFS is the security driver.
4. Mutual authentication — both client and server verify each other's identity

   Incorrect. Mutual authentication is provided by client certificates (mTLS) — independent of whether DHE or RSA is used for key exchange. Certificate-based authentication provides identity verification regardless of key exchange method.

DHE/ECDHE key exchange provides Perfect Forward Secrecy: each session uses ephemeral keys not derivable from the server's long-term private key, so past sessions remain secure even after key compromise.

8. The AES key is encrypted with RSA using the attacker's: Why is this design resistant to decryption without the

1. The AES key is encrypted with RSA using the attacker's PUBLIC key — decryption requires the attacker's PRIVATE key, which only the attacker possesses ✓

   Correct. RSA public-key encryption: only the corresponding private key can decrypt. Since only the attacker has the private key, the AES key (and thus the files) cannot be recovered without the attacker's private key or an implementation flaw.
2. AES-256 is considered theoretically unbreakable, making brute-force infeasible

   Incorrect. While AES-256 brute-force is computationally infeasible, this is not the primary reason for ransomware's resistance to decryption. The critical protection is the RSA-encrypted AES key — even if AES-256 were weaker, the RSA layer would still protect the key.
3. The files are also compressed before encryption, preventing pattern analysis

   Incorrect. Compression before encryption is a common ransomware technique for efficiency but is not the reason decryption is impossible without the private key. The asymmetric key protection of the AES key is the fundamental barrier.
4. The ransomware deletes the Volume Shadow Copies (VSS), preventing recovery from backups

   Incorrect. VSS deletion prevents recovery from Windows backups — it is a separate persistence/anti-recovery technique. The decryption resistance specifically for the encrypted files requires the attacker's RSA private key.

Ransomware uses hybrid encryption: AES for file encryption (speed), RSA to protect the AES key. Since only the attacker's RSA private key can decrypt the AES key, victims cannot recover files without the attacker's key or an implementation flaw.

9. DS record, which contains a hash of the child zone's Key: Which DNSSEC record type establishes the link betwee

1. DNSKEY record, which contains the zone's public signing key published in the .com zone

   Incorrect because the DNSKEY record is published in the corp.com zone itself, not in the parent .com zone. The parent zone does not publish the child's DNSKEY directly.
2. DS (Delegation Signer) record, which contains a hash of the child zone's Key Signing Key (KSK) and is published in the parent .com zone ✓

   Correct because the DS record creates the parent-child chain of trust. The .com zone publishes a DS record containing a cryptographic hash of corp.com's KSK. A resolver can validate corp.com's DNSKEY by checking that its hash matches the DS record signed by the .com zone.
3. NSEC record, which lists all authoritative records in the corp.com zone for authenticated denial of existence

   Incorrect because NSEC (Next Secure) records provide authenticated denial-of-existence for non-existent records within a zone — they do not establish cross-zone chain of trust.
4. SOA record with the DNSSEC extension bit set, indicating the zone is signed

   Incorrect because the SOA (Start of Authority) record identifies the primary DNS server and zone serial number; it does not carry DNSSEC key material or delegation trust information.

The DS record in the parent zone (.com) contains a hash of the child zone's KSK, establishing the DNSSEC chain of trust between parent and child zones.

10. In AES-CBC, each plaintext block is XORed: What property of CBC mode makes this attack possible?

1. AES-CBC uses the same key for all blocks, allowing the attacker to derive the key by observing multiple ciphertexts

   Incorrect because this describes a related-key or chosen-plaintext attack. CBC bit-flipping exploits the XOR relationship between the IV/previous ciphertext block and the current plaintext — key derivation is not involved.
2. In AES-CBC, each plaintext block is XORed with the previous ciphertext block before encryption; flipping bits in the previous ciphertext block causes predictable inversions in the corresponding decrypted plaintext block ✓

   Correct because CBC decryption XORs the decrypted block with the previous ciphertext block to recover plaintext. If the attacker flips bit N in ciphertext block C[i-1], bit N in plaintext block P[i] is correspondingly flipped after decryption. By computing XOR differences, the attacker can modify specific plaintext bytes without knowing the key — at the cost of corrupting block C[i-1] to garbage.
3. AES-CBC has a weak initialisation vector that can be predicted from the ciphertext, allowing the attacker to replay previous sessions

   Incorrect because this describes IV prediction/reuse vulnerabilities. Bit-flipping does not require predicting the IV — it manipulates arbitrary ciphertext blocks using the XOR chaining property.
4. AES-CBC uses ECB mode internally for each block, making identical plaintext blocks produce identical ciphertext blocks that the attacker can rearrange

   Incorrect because AES-CBC explicitly prevents identical blocks from producing identical ciphertext (that is the ECB weakness that CBC addresses). Bit-flipping is a separate property of the XOR chaining mechanism.

AES-CBC bit-flipping exploits the XOR relationship between ciphertext and plaintext — flipping bits in block C[i-1] causes predictable inversions in decrypted block P[i], enabling controlled plaintext modification.

11. SHA-256 is based on the Merkle-Damgård construction: What property of SHA-256 makes this possible?

1. SHA-256 uses a linear key schedule that allows key recovery after observing 10 messages

   Incorrect because SHA-256 does not use a key schedule — it is a hash function, not a cipher. Key schedule vulnerabilities are specific to block ciphers like DES. Hash length extension attacks exploit a different structural property.
2. SHA-256 is based on the Merkle-Damgård construction; the hash output represents the internal state after processing, allowing an attacker to continue hashing from that state without knowing the secret prefix ✓

   Correct because Merkle-Damgård hash functions (MD5, SHA-1, SHA-256) expose their internal state in the final hash output. Given H(secret || message), an attacker can set their internal state to H's value and continue hashing additional data, producing a valid hash for (secret || message || padding || extension). The attacker does not need to know the secret.
3. SHA-256 has collision resistance weaknesses that allow two different messages to produce the same hash

   Incorrect because hash collisions (finding two inputs with the same hash) are a different attack from length extension. SHA-256 has no known practical collision attacks. Length extension exploits state resumption, not collision.
4. The concatenation order (key || message) is vulnerable to timing attacks because the key is processed first

   Incorrect because timing attacks exploit processing time differences in comparisons, not hash construction. The order (key || message) is specifically vulnerable to length extension because the key becomes part of the initial Merkle-Damgård state that is continued.

SHA-256's Merkle-Damgård construction exposes the internal state in the output hash, allowing attackers to append data and compute a valid forged MAC without knowing the secret prefix.

12. OCSP Stapling has the web server pre-fetch and cache: Comparing OCSP and CRL, which statement about OCSP Stapl

1. OCSP Stapling requires the client to contact the CA's OCSP responder for each TLS connection, increasing latency and revealing browsing history to the CA

   Incorrect because this describes regular OCSP (without stapling). OCSP Stapling is specifically designed to eliminate the need for the client to contact the OCSP responder — that is its primary benefit.
2. OCSP Stapling has the web server pre-fetch and cache a signed OCSP response from the CA, presenting it to clients during the TLS handshake — eliminating the client's need to contact the OCSP responder and protecting browsing privacy ✓

   Correct because with OCSP Stapling, the web server periodically fetches and caches a CA-signed OCSP response for its own certificate. During the TLS handshake, the server 'staples' this response to the Certificate message. Clients receive real-time revocation status without connecting to a third-party OCSP server, reducing latency and preserving client privacy.
3. CRL is superior to OCSP because it provides real-time per-certificate revocation status whereas OCSP only provides batch updates

   Incorrect because this inverts the comparison. CRL is a periodic batch download of all revoked certificates — it is not real-time. OCSP provides per-certificate real-time status checks. CRL has scalability issues as the list grows; OCSP is more efficient for individual certificate checks.
4. OCSP Must-Staple prevents the OCSP Stapling attack where an attacker strips the stapled response to make revoked certificates appear valid

   Partially correct information but the statement describes OCSP Must-Staple (a certificate extension, not OCSP Stapling itself). The question asks specifically what OCSP Stapling is most accurately — the correct answer describes the stapling mechanism itself.

OCSP Stapling has the server cache and deliver CA-signed OCSP responses during TLS handshake, eliminating client OCSP lookups and protecting user privacy.

Other CEH domains

• Web Application Hacking — 100 questions →
• System Hacking Phases and Attack Techniques — 96 questions →
• Reconnaissance Techniques — 84 questions →
• Network and Perimeter Hacking — 81 questions →
• Mobile Platform, IoT, and OT Hacking — 38 questions →
• All 498 CEH questions →