Cryptography practice questions

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Why it fails: DHE provides forward secrecy but RSA certificates are larger, and CBC mode is slower than GCM.

TLS_RSA_WITH_AES_128_CBC_SHA256

Why it fails: RSA key exchange lacks forward secrecy, and CBC mode is less efficient than GCM.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Why it fails: This is also strong but uses RSA certificates, which are larger than ECDSA for equivalent security.

SHA-1

Why it fails: SHA-1 is deprecated and susceptible to collision attacks.

MD5

Why it fails: MD5 is broken due to collision attacks.

HMAC-SHA256

Why it fails: HMAC is a message authentication code, not a hash function.

3DES

Why it fails: 3DES is a block cipher.

AES-GCM

Why it fails: AES-GCM is a block cipher mode, not a stream cipher.

ChaCha20

Why it fails: ChaCha20 is a modern stream cipher considered secure.

The receiver uses the sender's private key to verify the signature.

Why it fails: The private key is never shared; verification always uses the public key.

The sender encrypts the entire document with their public key to create a signature.

Why it fails: Encrypting the entire document with the public key would not produce a signature; signatures involve the hash and private key.

Software-based key store with AES-256 encryption

Why it fails: A software-based key store, even with strong encryption, is vulnerable to memory scraping, debugging, and side-channel attacks if the host is compromised. It does not provide hardware-based key generation or tamper-resistant storage. The requirement for protection against extraction even if the host is compromised cannot be met by software alone.

Key Management Interoperability Protocol (KMIP) server

Why it fails: KMIP is a protocol for key management interoperability, not a hardware-based key storage technology. A KMIP server may use HSMs for backing storage, but KMIP itself does not provide hardware-based key generation or tamper-resistant storage. It is a communication standard, not a security module.

Trusted Platform Module (TPM)

Why it fails: A TPM is a hardware chip that provides secure key storage and cryptographic operations, but it is typically bound to a single host and not designed for centralized key management or high-volume key generation. While it protects keys from software attacks, it may not meet the requirement for a dedicated, tamper-resistant hardware module for enterprise key storage.

Keyed hash (HMAC) construction

Why it fails: HMAC adds a secret key to the hash, providing authentication of the source in addition to integrity. However, the scenario only asks about detecting modifications, not verifying origin, and HMAC still relies on the underlying hash's collision resistance. Without collision resistance, HMAC alone cannot guarantee integrity.

Preimage resistance

Why it fails: Preimage resistance ensures that given a hash value, it is infeasible to find any input that hashes to it. While important for password storage and one-way functions, it does not directly prevent an attacker from creating a modified file with the same hash as the original, which is the integrity concern here.

Second preimage resistance

Why it fails: Second preimage resistance ensures that given one input, it is infeasible to find a different input with the same hash. This is closely related to collision resistance, but collision resistance is the stronger property that guarantees no two arbitrary inputs collide, making it the most critical for detecting substitutions.

GRE (Generic Routing Encapsulation)

Why it fails: GRE is a tunneling protocol that encapsulates various network layer protocols, but it does not provide encryption or authentication by itself. It is often used in conjunction with IPsec to add multicast support, but it does not meet the confidentiality and integrity requirements on its own.

AH (Authentication Header)

Why it fails: AH provides integrity and authentication but does not provide confidentiality, as it does not encrypt the payload. Since the requirement includes confidentiality, AH alone is insufficient. AH is also incompatible with NAT, which is common in VPN deployments.

SSL/TLS

Why it fails: SSL/TLS is a different protocol suite used for securing application-layer traffic, such as HTTPS or SSL VPNs. It is not a component of IPsec and does not provide the IP-layer security required for an IPsec tunnel. It would not be used to meet the IPsec VPN requirements.

Trusted Platform Module (TPM)

Why it fails: A TPM stores keys and measurements but is not designed to bulk-encrypt an entire disk at line speed. It can seal a volume's key to platform measurements, yet the actual data transformation is done by the CPU or a self-encrypting drive controller. For removing disks and preserving confidentiality, the TPM alone does not encrypt the platters, so it fails the physical-theft requirement.

Hardware Security Module (HSM) configured for database column encryption

Why it fails: An HSM protects keys and accelerates cryptographic operations, but it does not encrypt an entire disk volume. It would require the host to send each block to the HSM, which is not how full-disk encryption works. Column-level encryption also leaves other files unprotected, so it does not meet the requirement for whole-disk confidentiality under physical theft.

File-level encryption using EFS with a recovery agent

Why it fails: EFS encrypts individual files and folders, not the entire disk. System files, swap space, and metadata may remain in cleartext, and an attacker with physical access could potentially recover unencrypted remnants. It also depends on host CPU for cryptographic work, so it does not provide the independent hardware-based full-disk protection required.

Apply Base64 encoding to the stored data

Why it fails: Base64 is an encoding scheme that transforms binary data into ASCII text for compatibility, not a security control. It provides no confidentiality or integrity; anyone can decode it. Applying Base64 would not encrypt data at rest or detect tampering, so it fails the requirements.

Use RSA-2048 to encrypt the data directly

Why it fails: RSA-2048 is an asymmetric algorithm suitable for key transport or digital signatures, not for bulk data encryption. It is slow and has size limitations, and it does not inherently provide integrity for the encrypted data. Using it alone would not efficiently encrypt large volumes of customer data or detect tampering.

Generate a SHA-256 hash of the plaintext and store it alongside

Why it fails: A plain hash of the plaintext can detect accidental changes but does not provide confidentiality. An attacker who modifies the ciphertext could also recompute the hash if they have access to the plaintext, and the hash itself is not keyed, so it does not authenticate the data. It does not meet the encryption requirement.

3DES-CBC

Why it fails: CBC supplies confidentiality only; it lacks a message authentication code, so ciphertext modifications go undetected. It is tempting because 3DES-CBC was long the standard for bulk encryption, and would be acceptable where integrity is handled separately, such as an encrypt-then-MAC construction.

AES-ECB

Why it fails: ECB mode is not recommended due to pattern leakage and does not provide authentication.

RC4

Why it fails: RC4 is a stream cipher with known keystream biases and no integrity mechanism, so it cannot supply authentication. It is tempting for its speed and simplicity in legacy TLS or WEP contexts, but those deployments are deprecated precisely because RC4 fails confidentiality and authenticity guarantees.

Recipient's public key to sign, recipient's private key to verify

Why it fails: The recipient's key pair is irrelevant to signing; only the sender's private key can produce a signature verifiable with the sender's public key. Using the recipient's keys would let the recipient forge signatures, destroying non-repudiation. This option confuses encryption to a recipient with signing by an originator.

Sender's public key to sign, recipient's private key to verify

Why it fails: Signing uses the sender's private key, not their public key, and verification uses the sender's public key, not the recipient's private key. The recipient's key pair plays no part in signing. This reversed pairing is tempting because public-key operations do involve both key types, but the signer must hold the private half.

A shared symmetric key for both signing and verification

Why it fails: Symmetric keys cannot provide non-repudiation: both parties hold the same secret, so either could have produced the signature. Symmetric cryptography suits bulk data confidentiality, such as AES session encryption, but digital signatures require the sender's private key to sign and the sender's public key to verify.

Pre-shared key (PSK)

Why it fails: A static pre-shared key provides no forward secrecy: compromise of the key exposes every session key derived from it, so past traffic becomes decryptable. PSK suits small, fixed peer sets where key distribution simplicity outweighs that risk, but it cannot meet this requirement.

RSA key exchange

Why it fails: RSA key exchange encrypts the session key under the server's long-term private key, so its compromise decrypts every recorded session, defeating forward secrecy. It is tempting because RSA is widely deployed for IPsec authentication and key transport, and is correct when forward secrecy is not required.

Diffie-Hellman with static keys

Why it fails: Static Diffie-Hellman keys are long-term and reused, so compromise of the server's private key exposes the shared secret and therefore past session keys. It is tempting because Diffie-Hellman provides forward secrecy when ephemeral, which is the correct choice for this requirement.

SHA-3

Why it fails: SHA-3 uses the Keccak sponge construction and is not vulnerable to practical collision attacks. It would be the correct choice if the question asked which modern hash standard offers an alternative design to SHA-2 for cryptographic integrity.

SHA-256

Why it fails: SHA-256 belongs to the SHA-2 family and has no practical collision attacks; it is currently recommended. It would be correct if the question asked which algorithm produces a 256-bit digest suitable for integrity verification and digital signatures.

HMAC-SHA256

Why it fails: HMAC-SHA256 is a keyed message authentication construction built on SHA-256, not a standalone hash algorithm, and remains secure. It would be the right answer if the question asked which mechanism verifies both integrity and authenticity of a message.

Only the root CA certificate

Why it fails: The root certificate alone cannot verify the end-entity certificate, because the intermediate CA's signature on it is unverified; the intermediate certificate is missing from the chain. Root-only validation tempts when administrators assume trust anchors suffice, but that scenario applies only when the root directly issues end-entity certificates.

Only the end-entity certificate and the root CA certificate

Why it fails: Omitting the intermediate CA certificate breaks the chain: the root cannot directly verify the end-entity certificate, since the intermediate signed it. End-entity plus root tempts when the hierarchy is assumed flat, but that pairing only works when the root issues end-entity certificates directly.

Only the end-entity certificate and the intermediate CA certificate

Why it fails: Validation requires the root CA certificate as the trust anchor to verify the intermediate's signature; without it the chain terminates unverified. End-entity plus intermediate tempts because those two are transmitted together, but the client must already hold or fetch the root to complete path validation.

RSA with 2048-bit keys

Why it fails: RSA with 2048-bit keys is the baseline the scenario seeks to improve on, so it delivers no key-size reduction for constrained hardware. It is tempting because RSA 2048 is the reference security level, and would be correct where ample computation exists and interoperability with legacy systems matters most.

Diffie-Hellman with 2048-bit keys

Why it fails: Diffie-Hellman with 2048-bit keys is a key-agreement method, not an encryption or signature algorithm, and its key sizes match RSA rather than shrinking. It is tempting because DH is asymmetric and widely deployed, and would be correct for establishing a shared secret over an untrusted channel, not for signing or encrypting IoT data.

3DES with 168-bit keys

Why it fails: 3DES is a symmetric block cipher, not asymmetric, and its 168-bit keys provide no public-key exchange for an IoT device. It is tempting because 3DES is a recognised encryption standard with short keys, and would be correct for bulk data confidentiality where a shared secret already exists, not for key agreement.

Confidentiality

Why it fails: HMAC-SHA256 outputs a tag computed over the message and key; the message itself remains readable, so confidentiality is not provided. Confidentiality requires encryption such as AES. HMAC is selected when verifying integrity and authenticity of a message whose contents need not be hidden.

Non-repudiation

Why it fails: HMAC uses a shared symmetric key, so both parties can compute the same tag; either could forge it, meaning no third party can attribute a message to one sender. Non-repudiation requires asymmetric signing with a private key. HMAC is chosen for integrity and authenticity between parties sharing a secret.

Forward secrecy

Why it fails: Forward secrecy protects past session keys if a long-term key is later compromised, achieved through ephemeral Diffie-Hellman key exchange. HMAC-SHA256 only produces a keyed message authentication tag; it performs no key agreement or session key derivation, so it cannot deliver this property.

FTP

Why it fails: FTP sends credentials and file contents unencrypted and provides file transfer, not interactive remote command execution. It is tempting because it is a standard administrative file-transfer tool, and would be correct when replaced by FTPS or SFTP for encrypted bulk file movement to a server.

HTTP

Why it fails: HTTP carries no transport encryption, so credentials and commands cross the network in cleartext; it also lacks a remote shell mechanism. It is tempting because HTTP underpins web-based management consoles, and would be right when secured as HTTPS for browser administration rather than command-line access.

Telnet

Why it fails: Telnet transmits credentials and session data in cleartext, so it is the insecure protocol being replaced, not a secure alternative. It is tempting because Telnet genuinely provides remote shell administration, and would be acceptable only on an isolated, trusted management network where encryption is handled by another layer.

Random numbers from a website

Why it fails: A website supplies no verifiable entropy source and exposes keys to network interception, tampering and provider logging, so outputs cannot be trusted as unpredictable. Fetching random values online is tempting for convenience in non-security contexts such as picking lottery numbers for a demo.

Linear congruential generator (LCG)

Why it fails: A linear congruential generator is deterministic and its output is predictable once the seed and parameters are known, so it cannot supply unpredictable keys. It is tempting because LCGs are fast and simple for simulations, but cryptographic key generation demands a cryptographically secure pseudorandom number generator seeded from a high-entropy source.

Pseudorandom number generator (PRNG) seeded with current timestamp

Why it fails: Seeding a PRNG with the current timestamp gives an attacker a tiny, guessable seed space, so the generated key stream can be reproduced by brute-forcing plausible times. Timestamp seeding suits reproducible test data or simulations, not cryptographic key generation.

Encrypt email

Why it fails: The serverAuth EKU restricts the certificate to authenticating TLS servers, so it cannot perform S/MIME email encryption, which requires the emailProtection EKU. It is tempting because serverAuth certificates are frequently used for secure communications, but that role is limited to TLS server authentication, not message-level encryption.

Sign code

Why it fails: The serverAuth EKU restricts the certificate to authenticating TLS servers, so code signing is outside its permitted use. Code signing requires the codeSigning EKU; serverAuth would be correct for a web or application server presenting TLS credentials.

Issue subordinate CA certificates

Why it fails: Issuing subordinate CA certificates requires the basicConstraints extension with CA:TRUE and keyCertSign key usage; serverAuth alone grants no signing authority over other certificates. It is tempting because CAs do issue certificates, but a serverAuth leaf certificate is an end-entity credential, not a signing authority.

Certificate Revocation List (CRL)

Why it fails: A CRL requires the client to download the entire signed list of revoked serial numbers, contradicting the requirement to avoid full-list retrieval. It is tempting because CRLs are a standard revocation mechanism, but their batch, periodically published format is exactly what OCSP was designed to replace.

Self-signed certificate validation

Why it fails: Self-signed certificate validation concerns trusting a certificate whose issuer and subject match; it says nothing about revocation status. It is tempting because self-signed certificates bypass CA chains, but no revocation checking mechanism exists within that model, so it cannot satisfy a real-time status query.

Certificate Transparency (CT)

Why it fails: Certificate Transparency provides append-only public logs of issued certificates to detect mis-issuance; it does not report whether a certificate has been revoked. It is tempting because CT offers real-time log monitoring without downloading lists, but its purpose is auditing issuance, not querying revocation status.