Question 2 of 7: Public-Key Communication, the Certificate Authority, and Diffie–Hellman vs. RSA

Question 2: Public-Key Communication, the Certificate Authority, and Diffie–Hellman vs. RSA (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part a) — both parties already have a public/private key pair. With each side already holding a public/private key pair, they can communicate securely with public-key (asymmetric) cryptography directly: the sender encrypts a message with the recipient's public key, so only the holder of the matching private key can decrypt it, and/or signs it with their own private key so the recipient can verify the sender's identity and that the message was not altered. Because asymmetric operations are computationally expensive for bulk data, real systems use a hybrid scheme: the public keys authenticate each other and establish a fresh, random symmetric session key (e.g. via a signed key exchange), and all subsequent traffic is protected with a faster symmetric cipher (Question 1) — the approach used by TLS/HTTPS.

Part b) — the certificate authority. A certificate authority (CA) is a trusted third party that verifies an entity's identity and then issues a digital certificate binding that identity to its public key, signing the certificate with the CA's own private key. Anyone who trusts the CA and holds its public key can verify the certificate's signature and thereby trust that the enclosed public key really belongs to the named party, without ever having had prior contact with that party. This directly prevents a man-in-the-middle (impersonation) attack: without a CA, an attacker sitting between the two parties could substitute their own public key while claiming to be the other party, silently intercepting and re-encrypting all "secure" traffic; because the attacker cannot forge a CA signature over a certificate binding the victim's identity to the attacker's key, a client that checks the certificate against a trusted CA rejects the substituted key.

Part c) — Diffie–Hellman versus RSA for establishing a shared key. Advantage of Diffie–Hellman: DH provides forward secrecy when fresh (ephemeral) private exponents $a, b$ are generated for each session — if a long-term key is later compromised, past session keys derived from discarded ephemeral values cannot be recovered, whereas with RSA key transport the session key is encrypted directly under the recipient's long-term public key, so compromise of that one long-term private key retroactively exposes every session key ever sent to it (no forward secrecy). Disadvantage of Diffie–Hellman: basic DH provides no authentication of the parties by itself (Question 1's public-key certificates must be layered on top to prevent a man-in-the-middle attack against the exchange), and it requires an interactive, two-way exchange of values before a shared key exists; RSA key transport can be one-way — the sender simply encrypts a chosen session key under the recipient's already-known public key and sends it, without needing the recipient to compute and return anything first.