CEH Cryptography and Malware Analysis Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Diffie-Hellman (DH) key exchange

  Why it's wrong here

  Standard Diffie-Hellman alone negotiates a shared secret without any server authentication, so it cannot establish a trusted HTTPS session because it lacks a mechanism to bind the key exchange to the server’s certificate. It is tempting because DH does provide ephemeral keying for PFS when combined with signatures (as in DHE), but the plain DH mode is actually intended for anonymous key agreement where authentication is handled separately or not required.

• ✓

  Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)

  Why this is correct

  Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) is the correct choice because it provides Perfect Forward Secrecy (PFS) by generating unique, ephemeral session keys for each TLS handshake. This means that even if the server's long-term private key is compromised in the future, an attacker cannot decrypt previously recorded sessions. The ephemeral keys are derived using elliptic curve cryptography, offering strong security with smaller key sizes and faster computations compared to traditional Diffie-Hellman, making it ideal for web servers.

• ✗

  Pre-Shared Key (PSK)

  Why it's wrong here

  Pre-Shared Key (PSK) key exchange is generally unsuitable for public web servers due to significant scalability and key management challenges, as each client would need to share a unique secret with the server beforehand. Furthermore, PSK does not inherently provide Perfect Forward Secrecy (PFS); if the pre-shared key is ever compromised, all past and future communications encrypted with that key become vulnerable to decryption. Its primary applications are typically in closed environments like VPNs or IoT devices where key distribution can be tightly controlled.

• ✗

  RSA key exchange

  Why it's wrong here

  RSA key exchange, while historically common, does not offer Perfect Forward Secrecy (PFS), making it an insecure choice for modern web servers. In this method, the client encrypts a pre-master secret using the server's static public RSA key, which the server then decrypts with its corresponding private key. Consequently, if the server's long-term private key is ever compromised, an attacker can retroactively decrypt all past recorded TLS sessions that used this key exchange mechanism, completely undermining confidentiality.

Go deeper

Related to this question