Trick 1: "To digitally sign a document, you encrypt it with the recipient's public key." True or False?
FALSE — this is the most common key-direction mistake on the exam.
For encryption (confidentiality): Encrypt with the RECIPIENT's public key. Only the recipient's private key can decrypt it.
For digital signing (integrity/authentication/non-repudiation): Hash the document, then encrypt the hash with YOUR OWN private key. Anyone with your public key can verify — but only you could have created the signature.
Memorize the direction rule:
- Confidentiality → encrypt with RECIPIENT's public key (they decrypt with their private key)
- Signing → encrypt hash with YOUR private key (they verify with your public key)
The exam will offer answers that mix these up. Always ask: "Is the goal to keep it secret (recipient's public key) or to prove it's from me (my private key)?"
For encryption (confidentiality): Encrypt with the RECIPIENT's public key. Only the recipient's private key can decrypt it.
For digital signing (integrity/authentication/non-repudiation): Hash the document, then encrypt the hash with YOUR OWN private key. Anyone with your public key can verify — but only you could have created the signature.
Memorize the direction rule:
- Confidentiality → encrypt with RECIPIENT's public key (they decrypt with their private key)
- Signing → encrypt hash with YOUR private key (they verify with your public key)
The exam will offer answers that mix these up. Always ask: "Is the goal to keep it secret (recipient's public key) or to prove it's from me (my private key)?"
Trick 2: "The salt used in password hashing must be kept secret to be effective." True or False?
FALSE — the salt does not need to be secret.
The salt is stored in the database alongside the hash — it's typically stored in plaintext right next to the hashed password. An attacker who steals the database can see both the salt and the hash. That's fine — the salt still does its job.
The purpose of the salt is not secrecy — it's uniqueness. By making each user's pre-hash input unique, the salt ensures that: (1) two users with the same password have different hashes, and (2) precomputed rainbow tables are useless — the attacker must brute-force each account individually using that user's specific salt.
Even with the salt visible, an attacker must try millions of password candidates against each individual salt to crack one account — instead of looking up thousands of accounts in one precomputed table lookup.
The salt is stored in the database alongside the hash — it's typically stored in plaintext right next to the hashed password. An attacker who steals the database can see both the salt and the hash. That's fine — the salt still does its job.
The purpose of the salt is not secrecy — it's uniqueness. By making each user's pre-hash input unique, the salt ensures that: (1) two users with the same password have different hashes, and (2) precomputed rainbow tables are useless — the attacker must brute-force each account individually using that user's specific salt.
Even with the salt visible, an attacker must try millions of password candidates against each individual salt to crack one account — instead of looking up thousands of accounts in one precomputed table lookup.
Trick 3: "Hashing a message provides confidentiality — an attacker who intercepts the hash cannot read the original message." True or False?
FALSE — hashing provides INTEGRITY, not confidentiality.
A hash does not encrypt or conceal the original data. If you publish a file and its SHA-256 hash, anyone can compute the same hash from the file. The hash itself doesn't hide anything — it's a fingerprint used for comparison, not a lock.
Confidentiality requires encryption (AES, RSA, etc.). Hashing is purely for integrity verification: "Has this data changed?" not "Can I hide this data?"
The CIA Triad breakdown for hashing:
- Confidentiality: No
- Integrity: Yes
- Availability: No
This is a very common exam trap — especially in questions about what SHA-256 "provides" for a stored file.
A hash does not encrypt or conceal the original data. If you publish a file and its SHA-256 hash, anyone can compute the same hash from the file. The hash itself doesn't hide anything — it's a fingerprint used for comparison, not a lock.
Confidentiality requires encryption (AES, RSA, etc.). Hashing is purely for integrity verification: "Has this data changed?" not "Can I hide this data?"
The CIA Triad breakdown for hashing:
- Confidentiality: No
- Integrity: Yes
- Availability: No
This is a very common exam trap — especially in questions about what SHA-256 "provides" for a stored file.
Trick 4: "MD5 is insecure only because the hash is too short — using MD5 with a longer output would fix the problem." True or False?
FALSE — MD5's weakness is a fundamental algorithmic flaw, not just key length.
MD5 produces 128-bit hashes — which is shorter than SHA-256's 256 bits, so there are fewer possible outputs. But that's not why it's broken. The MD5 algorithm itself has mathematical weaknesses that allow collisions to be found far more easily than the theoretical 2^64 operations that 128-bit output might suggest.
Researchers found specific computational techniques to craft collision pairs. The problem is in the algorithm's internal structure (compression function weaknesses), not just the output size. You can't "fix" MD5 by producing a longer output using the same broken algorithm.
SHA-3 was designed as a fundamentally different algorithm (different internal structure called the sponge construction) specifically to provide a fresh design independent of SHA-2's lineage — as insurance against potential future SHA-2 weaknesses.
MD5 produces 128-bit hashes — which is shorter than SHA-256's 256 bits, so there are fewer possible outputs. But that's not why it's broken. The MD5 algorithm itself has mathematical weaknesses that allow collisions to be found far more easily than the theoretical 2^64 operations that 128-bit output might suggest.
Researchers found specific computational techniques to craft collision pairs. The problem is in the algorithm's internal structure (compression function weaknesses), not just the output size. You can't "fix" MD5 by producing a longer output using the same broken algorithm.
SHA-3 was designed as a fundamentally different algorithm (different internal structure called the sponge construction) specifically to provide a fresh design independent of SHA-2's lineage — as insurance against potential future SHA-2 weaknesses.
Trick 5: "A digital signature provides confidentiality for the signed document." True or False?
FALSE — digital signatures provide integrity, authentication, and non-repudiation. NOT confidentiality.
Signing a document does not hide it. A signed PDF is still readable by anyone. The signature proves who signed it and that it hasn't been modified — but it doesn't encrypt the content.
To get both: (1) sign the document (for integrity/authentication/non-repudiation), then (2) encrypt it (for confidentiality). These are separate operations that can be combined but don't automatically come together.
Common exam trap: a question describes a scenario where authentication AND confidentiality are needed. The answer is NOT "digital signature alone" — it's "encrypt AND sign" (or use a protocol that provides both, like S/MIME with both signing and encryption enabled).
Signing a document does not hide it. A signed PDF is still readable by anyone. The signature proves who signed it and that it hasn't been modified — but it doesn't encrypt the content.
To get both: (1) sign the document (for integrity/authentication/non-repudiation), then (2) encrypt it (for confidentiality). These are separate operations that can be combined but don't automatically come together.
Common exam trap: a question describes a scenario where authentication AND confidentiality are needed. The answer is NOT "digital signature alone" — it's "encrypt AND sign" (or use a protocol that provides both, like S/MIME with both signing and encryption enabled).
Performance Task: A software company distributes updates to 50,000 enterprise customers. Recently, a competitor's update channel was compromised and malware was distributed as a legitimate update. Design a code integrity and authentication system that would prevent or detect this attack.
Model Answer:
Problem analysis: The attack succeeded because customers had no way to verify (1) that the update came from the legitimate vendor, and (2) that the update hadn't been modified after publishing.
Solution — Code Signing Infrastructure:
Step 1 — Obtain a code signing certificate from a trusted CA. The vendor's code signing certificate is issued by a CA that customer operating systems and software trust by default. The certificate binds the company's identity to a public key.
Step 2 — Sign every release build before publication. After building the software package, compute its SHA-256 hash and sign it with the code signing certificate's private key. The private key is stored in an HSM (not exportable) — even a fully compromised build server cannot leak the signing key.
Step 3 — Publish SHA-256 hashes alongside downloads. Publish the expected SHA-256 hash on the download page (over HTTPS). This allows manual verification independent of the signature mechanism — a defense in depth layer.
Step 4 — Customer verification at installation. The update installer verifies the digital signature before executing: (1) computes SHA-256 of the downloaded package, (2) decrypts the signature with the vendor's public key (from their code signing certificate), (3) compares hashes. Match → proceed. Mismatch or invalid certificate → abort installation and alert administrator.
Step 5 — Implement update channel integrity. The update manifest (the list of available updates and their expected hashes) should itself be signed. If an attacker compromises the update server and modifies the manifest, the signature on the manifest won't verify — the client rejects the tampered manifest.
Result: An attacker who compromises the update distribution infrastructure can substitute files — but any substituted file will fail signature verification at the customer endpoint. The private signing key is in an HSM and was never on the distribution servers. The attack is detected at the customer before any malicious code executes.
Problem analysis: The attack succeeded because customers had no way to verify (1) that the update came from the legitimate vendor, and (2) that the update hadn't been modified after publishing.
Solution — Code Signing Infrastructure:
Step 1 — Obtain a code signing certificate from a trusted CA. The vendor's code signing certificate is issued by a CA that customer operating systems and software trust by default. The certificate binds the company's identity to a public key.
Step 2 — Sign every release build before publication. After building the software package, compute its SHA-256 hash and sign it with the code signing certificate's private key. The private key is stored in an HSM (not exportable) — even a fully compromised build server cannot leak the signing key.
Step 3 — Publish SHA-256 hashes alongside downloads. Publish the expected SHA-256 hash on the download page (over HTTPS). This allows manual verification independent of the signature mechanism — a defense in depth layer.
Step 4 — Customer verification at installation. The update installer verifies the digital signature before executing: (1) computes SHA-256 of the downloaded package, (2) decrypts the signature with the vendor's public key (from their code signing certificate), (3) compares hashes. Match → proceed. Mismatch or invalid certificate → abort installation and alert administrator.
Step 5 — Implement update channel integrity. The update manifest (the list of available updates and their expected hashes) should itself be signed. If an attacker compromises the update server and modifies the manifest, the signature on the manifest won't verify — the client rejects the tampered manifest.
Result: An attacker who compromises the update distribution infrastructure can substitute files — but any substituted file will fail signature verification at the customer endpoint. The private signing key is in an HSM and was never on the distribution servers. The attack is detected at the customer before any malicious code executes.