Trick 1: "Diffie-Hellman is an encryption algorithm." True or False?
FALSE — Diffie-Hellman is a key EXCHANGE algorithm, not an encryption algorithm.
DH does not encrypt or decrypt any data. It is a mathematical process by which two parties establish a shared secret. That shared secret then becomes a symmetric key used by a separate encryption algorithm (like AES).
On the exam, the distinction matters: DH = key agreement. AES/3DES = encryption. RSA can do both (encrypt + key exchange), but DH only does key exchange. If a question asks "which algorithm is used to establish a shared secret," DH is the answer. If it asks "which algorithm encrypts the data," the answer is AES (or similar symmetric).
DH does not encrypt or decrypt any data. It is a mathematical process by which two parties establish a shared secret. That shared secret then becomes a symmetric key used by a separate encryption algorithm (like AES).
On the exam, the distinction matters: DH = key agreement. AES/3DES = encryption. RSA can do both (encrypt + key exchange), but DH only does key exchange. If a question asks "which algorithm is used to establish a shared secret," DH is the answer. If it asks "which algorithm encrypts the data," the answer is AES (or similar symmetric).
Trick 2: "Forward secrecy means that past sessions are protected even if today's session key is compromised." True or False?
Mostly true, but the precise definition is about the LONG-TERM key, not session keys.
Forward secrecy specifically means: compromise of the long-term private key does not expose past session keys. Because session keys are ephemeral and independently derived, there is nothing to "work backwards" from even if the server's long-term certificate key is later stolen.
If today's session key itself were compromised (e.g., through a memory dump), only today's session would be exposed — that's a different protection. Forward secrecy is specifically about protecting past sessions from long-term key compromise, not about protecting past sessions from session key compromise.
Exam tip: The trigger word is "past sessions." If a question asks what protects past sessions from future key compromise, the answer is forward secrecy / ephemeral keys / DHE / ECDHE.
Forward secrecy specifically means: compromise of the long-term private key does not expose past session keys. Because session keys are ephemeral and independently derived, there is nothing to "work backwards" from even if the server's long-term certificate key is later stolen.
If today's session key itself were compromised (e.g., through a memory dump), only today's session would be exposed — that's a different protection. Forward secrecy is specifically about protecting past sessions from long-term key compromise, not about protecting past sessions from session key compromise.
Exam tip: The trigger word is "past sessions." If a question asks what protects past sessions from future key compromise, the answer is forward secrecy / ephemeral keys / DHE / ECDHE.
Trick 3: "Out-of-band key exchange is more secure than in-band key exchange." True or False?
Not necessarily — it depends on the implementation of both.
Out-of-band exchange eliminates network interception risk but introduces physical security risks: courier interception, copied keys, social engineering. A poorly controlled out-of-band process (e.g., emailing the "out-of-band" key) is not secure at all.
In-band exchange with properly implemented ECDHE provides forward secrecy and mathematical guarantees that an eavesdropper cannot derive the shared secret — which is arguably more reliable than operational physical security controls.
The exam typically frames it as: out-of-band = impractical but traditional; in-band = practical, scalable, and cryptographically sound when done correctly. Neither is categorically "more secure" — context and implementation matter.
Out-of-band exchange eliminates network interception risk but introduces physical security risks: courier interception, copied keys, social engineering. A poorly controlled out-of-band process (e.g., emailing the "out-of-band" key) is not secure at all.
In-band exchange with properly implemented ECDHE provides forward secrecy and mathematical guarantees that an eavesdropper cannot derive the shared secret — which is arguably more reliable than operational physical security controls.
The exam typically frames it as: out-of-band = impractical but traditional; in-band = practical, scalable, and cryptographically sound when done correctly. Neither is categorically "more secure" — context and implementation matter.
Trick 4: "HTTPS uses asymmetric encryption to protect all communication between the browser and server." True or False?
FALSE — HTTPS uses asymmetric encryption ONLY for the key exchange phase.
This is a classic exam trap (also appears in the PKI chapter). The TLS handshake uses asymmetric encryption (or DH) to establish a shared session key. After that, ALL actual data — the web page, your login credentials, your form submissions — is encrypted using symmetric encryption (AES) with the session key.
Why? Asymmetric encryption is far too slow for bulk data. A typical web page download encrypted entirely with RSA would be 100-1000x slower than AES.
Correct statement: "HTTPS uses asymmetric encryption during the handshake to establish a shared symmetric session key, then uses symmetric encryption (AES) for the actual data."
This is a classic exam trap (also appears in the PKI chapter). The TLS handshake uses asymmetric encryption (or DH) to establish a shared session key. After that, ALL actual data — the web page, your login credentials, your form submissions — is encrypted using symmetric encryption (AES) with the session key.
Why? Asymmetric encryption is far too slow for bulk data. A typical web page download encrypted entirely with RSA would be 100-1000x slower than AES.
Correct statement: "HTTPS uses asymmetric encryption during the handshake to establish a shared symmetric session key, then uses symmetric encryption (AES) for the actual data."
Trick 5: "Using a longer RSA key for HTTPS provides forward secrecy." True or False?
FALSE — key length has nothing to do with forward secrecy.
Forward secrecy depends on the key exchange mechanism, not the key size. RSA-4096 used for key exchange does NOT provide forward secrecy — it just means the key would be harder to factor. If an attacker records traffic today and later obtains that 4096-bit private key, they can still decrypt all past sessions.
Forward secrecy requires ephemeral key exchange (DHE or ECDHE) so that each session's key is derived from temporary values that no longer exist after the session ends.
To get forward secrecy: use DHE or ECDHE — regardless of certificate key size. RSA key size and forward secrecy are orthogonal concerns.
Forward secrecy depends on the key exchange mechanism, not the key size. RSA-4096 used for key exchange does NOT provide forward secrecy — it just means the key would be harder to factor. If an attacker records traffic today and later obtains that 4096-bit private key, they can still decrypt all past sessions.
Forward secrecy requires ephemeral key exchange (DHE or ECDHE) so that each session's key is derived from temporary values that no longer exist after the session ends.
To get forward secrecy: use DHE or ECDHE — regardless of certificate key size. RSA key size and forward secrecy are orthogonal concerns.
Performance Task: A healthcare organization is being acquired. The acquirer's security team demands access to all encrypted communications from the past 3 years for legal due diligence. The organization's IT team reports they used TLS with ECDHE throughout. The acquirer insists the organization's certificate private key will be sufficient to decrypt the archives. Who is correct, and what are the implications?
Model Answer: The IT team is correct — ECDHE provides forward secrecy; the private key alone cannot decrypt archived sessions.
Technical explanation:
With ECDHE, each TLS session generated a unique ephemeral key pair. The session key was derived from the ephemeral values (which were discarded after each session) combined with the server's long-term key for authentication only. The server's certificate private key was used to authenticate the server's identity during the handshake — it did not encrypt the session data.
What the private key CAN do: Authenticate that traffic came from this server. Decrypt the handshake authentication portions. It cannot reconstruct the ephemeral keys, which were deleted when each session ended.
Implications for the acquirer:
1. The archived TLS traffic cannot be retroactively decrypted — this is a fundamental property of forward secrecy, not a policy choice the organization made.
2. If the acquirer needs historical communication records, they must seek them from application-layer logs, database records, or email archives — not from TLS decryption.
3. The organization should document this clearly: the inability to produce decrypted archives is not obstruction — it is a mathematical property of the encryption system in use.
Lesson: Forward secrecy protects users' privacy retroactively. Organizations that require forensic access to their own TLS communications must either: (a) use TLS inspection proxies that log decrypted traffic at the application layer, or (b) accept that ECDHE sessions cannot be retroactively decrypted.
Technical explanation:
With ECDHE, each TLS session generated a unique ephemeral key pair. The session key was derived from the ephemeral values (which were discarded after each session) combined with the server's long-term key for authentication only. The server's certificate private key was used to authenticate the server's identity during the handshake — it did not encrypt the session data.
What the private key CAN do: Authenticate that traffic came from this server. Decrypt the handshake authentication portions. It cannot reconstruct the ephemeral keys, which were deleted when each session ended.
Implications for the acquirer:
1. The archived TLS traffic cannot be retroactively decrypted — this is a fundamental property of forward secrecy, not a policy choice the organization made.
2. If the acquirer needs historical communication records, they must seek them from application-layer logs, database records, or email archives — not from TLS decryption.
3. The organization should document this clearly: the inability to produce decrypted archives is not obstruction — it is a mathematical property of the encryption system in use.
Lesson: Forward secrecy protects users' privacy retroactively. Organizations that require forensic access to their own TLS communications must either: (a) use TLS inspection proxies that log decrypted traffic at the application layer, or (b) accept that ECDHE sessions cannot be retroactively decrypted.