Cryptography practice questions

Data confidentiality

Why it fails: Data confidentiality ensures that intercepted information cannot be read by unauthorized parties through robust encryption mechanisms. A substitute certificate still allows encrypted sessions, meaning confidentiality technically remains intact while authenticity fails.

System availability

Why it fails: System availability guarantees that network resources and applications remain accessible to authorized users without disruption. Certificate manipulation targets trust and identity validation rather than rendering the web server unreachable or unresponsive.

Message non-repudiation

Why it fails: Non-repudiation prevents a sender from denying the authenticity of their transmitted signature using private key validation. While related to signatures, the primary failure in a fraudulent certificate deployment is establishing correct endpoint identity.

Entity authenticity

Why it fails: Entity authenticity relies on trusted certificates to prove that the communicating server is indeed who it claims to be. A forged or compromised certificate chain subverts this verification process, allowing malicious actors to impersonate legitimate services.

Replace asymmetric digital signatures entirely with symmetric HMAC tokens.

Why it fails: HMAC tokens require sharing a secret key between verification and signing parties, which destroys non-repudiation guarantees. Digital signatures explicitly require asymmetric key pairs to ensure third-party verifiable authenticity and non-repudiation.

Disable certificate revocation list checking to speed up validation performance.

Why it fails: Disabling revocation checks leaves systems blind to compromised or fraudulently issued certificates currently active in the wild. Revocation mechanisms are vital components for maintaining trust within a public key infrastructure.

Store private keys in plain text configuration files on web server root directories.

Why it fails: Storing private keys in plain text exposes them to immediate theft by any malicious actor who gains read access to the server. Private keys must always reside in secure hardware security modules or encrypted, access-controlled key stores.

Perfect Forward Secrecy

Why it fails: Perfect Forward Secrecy is a property of key exchange protocols that ensures session keys are not compromised even if the server's long-term private key is stolen. It does not apply to digital signatures or document signing, as digital signatures do not involve session key derivation for communication privacy.

Certificate Revocation List (CRL)

Why it fails: A CRL is a list of revoked certificates published by a CA. While it helps identify compromised keys, it does not inherently 'validate' past signatures. Relying solely on CRLs would make it difficult to determine if a signature was created before or after a key was actually compromised.

Hashing with salt

Why it fails: Salting is used to protect passwords from rainbow table attacks by adding random data to the input before hashing. It is not relevant to digital signatures or the long-term validity of signed documents, as it serves a completely different purpose in identity management and authentication of stored secret credentials.

AES-ECB

Why it fails: ECB encrypts each block independently with no IV, so it technically avoids IV management and allows parallel decryption. However, identical plaintext blocks produce identical ciphertext blocks, leaking structural patterns in the data. It is not considered suitable for protecting data at rest and would fail the hospital's compliance review despite its low overhead.

AES-CBC

Why it fails: CBC requires a unique random IV per message and chains each ciphertext block into the next, so decryption is inherently serial. It is NIST-approved and widely used, but it fails the stated requirement that no separate random IV be needed and does not permit parallel decryption. For a fleet of servers without hardware acceleration, CBC also adds measurable latency compared with counter-based modes.

AES-GCM

Why it fails: GCM is an authenticated encryption mode built on counter mode, but it requires a unique nonce per encryption and adds GHASH authentication overhead. While it is NIST-approved and parallelizable, the requirement that each message use a distinct nonce conflicts with the architect's insistence on avoiding per-block randomness. The question asks specifically for the counter-based mode without authentication overhead.

ESP with AES-GCM, which derives both the encryption key and the integrity key from the same shared secret without separation.

Why it fails: AES-GCM is an AEAD mode that provides confidentiality and integrity, but a properly implemented IPsec GCM configuration still derives distinct keying material for encryption and for the authentication tag through the key schedule. Describing it as using one shared secret without separation mischaracterizes how GCM keying works and does not match the requirement to avoid key reuse. The premise in this option is technically inaccurate.

ESP with 3DES for confidentiality and HMAC-MD5 for integrity, using the same key for both transforms.

Why it fails: 3DES is deprecated due to its small effective block size and performance cost, and MD5 is cryptographically broken for collision resistance and no longer acceptable for integrity protection. Reusing the same key for both encryption and integrity is precisely the practice the design must avoid. This combination fails on algorithm strength, on key separation, and on current cryptographic guidance for IPsec deployments.

AH in transport mode with SHA-256 for integrity and no encryption transform.

Why it fails: Authentication Header provides integrity and data origin authentication but no confidentiality, so it fails the explicit confidentiality requirement. Transport mode also protects only the payload, not the outer IP header, which is unsuitable for a gateway-to-gateway data center tunnel. AH additionally cannot traverse NAT devices because it hashes the immutable IP header fields, adding an operational problem without meeting the encryption requirement.

Issue all service certificates from an intermediate CA whose certificate is constrained with a name constraint and a short validity period.

Why it fails: Intermediate CAs and name constraints limit the blast radius of a compromised intermediate, and short validity periods reduce the window of exposure. However, if the intermediate's private key is the one compromised and its certificate is already cached by relying parties, forged certificates still validate. This is containment, not prevention of forgery against already-trusting clients.

Enable OCSP stapling on every service so that revocation status is checked at handshake time.

Why it fails: OCSP stapling lets a server present a signed revocation status response, which speeds up revocation checking. However, if the CA private key is compromised, the attacker can issue a forged certificate and also forge or suppress revocation responses, because those are signed by the same compromised key hierarchy. Stapling does not prevent forgery of certificates that chain to the trusted CA; it only addresses timeliness of revocation data.

Use Certificate Transparency logs to publish every issued certificate and monitor for unauthorized issuance.

Why it fails: Certificate Transparency provides public, append-only logs of issued certificates and enables detection of mis-issuance. Detection is valuable, but it does not prevent an attacker who holds the CA private key from generating a certificate that validates against the cached CA certificate. CT is a detective and accountability control, not a preventive cryptographic control against a compromised signing key.

DES with CBC mode

Why it fails: DES is considered legacy and insecure due to its small 56-bit key size, which is vulnerable to brute-force attacks. Using such a weak cipher for disk encryption would fail to meet current compliance standards and expose sensitive data to decryption by modern computing resources in a short time.

Blowfish with ECB mode

Why it fails: Blowfish is a legacy block cipher with a 64-bit block size that is susceptible to birthday attacks on large datasets. Additionally, ECB mode is fundamentally insecure for disk encryption because it preserves patterns in plaintext, allowing attackers to infer structure within the encrypted data without needing the key.

RSA-4096 with OAEP

Why it fails: RSA is an asymmetric algorithm primarily used for key exchange and digital signatures, not for bulk data encryption of disks. Using RSA for disk encryption would be computationally prohibitive due to the extreme overhead and complexity, making it an inappropriate and impractical choice for protecting large volumes of data.

The RSA key length is insufficient for modern requirements

Why it fails: A 2048-bit RSA key length is currently considered the industry minimum for secure communications. While 3072-bit or higher is recommended for longer-term security, 2048-bit does not constitute a critical vulnerability in the context of generating a CSR, unlike the exposure of the private key itself.

The certificate will be self-signed and untrusted

Why it fails: The command generates a CSR, not a final certificate. A CSR is intended to be sent to a Certificate Authority for signing. The lack of a passphrase does not affect whether the resulting certificate will be signed or trusted by external entities, but rather compromises the security of the key.

The output file format defaults to a deprecated encoding

Why it fails: OpenSSL defaults to PEM encoding for CSRs and private keys, which is the standard format for most web servers and infrastructure. The -nodes flag affects the encryption status of the key file, not the encoding format or the structure of the data generated by the OpenSSL utility.

Lack of Perfect Forward Secrecy

Why it fails: Perfect Forward Secrecy relates to how session keys are derived from long-term keys. While lacking it is a concern for future-proofing, it does not explain why a client would ignore certificate validation errors during the initial TLS handshake process, which is the primary authentication step in the connection.

Weak cipher suite negotiation

Why it fails: Cipher suite negotiation concerns the algorithms used for encryption (like AES or ChaCha20). While using weak ciphers is bad practice, it does not cause the client to ignore certificate verification errors. Certificate verification is a separate process that happens before any encrypted data is even exchanged during the handshake.

Use of outdated TLS 1.0 protocol

Why it fails: TLS 1.0 is deprecated and insecure, but using it does not cause a client to ignore certificate validation errors. The protocol version negotiation and the certificate authentication process are distinct steps in the TLS handshake. A client must still validate the certificate regardless of the TLS version being negotiated.

Storing passwords using SHA-256 with no salt

Why it fails: SHA-256 is a general-purpose cryptographic hash that is computationally efficient. Without a salt, the same password will always result in the same hash, allowing attackers to use rainbow tables to crack passwords instantly. This is a critical security vulnerability that renders the password storage mechanism ineffective against common attacks.

Encrypting the database table with AES-128

Why it fails: Encryption is different from hashing. If the server is compromised, the decryption key for the database might also be available to the attacker. Storing hashes that are not reversible is a much safer approach than encryption, which implies that the original password can be recovered with the right key.

Transport Layer Security (TLS)

Why it fails: TLS is designed to protect data while it is in transit over a network. It does not provide protection for data in use on a server, as the data must be decrypted by the application before it can be processed. Therefore, it is insufficient for protecting data-in-use scenarios.

Full Disk Encryption (FDE)

Why it fails: FDE protects data while it is at rest on a physical or virtual disk. Once the system is booted and the volume is mounted, the data is decrypted for the OS. FDE does not protect data from being accessed or modified by unauthorized processes running on the live system.

Database Transparent Data Encryption

Why it fails: Transparent Data Encryption (TDE) is a form of at-rest encryption that secures database files on disk. It does not offer protection against unauthorized access to the data while the database engine is running and processing queries, as the engine handles the decryption transparently for the calling application.

Increase the RSA key size from 2048 to 4096 bits.

Why it fails: Increasing key size raises the computational cost of brute-force attacks against the key, but it does nothing to prevent misuse of a key that has already been stolen. The attacker in this scenario possesses the private key outright, so a larger modulus only makes signing slightly slower. Key-length hardening is a valid defense-in-depth measure but does not address the stated compromise scenario.

Publish the firmware hashes to a public transparency log.

Why it fails: A transparency log lets observers detect that a signature was issued and can help with after-the-fact auditing, but it does not prevent an attacker holding the private key from generating a signature that verifies on customers' devices. The forged update would still be accepted by the device's signature check. Logging improves detection and accountability, not the cryptographic guarantee that only authorized signers can produce valid signatures.

Switch the signature algorithm from RSA to ECDSA with P-256.

Why it fails: ECDSA with P-256 offers equivalent security to RSA-3072 with smaller keys and faster operations, but it still relies on a single private key. If that key is stolen, the attacker can sign arbitrary firmware exactly as before. Changing the algorithm family changes performance and key sizes, not the single-point-of-failure property that caused the incident.

Enforce a minimum RSA key size of 4096 bits for the CA key pair.

Why it fails: Increasing RSA key size strengthens resistance to brute-force attacks on the CA key, but it does not provide detection if the key is compromised and used to sign certificates. An attacker with the private key can still issue certificates silently. Key size is a preventive hardening measure, not a detective control for unauthorized issuance.

Require Certificate Revocation List (CRL) checking on all clients.

Why it fails: CRL checking allows clients to reject revoked certificates, which is useful after a compromise is discovered. It does not detect unauthorized issuance in the first place; an attacker-issued certificate remains valid until revoked. CRL checking is a reactive control that depends on prior detection, so it is not the most effective detective measure.

Configure certificate pinning in all client applications.

Why it fails: Certificate pinning associates a service with a specific certificate or public key, preventing man-in-the-middle attacks using rogue certificates. However, it does not detect when the CA issues a certificate for a different service or an unauthorized certificate; it only protects clients that already pin. Pinning is a preventive control, not a detection mechanism for CA misuse.

A cloud key management service (KMS) that stores keys in a multi-tenant environment.

Why it fails: Cloud KMS solutions can protect keys, but multi-tenant environments may not guarantee that private keys never leave the hardware boundary; some services export keys or use software-based protections. The requirement explicitly states keys must never be exposed to the OS, which may not be guaranteed. Additionally, high transaction volumes may incur latency and cost issues compared to a dedicated HSM.

A software-based key store protected by a strong passphrase and file system permissions.

Why it fails: Software-based key stores keep private keys in memory or on disk, where the operating system and privileged processes can access them. Even with strong passphrase protection, the key material is exposed to the OS during use, violating the requirement. This approach also lacks hardware isolation and is vulnerable to memory scraping or cold boot attacks.

A Trusted Platform Module (TPM) 2.0 chip on each server.

Why it fails: A TPM provides secure storage and cryptographic operations, but it is designed for platform integrity and low-throughput operations, not high-volume TLS server authentication. TPMs typically have limited performance and may not support the required number of TLS handshakes. They also do not provide the same level of physical tamper resistance as an HSM for server key protection.

PSK authentication cannot be used with IKEv2; it requires IKEv1.

Why it fails: IKEv2 fully supports pre-shared key authentication. This option is factually incorrect; both IKEv1 and IKEv2 can use PSKs. The concern is not protocol support but the security weaknesses of PSKs. Therefore, this option is not a valid primary security concern.

PSK authentication does not encrypt the IKEv2 handshake, exposing the PSK in plaintext.

Why it fails: The IKEv2 handshake is encrypted after the initial exchange, and the PSK itself is never sent in plaintext. Instead, it is used to generate authentication payloads. So the PSK is not exposed directly. The actual risk is offline dictionary attacks, not plaintext exposure. This option misrepresents how PSK authentication works.

PSK authentication does not provide perfect forward secrecy (PFS).

Why it fails: Perfect forward secrecy is a property of key exchange, not authentication. IKEv2 with PSK can still use Diffie-Hellman for key exchange to achieve PFS. The primary concern with PSK is not the lack of PFS but the fact that the same secret is shared among multiple parties, increasing the risk of compromise. So this option misidentifies the main issue.

eCryptfs

Why it fails: eCryptfs is a stacked cryptographic filesystem that encrypts files at the file level, not block devices. It is often used for home directory encryption. While it can encrypt data at rest, it operates on a per-file basis and does not provide the same block-level encryption as dm-crypt/LUKS. It also has different key management, often tied to user login passphrases.

OpenSSL

Why it fails: OpenSSL is a cryptographic library and toolkit used for TLS/SSL, certificate management, and general-purpose encryption. It can encrypt files but does not provide block device encryption or key management for full disk encryption. Using OpenSSL to encrypt a block device would require manual processes and lacks the integration and key management features of LUKS.

GnuPG (GPG)

Why it fails: GnuPG is a tool for file and email encryption, digital signatures, and key management. It is not designed for full block device encryption. While it can encrypt files, it does not provide transparent encryption of a block device at rest. Therefore, it does not meet the requirement of encrypting a block device with a passphrase-protected key.

Cipher Block Chaining (CBC)

Why it fails: CBC chains each ciphertext block into the next block's encryption, so any block can only be decrypted after all preceding blocks are processed. On a tape appliance with limited CPU, the serial dependency prevents parallel decryption and makes random access to a 40 GB archive impractical. CBC also requires careful IV management and padding, which adds complexity without delivering the independent-chunk capability the engineer needs.

Galois/Counter Mode (GCM)

Why it fails: GCM is an authenticated encryption mode that provides confidentiality and integrity, but its authentication tag covers the entire message, so verification requires processing the whole stream. That conflicts with decrypting the archive in independent chunks. GCM also demands unique nonces per key; reusing a nonce with the same key catastrophically breaks confidentiality and authenticity, which is a serious operational risk for a long-lived archival key.

Electronic Codebook (ECB)

Why it fails: ECB encrypts each block independently, so it technically permits random access, but it leaks plaintext patterns because identical plaintext blocks produce identical ciphertext blocks. A structured database backup contains highly repetitive blocks, so ECB would expose that structure in the archived ciphertext. ECB is also not a recommended mode for bulk data protection under current guidance, making it a poor choice despite its independent-block behavior.

Include a timestamp from a trusted Time Stamping Authority (TSA) in the signature.

Why it fails: A timestamp from a TSA proves that the signature existed at a certain time, which is useful for long-term validation and non-repudiation in some contexts. However, it is not essential for basic digital signature authenticity and integrity. The core requirements are hashing and using the signer's private key. Timestamps are an additional layer, not a fundamental practice.

Use the recipient's public key to encrypt the hash before signing.

Why it fails: Digital signatures use the signer's private key, not the recipient's public key. Encrypting the hash with the recipient's public key would provide confidentiality to the recipient but not a signature. Signatures must be verifiable by anyone with the signer's public key, so this practice is incorrect and does not achieve authenticity or non-repudiation.

Encrypt the entire message with the sender's private key.

Why it fails: Encrypting the entire message with the sender's private key is not a standard digital signature practice. It would be computationally expensive and does not provide confidentiality, since anyone with the public key could decrypt it. Moreover, signing is not encryption; it is a separate cryptographic operation. This approach is inefficient and incorrect for achieving the stated goals.

Split the CA key using Shamir's Secret Sharing and store one share on each HSM, reconstructing the key in memory when signing is required.

Why it fails: Shamir's Secret Sharing protects a key at rest by distributing shares, but reconstructing the key for signing places the full private key in memory on the reconstructing host. A root-level attacker on that appliance could capture the reconstructed key. The scheme also introduces complexity and availability risk without providing the in-module, never-exported guarantee the scenario demands.

Enable FIPS 140-3 Level 1 validation on the HSM and replicate the CA key to a standby appliance using a vendor export command.

Why it fails: FIPS 140-3 Level 1 requires only basic cryptographic module validation and does not mandate tamper resistance or non-exportable keys. Using a vendor export command to replicate the key explicitly moves key material outside the module boundary, which is exactly the exposure the architect wants to avoid. Validation level alone does not prevent a root-level attacker from capturing exported key material during replication.

Store the CA private key in an encrypted file on each HSM's local disk, protected by a passphrase entered at boot.

Why it fails: A passphrase-protected key file on local disk means the key exists in host memory when unlocked, and an attacker with root on the appliance can dump process memory or read the passphrase from the boot process. This approach also forces redundant key copies across appliances, increasing exposure. It does not ensure the key never appears in plaintext outside the HSM boundary, so it fails the architect's stated requirement.

Run the ISO through an antivirus scanner and confirm no malware is detected.

Why it fails: An antivirus scan checks for known malicious content but does not verify a cryptographic hash or signature, so it cannot confirm integrity in the cryptographic sense or establish origin. A tampered file with no known malware signature would pass. This approach also depends on signature databases that may lag behind new threats, making it unsuitable as the primary integrity and authenticity check.

Compute the SHA-256 hash of the ISO and compare it to the published checksum only.

Why it fails: Comparing the computed SHA-256 hash to the published value detects accidental corruption and verifies integrity, but it does not prove origin. If an attacker can alter the ISO, they can also alter the published checksum on the same compromised site. The hash comparison alone therefore cannot establish that the file genuinely came from the vendor, which is half of the stated requirement.

Encrypt the ISO with the vendor's public key and confirm the operation succeeds.

Why it fails: Encrypting with the vendor's public key would produce ciphertext only the vendor's private key could decrypt, which is useful for confidentiality but irrelevant to verifying a downloaded file. It neither checks integrity nor confirms that the vendor produced the ISO. This action misunderstands the direction of asymmetric operations and does not address the administrator's verification goal.