Cryptography Application practice questions

MACs hmac-md5,hmac-sha1

Why it fails: HMAC-MD5 and HMAC-SHA1 are cryptographically weak message authentication codes suffering from theoretical collision attacks and deprecation by modern security standards. Allowing these algorithms exposes the session integrity layer to potential tampering and active downgrade attacks.

PubkeyAuthentication no

Why it fails: Disabling public key authentication forces users to rely exclusively on password-based authentication, which significantly increases vulnerability to brute-force attacks and credential stuffing. Strong SSH hardening mandates public key authentication while disabling interactive passwords entirely.

Cipher blowfish-cbc

Why it fails: Blowfish is an obsolete block cipher with a small 64-bit block size that makes it exceptionally vulnerable to birthday attacks and sweet32 collision exploits when used for long data transfers. Modern security baselines explicitly prohibit small block cipher algorithms.

The key size is too large for the RSA algorithm, causing latency.

Why it fails: A 1024-bit key is considered too small, not too large, by modern standards. The risk is not latency but rather the feasibility of factoring the modulus using advanced computational resources, which renders the private key vulnerable to discovery and invalidates the security posture of the signing service.

RSA should only be used for symmetric key storage.

Why it fails: RSA is an asymmetric algorithm perfectly suited for digital signatures when implemented correctly. The issue here lies not in the intended use case, but in the outdated parameters and insecure padding mechanisms that fail to provide adequate protection against modern cryptanalysis techniques and practical adversarial attack vectors.

The JSON format is not compatible with cryptographic standards.

Why it fails: The JSON format is merely a representation of the configuration parameters and has no bearing on the cryptographic strength of the algorithm. The security risk stems entirely from the underlying RSA-1024 parameters and the vulnerable PKCS padding scheme, which are mathematically obsolete and prone to exploitation by attackers.

The subordinate certificate is rejected because the microservice certificate does not include the keyUsage extension with keyCertSign.

Why it fails: While keyUsage with keyCertSign is required for a CA certificate, the scenario states that basicConstraints is set to CA:FALSE. Even if keyUsage were missing, the basicConstraints extension alone is sufficient to prevent the certificate from being used as a CA. The primary reason for rejection is the CA:FALSE setting, not the absence of keyUsage.

The subordinate certificate is accepted because the pathlen:0 constraint only limits the depth of the certificate chain, not the ability to sign.

Why it fails: The pathlen:0 constraint is only relevant when the certificate has CA:TRUE. It limits the number of intermediate CAs that can follow. Since the microservice certificate has CA:FALSE, pathlen is ignored, and the certificate cannot sign at all. Thus, the subordinate certificate is rejected, not accepted.

The subordinate certificate is accepted because the microservice certificate includes a valid digital signature.

Why it fails: The microservice certificate has basicConstraints CA:FALSE, which explicitly marks it as an end-entity certificate. A relying party that checks the basicConstraints extension will reject any certificate signed by this microservice certificate because it is not authorized to act as a CA. A valid digital signature alone does not override the basicConstraints restriction.

AES-256-GCM

Why it fails: AES-256-GCM is a symmetric encryption algorithm providing confidentiality and integrity, but it does not provide digital signatures or non-repudiation. It uses a shared secret key, so any party with the key could generate a valid authentication tag. Thus, it cannot be used to create legally binding digital signatures that ensure non-repudiation.

HMAC-SHA256

Why it fails: HMAC-SHA256 is a message authentication code, not a digital signature algorithm. It uses a shared secret key, so it cannot provide non-repudiation because both parties possess the same key. An attacker who obtains the shared key could forge a MAC. Therefore, HMAC-SHA256 does not meet the requirement for non-repudiation or public-key based signature verification.

ECDSA with P-256 and SHA-256

Why it fails: ECDSA with P-256 and SHA-256 is a NIST-standardized digital signature algorithm and provides non-repudiation. However, it is not as widely supported in legacy COTS products as RSA. Some older systems may lack ECDSA support, which could hinder interoperability. While ECDSA is secure, the requirement for broad COTS support makes RSA a more suitable choice in this scenario.

Output Feedback (OFB)

Why it fails: OFB is a stream mode that does not require padding, but it cannot process blocks in parallel because the keystream is generated sequentially from the previous output. While it avoids identical ciphertext blocks for identical plaintext, the lack of parallel processing fails the backup software requirement. OFB is not the best fit here.

Electronic Codebook (ECB)

Why it fails: ECB encrypts each block independently, which allows parallel processing and avoids padding, but identical plaintext blocks always produce identical ciphertext blocks. This directly violates the requirement that identical plaintext blocks must not yield identical ciphertext blocks. ECB is therefore insecure for backups containing repetitive data.

Cipher Block Chaining (CBC)

Why it fails: CBC requires padding to a multiple of the block size and cannot process blocks in parallel because each block depends on the previous ciphertext block. It also does not meet the requirement that identical plaintext blocks produce different ciphertext blocks when the same IV is reused. CBC is unsuitable for this backup scenario.

Derive a per-archive key from a single organization-wide master secret using PBKDF2 with a unique salt, and store the salt with each archive.

Why it fails: PBKDF2 is a password-based derivation function built to slow brute-force guessing of low-entropy secrets, not to provide forward secrecy. Because every per-archive key traces back to one master secret, compromise of that master secret lets an attacker recompute all derived keys and decrypt every archive, failing the stated requirement.

Encrypt each backup archive with a unique randomly generated data encryption key, wrap that key with a long-lived key-encryption key stored in a hardware security module, and store only the wrapped key alongside the archive.

Why it fails: This envelope approach is efficient and common, but the archive's confidentiality is bound to the long-lived key-encryption key. If that wrapping key is compromised, every wrapped data key can be unwrapped and all archives decrypted, which violates the requirement that data stay confidential after key compromise.

Use a hybrid scheme: generate a random symmetric key per archive, encrypt the archive with it, then encrypt that key using an ephemeral asymmetric key pair whose private key is destroyed immediately after wrapping.

Why it fails: Destroying the private key makes the wrapped key permanently unrecoverable, so the archive itself can never be decrypted by anyone, including authorized restoration staff. This provides strong secrecy but breaks the operational need to restore backups, making it unsuitable for a ten-year archive that must remain readable.

AH with HMAC-SHA256

Why it fails: AH provides authentication and integrity but no confidentiality. The requirement explicitly states that the algorithm must provide confidentiality. Therefore, AH alone is insufficient. While AH can be combined with ESP, the question asks for a combination that provides both confidentiality and authenticity, and AH does not contribute to confidentiality.

ESP with 3DES and HMAC-MD5

Why it fails: ESP with 3DES and HMAC-MD5 provides confidentiality and integrity, but 3DES is deprecated due to its small block size and slow performance, and HMAC-MD5 is considered weak. It also requires separate keys for encryption and authentication, and does not inherently prevent key reuse. This combination is not recommended for new deployments.

ESP with AES-CBC and HMAC-SHA256

Why it fails: ESP with AES-CBC and HMAC-SHA256 provides confidentiality and integrity, but it requires two separate keys: one for encryption and one for authentication. This meets the authenticity requirement but does not inherently prevent key reuse; key management is external. It is a valid but less efficient choice compared to combined mode algorithms.

A 1024-bit RSA signature with SHA-1, because the smaller modulus reduces the exponentiation cost while retaining legacy compatibility.

Why it fails: Reducing RSA to 1024 bits and SHA-1 lowers cost but is cryptographically unacceptable today; 1024-bit RSA and SHA-1 are deprecated and vulnerable to collision and factoring advances. It also still relies on modular exponentiation, so it fails the performance goal as well as current security expectations.

RSA-PSS with a 2048-bit modulus and SHA-256, because PSS provides provable security and is widely supported.

Why it fails: RSA-PSS is secure and widely supported, but RSA signature verification requires modular exponentiation with a large modulus, which is exactly the slow operation the devices cannot perform quickly. The requirement to avoid large modular exponentiations rules out RSA-based signatures despite their broad compatibility.

Ed25519 with SHA-512 internally, because it is deterministic and avoids the random nonce problem that affects ECDSA.

Why it fails: Ed25519 is fast and deterministic, but the scenario specifies that devices support only RSA and ECDSA. Choosing Ed25519 would leave those devices unable to verify firmware signatures, so it fails the explicit compatibility constraint even though its cryptographic properties are strong.

TPM + Startup Key

Why it fails: TPM + Startup Key requires a USB drive containing a startup key to be inserted at boot. This adds a possession factor but also introduces operational complexity and a physical token that could be lost. The scenario does not require an additional factor beyond the TPM; thus, this configuration is unnecessary.

Password only

Why it fails: Password-only mode does not use the TPM for key protection or boot validation. It relies solely on a user-entered password, which does not meet the requirement for a hardware module that validates the boot process. This mode is less secure against certain attacks and does not satisfy the stated criteria.

TPM + PIN

Why it fails: TPM + PIN adds a user-entered PIN as a second factor, which enhances security but also requires user interaction at boot. The scenario does not mention a requirement for a PIN or pre-boot authentication; it only requires hardware-based key protection and boot validation. Therefore, TPM-only is more appropriate.

Certificate Transparency (CT)

Why it fails: Certificate Transparency is a logging framework that records certificates in public logs to detect misissuance. It does not provide revocation status information. While it enhances accountability, it does not fulfill the requirement for revocation checking. Therefore, it is not a suitable mechanism for this scenario.

Online Certificate Status Protocol (OCSP)

Why it fails: OCSP requires the client to contact an OCSP responder to check the revocation status of a certificate. This is an online mechanism, which violates the requirement that clients verify revocation without directly contacting the CA. While OCSP can be used with stapling to reduce direct contact, the base protocol itself is online and thus not suitable here.

Simple Certificate Enrollment Protocol (SCEP)

Why it fails: SCEP is used for automated certificate enrollment and renewal, not for revocation checking. It allows clients to request certificates from a CA but does not provide a way to verify if a certificate has been revoked. Thus, it does not meet the requirement for revocation status verification without contacting the CA.

ssh-dss

Why it fails: ssh-dss is based on the Digital Signature Algorithm with a fixed 1024-bit key size. It is considered obsolete and insecure because 1024-bit DSA keys can be broken with sufficient computational resources, and the algorithm is disabled by default in modern OpenSSH versions. It does not provide forward secrecy on its own, and it is not resistant to offline brute-force attacks. Therefore, it fails the policy requirements.

diffie-hellman-group14-sha1

Why it fails: diffie-hellman-group14-sha1 is a key exchange algorithm that uses a 2048-bit MODP group with SHA-1 as the hash. While it provides forward secrecy because the ephemeral Diffie-Hellman keys are discarded after the session, the use of SHA-1 makes it vulnerable to collision and preimage attacks, and it is considered weak by current standards. The policy requires resistance to offline brute-force attacks, so a SHA-1 based algorithm is not appropriate.

ssh-rsa

Why it fails: ssh-rsa is a signature algorithm based on RSA with SHA-1 or SHA-256, not an ephemeral key exchange. It does not provide forward secrecy because the same long-term RSA key is used for every session. If that key is compromised, all previously recorded sessions can be decrypted. It is also increasingly deprecated in modern OpenSSH due to SHA-1 weaknesses and small key sizes. Therefore, it does not satisfy the policy requirement for forward secrecy.

Key Usage extension populated solely with Digital Signature, Non-Repudiation, and Key Encipherment flags.

Why it fails: Key Usage defines cryptographic operations permissible for the specific key pair, such as signing or encryption. While vital for operational security, it does not restrict which specific subject names or domain namespaces a subordinate CA can certify.

Authority Information Access extension pointing directly to the organization's primary online OCSP responder.

Why it fails: Authority Information Access only publishes OCSP and CA issuer endpoints for revocation checking; it constrains nothing about which domains the sub-CA may certify. Name Constraints is the extension that restricts issuance to permitted DNS namespaces, so AIA leaves the sub-CA free to sign any domain.

Extended Key Usage extension restricted strictly to TLS Web Server Authentication and Code Signing.

Why it fails: Extended Key Usage limits the application purposes for which the certified public key can be used, such as server authentication. It does not restrict the target domain names or organizational subtrees that the subordinate CA is authorized to issue against.

RSA key transport mechanism

Why it fails: RSA key transport relies entirely on the server static private key to encrypt the pre-master secret directly. If an attacker records the encrypted handshake and later steals the private key, every historical session is instantly compromised, completely failing forward secrecy requirements.

Pre-Shared Key authentication mode

Why it fails: Pre-shared keys bypass public-key cryptography entirely during the initial authentication phase. While fast, they do not inherently generate ephemeral session parameters unless explicitly combined with an underlying Diffie-Hellman exchange, making them dependent on the specific implementation parameters chosen.

Static Diffie-Hellman key agreement

Why it fails: Static Diffie-Hellman utilizes long-term parameters configured identically across multiple sessions. Because the private components remain constant over extended operational periods, compromising the static key material instantly exposes all derived session keys to retroactive decryption attacks.

Support TLS 1.0, 1.1, and 1.2 to maintain maximum backward compatibility.

Why it fails: Supporting older protocols like TLS 1.0 and 1.1 exposes the server to known cryptographic flaws such as BEAST and Lucky13. Modern standards explicitly mandate the removal of these protocols to ensure that only secure, updated handshake procedures are utilized during client-server negotiation, thereby maintaining high security baselines.

Enable SSLv3 for clients who cannot support newer TLS versions.

Why it fails: SSLv3 is fundamentally broken and susceptible to the POODLE attack, which allows attackers to decrypt sensitive cookies. Enabling this protocol on any production server is a significant security violation, as it provides no meaningful protection against modern interception techniques or sophisticated cryptographic analysis tools.

Use RC4 for all connections to ensure high performance over low-bandwidth links.

Why it fails: The RC4 stream cipher is considered cryptographically broken due to significant biases in its output stream. Modern security standards strictly prohibit the use of RC4, as attackers can recover sensitive plaintext through statistical analysis, making it entirely unsuitable for protecting confidential data in any production environment.

Use SHA-256 hashing for all database fields.

Why it fails: Hashing is a one-way function used primarily for integrity verification or password storage, not for reversible encryption of PII. Since hashing cannot be reversed to retrieve the original data, it would render the database unusable for legitimate business processes that require authorized access to the underlying sensitive information.

Use RSA-4096 for encrypting large datasets.

Why it fails: RSA is an asymmetric algorithm designed for key exchange or digital signatures, not for encrypting large volumes of data. Applying RSA to a database would be prohibitively slow and computationally expensive, as asymmetric operations are mathematically intensive compared to the symmetric algorithms designed for bulk data encryption tasks.

Apply XOR-based encryption with a static global key.

Why it fails: XOR encryption with a static key is extremely weak and provides no real security against even basic cryptanalysis. It is not considered a valid cryptographic solution in any professional context, as the lack of diffusion and the reuse of keys make the protected data trivially easy to decrypt.

Centralized distribution of symmetric keys.

Why it fails: Symmetric key distribution is handled by protocols like Kerberos or Key Management Systems, not PKI. PKI specifically focuses on the management of asymmetric key pairs and the verification of identities through X.509 certificates rather than the direct transmission of secret symmetric keys between various network clients.

Hardware-level encryption for disk storage.

Why it fails: Disk encryption is typically handled by Full Disk Encryption (FDE) tools or platform-specific features like BitLocker or dm-crypt. While PKI might assist in managing the keys for such systems, it is not the primary function of the infrastructure itself, which is designed for identity and trust management.

Real-time traffic flow monitoring and alerting.

Why it fails: Traffic monitoring and alerting are the responsibilities of Intrusion Detection and Prevention Systems (IDPS) or Network Monitoring Tools. PKI does not provide analysis of packet contents or network behavior, as its operational focus remains strictly on the management of public key assets and digital identity authentication.

Pre-image resistance.

Why it fails: Pre-image resistance ensures that it is hard to find the input given an output hash. While important for password storage, it does not prevent collisions where two different files might produce the same hash, which is the specific threat when attackers attempt to substitute malicious files for legitimate ones.

Reversibility.

Why it fails: Cryptographic hash functions are designed to be one-way, non-reversible functions. Reversibility is not a property of hash functions, and in fact, any hash function that could be reversed would be fundamentally broken and useless for cryptographic integrity checks or secure digital signatures, as it would expose the underlying data.

High computational speed.

Why it fails: While speed is convenient, it is not a security property. In some cases, high speed is actually a disadvantage, such as in password hashing, where slow functions are preferred to hinder brute-force attacks. Collision resistance is far more vital for integrity than the raw performance of the algorithm.

Keep the 1024-bit RSA key but replace SHA-1 with SHA-3.

Why it fails: Replacing SHA-1 with SHA-3 improves hash security, but the 1024-bit RSA key remains too weak for modern standards. NIST recommends a minimum of 2048-bit RSA keys for security beyond 2030. The key size must also be increased to meet current requirements. Thus, this change is insufficient.

Replace RSA with HMAC-SHA256 for signing.

Why it fails: HMAC-SHA256 is a symmetric message authentication code, not a digital signature algorithm. It cannot provide non-repudiation and requires a shared secret key, which is unsuitable for signing messages in a public-key infrastructure. This does not maintain the RSA algorithm family and is conceptually incorrect for digital signatures.

Switch to Elliptic Curve Digital Signature Algorithm (ECDSA) with P-256 and SHA-256.

Why it fails: While ECDSA with P-256 and SHA-256 is secure and efficient, it changes the algorithm family from RSA to elliptic curve. The requirement explicitly states to maintain the same algorithm family. Therefore, this recommendation does not meet the stated constraint, even though it is a valid upgrade in other contexts.

Key encapsulation, so that the long-term secret directly encrypts each session key and guarantees confidentiality of the exchange.

Why it fails: Key encapsulation typically wraps a session key with a long-term public key; if the corresponding long-term private key is later compromised, every wrapped session key can be recovered. That directly violates the requirement that compromise of one session key never reveal another session's key or the long-term secret.

Collision resistance, so that two different sessions cannot produce the same derived key material during the handshake.

Why it fails: Collision resistance is a hash function property that prevents two distinct inputs producing the same digest; it does not prevent a compromised long-term secret from unwrapping stored session keys. It is unrelated to isolating session keys from each other or protecting the long-term authentication secret.

Non-repudiation, so that each VPN endpoint can prove it participated in the session and cannot deny sending traffic.

Why it fails: Non-repudiation is a property of digital signatures that binds a party to a message; it does not isolate session keys from one another. It addresses accountability rather than the confidentiality requirement that one session key compromise cannot expose other keys or the long-term authentication secret.

The file is encrypted with a stream cipher using a nonce that is reused across all files for simplicity.

Why it fails: Reusing a nonce with the same stream cipher key causes the keystream to repeat, so XORing two ciphertexts cancels the keystream and leaks plaintext relationships. It also does nothing to detect ciphertext modification, so it fails both the confidentiality and integrity expectations of the scenario.

A static initialization vector equal to the file creation timestamp is used for every encryption operation to ensure reproducibility.

Why it fails: A predictable, reused initialization vector in modes like CBC causes identical plaintext blocks to produce identical ciphertext and enables chosen-plaintext attacks. It also provides no integrity protection, so ciphertext modification would go undetected, failing the tamper-detection requirement.

The encryption key is embedded in the file header obfuscated with Base64 so the tool can decrypt without prompting the user.

Why it fails: Base64 is an encoding, not encryption; anyone can decode the header and recover the key, so a copied file decrypts without any passphrase. This defeats the core requirement that an attacker who copies the file cannot decrypt it without the user's passphrase.