Key exchange method in https

Let’s dive into how the key exchange works in HTTPS, focusing on the interplay between asymmetric and symmetric encryption, and then provide simple examples to illustrate how RSA and Diffie-Hellman (DH) facilitate this process in the TLS handshake.

---

Overview of Key Exchange in HTTPS

In HTTPS, the key exchange is part of the TLS handshake, which establishes a secure channel between the client (e.g., browser) and server. The goal is to securely agree on a symmetric session key that both sides will use to encrypt and decrypt data. This process leverages both asymmetric and symmetric encryption:

• Asymmetric Encryption: Uses a pair of keys (public and private) to securely exchange information. It’s slower but secure for small data like keys.
• Symmetric Encryption: Uses a single shared key for both encryption and decryption. It’s fast and used for the bulk of data transfer once the session key is established.

The key exchange ensures that even if an attacker intercepts the communication, they can’t derive the session key without the private keys.

---

Why Two Types of Encryption?

• Asymmetric: Ideal for securely sharing the session key over an untrusted network, as only the public key is exposed.
• Symmetric: Efficient for encrypting large amounts of data (e.g., web pages, videos) after the key is shared.

The key exchange bridges these two: asymmetric encryption secures the initial setup, and symmetric encryption takes over for the session.

---

Key Exchange Process in TLS

1. Client and Server Agree on a Method: During the TLS handshake (ClientHello and ServerHello), they negotiate a cipher suite (e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384), which specifies the key exchange method (RSA or DH), symmetric algorithm (e.g., AES), and more.
2. Key Exchange Happens: The chosen method (RSA or Diffie-Hellman) securely shares a premaster secret.
3. Session Key Derived: Both sides use the premaster secret (plus random nonces from the handshake) to generate the same symmetric session key.
4. Switch to Symmetric: All further communication uses this session key with a symmetric algorithm like AES.

Now, let’s explore the two main key exchange methods: RSA and Diffie-Hellman.

---

RSA Key Exchange (Asymmetric)

How It Works:

• RSA relies on a public-private key pair generated by the server.
• The server sends its public key in its certificate during the TLS handshake.
• The client uses this public key to encrypt a secret (the premaster secret) and sends it to the server.
• The server decrypts it with its private key, which only it possesses.

Simple Example:

• Setup:
  • Server’s public key: (e=3, n=33) (simplified; real RSA uses huge numbers).
  • Server’s private key: (d=7, n=33).
  • Client wants to send premaster secret: 5.
• Encryption by Client:
  • Formula: ciphertext = (plaintext^e) mod n.
  • 5^3 mod 33 = 125 mod 33 = 26.
  • Client sends 26 to the server.
• Decryption by Server:
  • Formula: plaintext = (ciphertext^d) mod n.
  • 26^7 mod 33 = 5 (after computation).
  • Server recovers 5.
• Result: Both now have the premaster secret 5, which they use to derive the session key.

Pros:

• Simple and historically common.
• Server authentication is built-in (via the certificate).

Cons:

• No forward secrecy: If the server’s private key is later compromised, past sessions can be decrypted (since the premaster secret was encrypted with it).

---

Diffie-Hellman Key Exchange (Asymmetric, with Forward Secrecy)

How It Works:

• Diffie-Hellman (DH) allows both parties to independently compute the same secret without ever sending it over the network.
• It uses modular arithmetic and a shared base (g) and modulus (p), plus private-public key pairs generated on the fly.
• Modern TLS often uses Elliptic Curve Diffie-Hellman (ECDHE) for efficiency, but the concept is the same.

Simple Example:

• Setup:
  • Public values (agreed upon): g = 5, p = 23 (small for simplicity; real values are huge).
  • Client’s private key: a = 6 (kept secret).
  • Server’s private key: b = 15 (kept secret).
• Step 1: Generate Public Values:
  • Client: A = g^a mod p = 5^6 mod 23 = 15625 mod 23 = 8.
  • Server: B = g^b mod p = 5^15 mod 23 = 5^15 mod 23 = 19 (computed).
  • Client sends A = 8 to server; server sends B = 19 to client.
• Step 2: Compute Shared Secret:
  • Client: B^a mod p = 19^6 mod 23 = 7.
  • Server: A^b mod p = 8^15 mod 23 = 7.
• Result: Both derive the same premaster secret 7, used to generate the session key.

Key Insight:

• An attacker sees g=5, p=23, A=8, and B=19, but solving for a or b (the discrete logarithm problem) is computationally infeasible with large numbers.

Pros:

• Forward secrecy: Session keys are ephemeral (temporary), so compromising the server’s long-term private key doesn’t expose past sessions.
• No direct secret transmission.

Cons:

• Slightly more complex than RSA.

---

Asymmetric vs. Symmetric in Action

• Asymmetric Phase (RSA or DH):
  • RSA: Client encrypts premaster secret with server’s public key.
  • DH: Client and server exchange public values to compute the premaster secret.
  • Outcome: Both have the premaster secret (e.g., 5 or 7 in examples).
• Symmetric Phase:
  • Premaster secret + nonces (from ClientHello/ServerHello) → Session key (e.g., a 256-bit AES key).
  • Example: AES encryption of “Hello” with key K becomes gibberish to outsiders but is decrypted back to “Hello” by the other side.

TLS Handshake:
Client <--> Server: [RSA or DH] → Session Key "K"

Data Transfer:
Server: HTML/Images → AES-encrypt(..., K) → Encrypted Data → Client
Client: Encrypted Data → AES-decrypt(..., K) → HTML/Images

---

Putting It Together in HTTPS

1. TLS Handshake:
   • Client: “I support ECDHE with AES.”
   • Server: “Here’s my cert and ECDHE public value.”
   • Client verifies cert, sends its ECDHE public value.
   • Both compute the same session key (e.g., via ECDHE).
2. Secure Communication:
   • Client sends encrypted GET / using AES with the session key.
   • Server responds with encrypted HTML.

---

RSA vs. DH in HTTPS

Aspect	RSA	Diffie-Hellman (ECDHE)
Mechanism	Encrypt premaster secret	Compute shared secret
Forward Secrecy	No	Yes
Speed	Slower (larger keys)	Faster (elliptic curves)
TLS Usage	Legacy (pre-TLS 1.3)	Standard (TLS 1.2, 1.3)

Modern Preference: ECDHE is favored in TLS 1.3 for forward secrecy and performance; RSA is phased out for key exchange (though still used for authentication via certificates).