Trick 1: "To send an encrypted message to Bob, you use YOUR private key." True or False?
FALSE — and this is one of the most common PKI exam traps.
To send an encrypted message to Bob, you use Bob's PUBLIC key. Only Bob's private key can decrypt it.
Your private key is used for digital signatures — to sign something that proves it came from you. The direction matters:
- Encrypt for someone → use THEIR public key
- Sign something → use YOUR private key
Mixing these up is the #1 PKI exam mistake.
To send an encrypted message to Bob, you use Bob's PUBLIC key. Only Bob's private key can decrypt it.
Your private key is used for digital signatures — to sign something that proves it came from you. The direction matters:
- Encrypt for someone → use THEIR public key
- Sign something → use YOUR private key
Mixing these up is the #1 PKI exam mistake.
Trick 2: "If you have someone's public key and the algorithm, you can figure out their private key given enough time." True or False?
FALSE — computationally infeasible, not just difficult.
The mathematical relationship between public and private keys (based on very large prime numbers) is designed so that reversing it is computationally infeasible with current and foreseeable technology. This isn't "it would take a long time" — it's "it would take longer than the age of the universe with today's hardware."
This property is fundamental to asymmetric security. The exam may word it as "with sufficient computational resources" — still false for properly sized modern keys.
The mathematical relationship between public and private keys (based on very large prime numbers) is designed so that reversing it is computationally infeasible with current and foreseeable technology. This isn't "it would take a long time" — it's "it would take longer than the age of the universe with today's hardware."
This property is fundamental to asymmetric security. The exam may word it as "with sufficient computational resources" — still false for properly sized modern keys.
Trick 3: "HTTPS uses only asymmetric encryption." True or False?
FALSE — HTTPS uses hybrid encryption.
Asymmetric encryption is only used during the TLS handshake to exchange the symmetric session key. The actual web traffic (the page content, your form data, your login credentials) is encrypted using fast symmetric encryption with the session key.
If HTTPS used only asymmetric encryption, it would be too slow for practical use. The hybrid model is what makes encrypted web browsing feasible at scale.
Asymmetric encryption is only used during the TLS handshake to exchange the symmetric session key. The actual web traffic (the page content, your form data, your login credentials) is encrypted using fast symmetric encryption with the session key.
If HTTPS used only asymmetric encryption, it would be too slow for practical use. The hybrid model is what makes encrypted web browsing feasible at scale.
Trick 4: "Symmetric encryption is less secure than asymmetric encryption." True or False?
FALSE — they solve different problems, and symmetric can be very secure.
AES-256 (symmetric) is one of the most secure encryption algorithms in existence. The weakness of symmetric encryption is not the algorithm — it's the key distribution problem. Once both parties have the key, symmetric encryption is robust.
Asymmetric encryption solves the distribution problem. Symmetric is used for the actual data because of its speed. Neither is "more secure" in absolute terms — they are complementary technologies addressing different challenges.
AES-256 (symmetric) is one of the most secure encryption algorithms in existence. The weakness of symmetric encryption is not the algorithm — it's the key distribution problem. Once both parties have the key, symmetric encryption is robust.
Asymmetric encryption solves the distribution problem. Symmetric is used for the actual data because of its speed. Neither is "more secure" in absolute terms — they are complementary technologies addressing different challenges.
Trick 5: "Key escrow is equivalent to giving everyone access to your private key." True or False?
FALSE — key escrow with proper controls is very different.
Key escrow with proper implementation means:
- Keys stored in a Hardware Security Module (HSM) vault
- Access requires multi-person authorization (dual control)
- Full audit logging of all access attempts
- Access only granted with legal justification and approval
This is NOT the same as giving everyone your key. Proper escrow is more like a bank's safe deposit box with dual keys — the bank and you both have a key, but accessing the box without you requires formal procedure and oversight.
Improper escrow (e.g., storing keys in a spreadsheet) IS dangerous. The implementation matters enormously.
Key escrow with proper implementation means:
- Keys stored in a Hardware Security Module (HSM) vault
- Access requires multi-person authorization (dual control)
- Full audit logging of all access attempts
- Access only granted with legal justification and approval
This is NOT the same as giving everyone your key. Proper escrow is more like a bank's safe deposit box with dual keys — the bank and you both have a key, but accessing the box without you requires formal procedure and oversight.
Improper escrow (e.g., storing keys in a spreadsheet) IS dangerous. The implementation matters enormously.
Performance Task: Your organization has 500 employees. Design an asymmetric key management strategy that covers: key generation, public key distribution, private key protection, key escrow, and what happens when an employee leaves.
Model Answer:
1. Key generation: Each employee generates their key pair through a centralized PKI tool — standardized algorithm (RSA 3072-bit or ECC 256-bit), strong randomness source. IT can batch-generate for new hires.
2. Public key distribution: All public keys published to an internal LDAP/Active Directory directory. Automatically available to all email clients. Employees can also upload to public keyservers if they interact with external parties.
3. Private key protection: Private key stored locally in an OS keystore or hardware token (smart card/YubiKey). Protected by a strong passphrase that only the employee knows. Keys never transmitted via email.
4. Key escrow: A copy of each private key encrypted with the PKI master key and stored in an on-premises HSM. Access requires: written justification + approval from two senior managers + logged by the security team. Annual audit of access log.
5. Employee departure: Upon departure: (a) Employee's public key marked as revoked in the directory. (b) Their escrowed private key remains in HSM for 7 years (to decrypt any legacy files). (c) Former employee's access to their private key is terminated immediately. (d) Any documents they encrypted can still be accessed via the escrowed copy with proper authorization.
1. Key generation: Each employee generates their key pair through a centralized PKI tool — standardized algorithm (RSA 3072-bit or ECC 256-bit), strong randomness source. IT can batch-generate for new hires.
2. Public key distribution: All public keys published to an internal LDAP/Active Directory directory. Automatically available to all email clients. Employees can also upload to public keyservers if they interact with external parties.
3. Private key protection: Private key stored locally in an OS keystore or hardware token (smart card/YubiKey). Protected by a strong passphrase that only the employee knows. Keys never transmitted via email.
4. Key escrow: A copy of each private key encrypted with the PKI master key and stored in an on-premises HSM. Access requires: written justification + approval from two senior managers + logged by the security team. Annual audit of access log.
5. Employee departure: Upon departure: (a) Employee's public key marked as revoked in the directory. (b) Their escrowed private key remains in HSM for 7 years (to decrypt any legacy files). (c) Former employee's access to their private key is terminated immediately. (d) Any documents they encrypted can still be accessed via the escrowed copy with proper authorization.