Key Distribution and Key Exchange

The lecturer first discussed some organizational points.

• The first midterm was intended partly as a way to give extra points and to see how the format worked.
• A common comment was that the questions were not too hard, but there was not enough time.
• The lecturer said that future exams would take this into account, probably by having fewer questions or questions that are easier to answer within the available time.
• This lecture starts the transition from symmetric-key cryptography to public-key cryptography.
• The lecturer described this as a “light start” into public-key cryptography, because not everyone has the same mathematical background.
• The more detailed mathematical background for the public-key part will be given later by Daniel.
• Next week there will be no lecture:
  • Monday: second midterm day.
  • Wednesday: the lecturer is traveling.
• A later recap and Q&A session was discussed.
  • Two possible dates were mentioned: July 22 and August 3.
  • The class voted for the later date, August 3, closer to the final exam.
  • The final exam was mentioned as being on August 6.
  • The recap session will likely contain short summaries and time for questions.

The course so far covered mostly the left side of the usual cryptography map:

• symmetric-key encryption for privacy;
• message authentication codes for authenticity.

This lecture begins the transition toward the public-key side.

The lecturer emphasized that today’s topic is not yet public-key encryption. Instead, the lecture is about the key-distribution problem and key exchange, which motivates why public-key cryptography is useful.

The broad map is:

\begin{array}{c|c|c} \text{Goal} & \text{Symmetric-key world} & \text{Public-key world} \\ \hline \text{Privacy} & \text{symmetric-key encryption} & \text{public-key encryption} \\ \text{Authenticity} & \text{message authentication codes} & \text{digital signatures} \end{array}

In private-key cryptography, both parties must already share a secret key.

If Alice and Bob share a key \(K\), then Alice can encrypt messages and Bob can decrypt them:

\[ c \leftarrow \mathsf{Enc}_K(m), \qquad m = \mathsf{Dec}_K(c). \]

Correctness says that if both parties have the same key, decryption works.

The problem is not decryption itself. The problem is:

\[ \textbf{How do Alice and Bob get the shared key } K \textbf{ in the first place?} \]

This is the key-distribution problem.

Historical situation.

In early cryptographic applications, this was less problematic.

Examples:

• military systems;
• banking systems;
• special-purpose devices.

In such settings, the parties or devices could often be prepared in advance. Keys could be physically installed or distributed before deployment.

Modern situation.

In modern open networks, this becomes much harder.

For example:

• Alice and Bob may live on different continents.
• Users of Signal or WhatsApp want end-to-end encryption without meeting in person.
• There may be hundreds of millions of users.
• It is unrealistic to physically pre-share a secret key with every possible communication partner.

So the core problem is:

\[ \boxed{ \text{How can two remote parties establish a shared secret key over the Internet?} } \]

The lecturer emphasized that private-key cryptography has not disappeared. There are still many modern situations where pre-shared symmetric keys are used.

SIM/USIM cards.

A SIM card already contains a symmetric key shared with the telecom provider.

This key can be used for authentication and encryption between the device and the telecom infrastructure.

IoT devices and sensors.

Small IoT devices often have limited computation power and limited battery capacity.

Public-key cryptography is usually more expensive than symmetric-key cryptography. Therefore, small devices may rely on pre-shared symmetric keys.

Wi-Fi.

Home Wi-Fi often uses a pre-shared key. The router and the user devices know the same password/key material.

So the point is:

\[ \boxed{ \text{Symmetric-key cryptography is efficient and still useful,} } \]

but it needs a way to distribute keys.

One classical idea is to introduce a trusted central entity:

\[ \text{KDC} = \text{Key Distribution Center}. \]

A KDC manages and distributes keys.

Basic setup.

Each user shares a long-term symmetric key with the KDC.

For example:

\[ K_A = \text{key shared by Alice and the KDC}, \]

\[ K_B = \text{key shared by Bob and the KDC}, \]

\[ K_C = \text{key shared by Charlie and the KDC}. \]

The KDC can store all these keys, but the lecturer also noted that this is not necessary.

Since we already know about PRFs, the KDC could store only one master PRF key and derive user-specific keys pseudorandomly:

\[ K_A = F_k(\text{Alice}), \]

\[ K_B = F_k(\text{Bob}), \]

\[ K_C = F_k(\text{Charlie}). \]

So the KDC does not necessarily need to store a huge table of all user keys.

Suppose Alice wants to talk securely to Bob.

Alice and Bob do not directly share a key. But Alice shares \(K_A\) with the KDC, and Bob shares \(K_B\) with the KDC.

The KDC protocol works as follows.

Step 1: Alice asks the KDC for a key to talk to Bob.

Alice sends a request:

\[ \text{``I want to talk to Bob.''} \]

Step 2: The KDC samples a fresh session key.

The KDC chooses:

\[ K \xleftarrow{\$} \{0,1\}^{\lambda}. \]

Here \(K\) is a fresh session key that Alice and Bob will use for their communication.

Step 3: The KDC sends encrypted copies of the session key.

The KDC sends Alice two ciphertexts:

\[ \mathsf{Enc}_{K_A}(K), \qquad \mathsf{Enc}_{K_B}(K). \]

The first ciphertext is for Alice. The second ciphertext is for Bob.

Step 4: Alice decrypts her part.

Alice uses \(K_A\) to decrypt:

\[ K = \mathsf{Dec}_{K_A}(\mathsf{Enc}_{K_A}(K)). \]

Now Alice knows the session key \(K\).

Step 5: Alice forwards Bob’s ciphertext to Bob.

Alice cannot decrypt

\[ \mathsf{Enc}_{K_B}(K), \]

because she does not know \(K_B\).

She simply forwards it to Bob.

Step 6: Bob decrypts his part.

Bob uses \(K_B\) to decrypt:

\[ K = \mathsf{Dec}_{K_B}(\mathsf{Enc}_{K_B}(K)). \]

Now Bob also knows \(K\).

After this, Alice and Bob can use ordinary symmetric-key encryption and MACs under the shared session key \(K\).

KDCs are only a partial solution.

The major problem is that the KDC is a trusted central point.

Problem 1: The KDC knows the session key.

The KDC generated \(K\), so it knows the key used by Alice and Bob.

Therefore, if the KDC can observe Alice and Bob’s communication, it can decrypt it.

This means the KDC is not just helping Alice and Bob establish a key; it is also technically capable of reading their communication.

Problem 2: The KDC is a single point of failure.

If the KDC is compromised, the attacker may compromise the security of many or all channels in the system.

The lecture summary point was:

\[ \boxed{ \text{Compromising the KDC compromises all other channels in the network.} } \]

Modern analogy.

The lecturer pointed out that a related idea still appears in modern systems like Signal and WhatsApp.

However, modern messengers do not use the server to distribute symmetric session keys in this simple KDC style.

Instead, their servers often help distribute public keys.

So the high-level idea

\[ \text{central server helps users find keys} \]

still exists, but the keys and security model are different.

KDCs do not fully solve key distribution in open systems.

Diffie and Hellman observed that many physical processes are asymmetric.

Examples:

• closing a padlock is easy, but opening it without the key is hard;
• shattering glass is easy, but reconstructing it is hard;
• running downhill is easier than running uphill;
• gaining weight may be easier than losing weight.

The general pattern is:

\[ \boxed{ \text{easy in one direction, hard in the reverse direction.} } \]

The cryptographic idea is to find a computational process with the same property.

That is, we want a function that is easy to compute but hard to reverse.

The lecturer used discrete logarithms as the motivating example.

In certain mathematical groups, exponentiation is easy:

\[ x \mapsto g^x. \]

Given \(x\), computing \(g^x\) is efficient.

But the reverse direction can be hard:

\[ g^x \mapsto x. \]

The problem of recovering \(x\) from \(g^x\) is the discrete logarithm problem.

The lecturer emphasized that this is not ordinary real-number logarithms from high school. For real numbers, logarithms can be computed efficiently using calculators.

The hard problem is discrete logarithm in suitable algebraic groups.

The intuition is:

\[ \boxed{ \text{I can reveal } g^x \text{ publicly while keeping } x \text{ secret.} } \]

Here:

• \(x\) is the secret value;
• \(g^x\) is the public value;
• computing \(g^x\) is easy;
• recovering \(x\) from \(g^x\) is assumed hard.

This is the basic idea behind public-key, or asymmetric-key, cryptography.

The terms are used interchangeably:

\[ \text{symmetric-key cryptography} \approx \text{private-key cryptography}, \]

\[ \text{asymmetric-key cryptography} \approx \text{public-key cryptography}. \]

A single puzzle is not enough.

If Alice sends Bob \(g^a\), Bob also cannot recover \(a\). So this alone does not give Bob a shared secret with Alice.

Diffie and Hellman’s idea was more subtle:

\[ \boxed{ \text{Alice sends Bob a puzzle, Bob sends Alice a puzzle,} } \]

and each party can combine:

• its own secret, and
• the other party’s public puzzle,

to compute the same shared value.

An eavesdropper only sees the public puzzles and should not be able to compute the shared value.

Let \(\mathbb{G}\) be a cyclic group of prime order \(p\), and let \(g\) be a generator.

The public parameters are:

\[ (\mathbb{G}, g). \]

In older textbook-style descriptions, Alice may generate these parameters. The lecturer noted that modern protocols usually do not let Alice choose arbitrary parameters during the protocol. Instead, modern systems use standardized, fixed parameters.

Alice’s first step.

Alice samples a secret exponent:

\[ a \xleftarrow{\$} \mathbb{Z}_p. \]

She computes:

\[ h_A = g^a. \]

She sends:

\[ (\mathbb{G}, g, h_A) \]

to Bob.

Here \(a\) is Alice’s private state, and \(h_A\) is Alice’s public puzzle.

Bob’s step.

Bob samples his secret exponent:

\[ b \xleftarrow{\$} \mathbb{Z}_p. \]

He computes:

\[ h_B = g^b. \]

He sends:

\[ h_B \]

to Alice.

Bob can already compute the shared key:

\[ K_B = h_A^b. \]

Since \(h_A = g^a\), this is:

\[ K_B = (g^a)^b = g^{ab}. \]

Alice’s final step.

Alice computes:

\[ K_A = h_B^a. \]

Since \(h_B = g^b\), this is:

\[ K_A = (g^b)^a = g^{ba}. \]

Since \(ab = ba\), both parties get the same value:

\[ K_A = K_B = g^{ab}. \]

This value is the shared key output by the key-exchange protocol.

Correctness means that Alice and Bob output the same key.

Formally:

\[ \Pr[K_A = K_B] = 1. \]

For Diffie-Hellman:

\[ K_A = h_B^a = (g^b)^a = g^{ba}, \]

and

\[ K_B = h_A^b = (g^a)^b = g^{ab}. \]

Therefore:

\[ K_A = K_B. \]

So the protocol is correct.

A passive eavesdropper sees only the public transcript:

\[ T = (\mathbb{G}, g, h_A, h_B). \]

That means the eavesdropper sees:

\[ h_A = g^a, \qquad h_B = g^b. \]

The eavesdropper does not know:

\[ a \qquad \text{or} \qquad b. \]

The shared key is:

\[ K = g^{ab}. \]

The intended security intuition is:

\[ \boxed{ \text{Given } g^a \text{ and } g^b, \text{ it should be hard to compute or recognize } g^{ab}. } \]

A key-exchange protocol is denoted by:

\[ \Pi. \]

Unlike encryption or MAC algorithms, a key-exchange protocol involves active interaction between two parties.

For example, in encryption, Alice can send a ciphertext while Bob is offline. Bob can decrypt it later.

In key exchange, Alice and Bob interact during the same session by exchanging messages.

A key-exchange protocol consists of algorithms or instructions for Alice and Bob. These algorithms output:

• private state;
• public messages;
• final keys.

Let \(T\) denote the public transcript of the protocol.

The transcript contains all public messages sent during the protocol. It is what an outside observer can see.

A run of the protocol is written as:

\[ (T,K) \leftarrow \Pi(1^\lambda). \]

This means:

• the protocol is run with security parameter \(1^\lambda\);
• all random coins are sampled uniformly;
• the run outputs a public transcript \(T\);
• the honest parties output a key \(K\).

For Diffie-Hellman, the protocol can be written as:

\[ \Pi = (\mathsf{Alice}_1, \mathsf{Bob}, \mathsf{Alice}_2). \]

Alice’s first algorithm.

\[ \mathsf{Alice}_1(1^\lambda) \to ((\mathbb{G}, a),(\mathbb{G}, g, h_A)). \]

Here:

• \((\mathbb{G},a)\) is Alice’s private state;
• \((\mathbb{G},g,h_A)\) is Alice’s outgoing public message;
• \(h_A = g^a\).

Bob’s algorithm.

Bob receives Alice’s public message. He samples \(b\), computes \(h_B = g^b\), and computes:

\[ K_B = h_A^b. \]

So Bob outputs:

\[ \mathsf{Bob}(\mathbb{G}, g, h_A) \to (K_B,h_B). \]

Alice’s second algorithm.

Alice receives \(h_B\). Using her private state \((\mathbb{G},a)\), she computes:

\[ K_A = h_B^a. \]

So:

\[ \mathsf{Alice}_2((\mathbb{G},a),h_B) \to K_A. \]

Transcript.

The public transcript is:

\[ T = (\mathbb{G}, g, h_A, h_B). \]

Correctness.

\[ \Pr[K_A = K_B] = 1. \]

The lecture then defined security against a passive eavesdropper.

Let:

\[ (T,K) \leftarrow \Pi(1^\lambda) \]

be a real protocol execution.

Let:

\[ \widehat{K} \xleftarrow{\$} \{0,1\}^{\lambda} \]

be a uniformly random key of the same length.

A key-exchange protocol \(\Pi\) is secure against eavesdropping if every PPT distinguisher \(\mathcal{D}\) has only negligible advantage in distinguishing:

\[ (T,K) \]

from

\[ (T,\widehat{K}). \]

Formally:

\begin{equation*} \left| \Pr[\mathcal{D}(T,K)=1] - \Pr[\mathcal{D}(T,\widehat{K})=1] \right| \leq \mathsf{negl}(\lambda). \end{equation*}

The probability is taken over:

• the randomness of the protocol run;
• the generated transcript \(T\);
• the real key \(K\);
• the independently random key \(\widehat{K}\);
• the randomness of the distinguisher.

Intuition.

The adversary sees the transcript \(T\).

Then the adversary is given a candidate key.

The adversary’s task is to decide:

\[ \text{Is this the real session key, or just a random string?} \]

Security means the adversary cannot tell, except with negligible advantage.

This is similar in spirit to earlier indistinguishability definitions in symmetric-key cryptography.

The lecturer then discussed what computational assumption is needed to prove Diffie-Hellman secure.

A tempting idea is to use the discrete logarithm assumption:

\[ \text{given } g^a, \text{ it is hard to compute } a. \]

This is indeed relevant, but it is not exactly the right assumption for the key-exchange security definition.

The reason is that the adversary’s goal is not necessarily to recover Alice’s secret \(a\) or Bob’s secret \(b\).

The adversary’s goal in the security definition is only to distinguish:

\[ K = g^{ab} \]

from a random key.

Recovering \(a\) from \(g^a\) is one possible way to attack Diffie-Hellman:

1. Observe \(h_A = g^a\).
2. Compute \(a\).
3. Use \(h_B = g^b\).
4. Compute \(K = h_B^a = g^{ab}\).

But this is only one strategy.

The adversary might distinguish the real key from random without explicitly recovering \(a\) or \(b\).

Therefore, the security proof for Diffie-Hellman uses the Decisional Diffie-Hellman assumption.

Let \(\mathbb{G} = \langle g \rangle\) be a cyclic group with order

\[ m = |\mathbb{G}| \geq 2^\lambda. \]

The Decisional Diffie-Hellman problem asks whether the following two distributions are computationally indistinguishable:

\[ (m,g,g^x,g^y,g^{xy}) \]

and

\[ (m,g,g^x,g^y,g^r), \]

where

\[ x,y,r \xleftarrow{\$} \mathbb{Z}_m. \]

The DDH assumption says that for every PPT adversary \(\mathcal{A}\),

\begin{equation*} \left| \Pr[\mathcal{A}(m,g,g^x,g^y,g^{xy})=1] - \Pr[\mathcal{A}(m,g,g^x,g^y,g^r)=1] \right| \leq \mathsf{negl}(\lambda). \end{equation*}

Interpretation.

The adversary receives:

\[ g^x, \qquad g^y, \qquad u. \]

It must decide whether:

\[ u = g^{xy} \]

or whether:

\[ u = g^r \]

for a fresh random exponent \(r\).

This is exactly related to Diffie-Hellman key exchange:

\[ h_A = g^a, \qquad h_B = g^b, \qquad K = g^{ab}. \]

So DDH says that the real Diffie-Hellman shared key looks random to an efficient adversary who only sees the public transcript.

The lecturer emphasized the relationship between the discrete logarithm problem and DDH.

If one can solve discrete logarithms, then one can solve DDH.

Suppose there is an algorithm:

\[ \mathcal{O}_{\mathsf{DLog}}(g^x) = x. \]

Given a DDH challenge:

\[ (m,g,g^x,g^y,u), \]

we can do:

1. Compute

   \[ x = \mathcal{O}_{\mathsf{DLog}}(g^x). \]

2. Compute

   \[ (g^y)^x = g^{xy}. \]

3. Compare this value with \(u\).

If

\[ u = (g^y)^x, \]

then guess that \(u = g^{xy}\).

Otherwise, guess that \(u\) is random.

Thus:

\[ \text{DLOG solver} \Longrightarrow \text{DDH solver}. \]

So as a computational problem, DDH is no harder than DLOG.

Equivalently:

\[ \boxed{ \text{DLOG is at least as hard as DDH.} } \]

However, the reverse direction is not known in general:

\begin{equation*} \text{DDH solver} \not\Longrightarrow \text{DLOG solver}. \end{equation*}

The lecturer mentioned that in some idealized or generic models, these problems can be related more closely, but that is outside the scope of this basic lecture.

The important lecture point is:

\[ \boxed{ \text{Diffie-Hellman key exchange security against eavesdropping is based on DDH,} } \]

not merely on the statement that discrete logarithms are hard.

The previous security definition only protects against passive eavesdroppers.

A passive adversary only observes the transcript:

\[ T = (\mathbb{G},g,h_A,h_B). \]

It does not modify messages.

But in real networks, an attacker may be active.

An active attacker can intercept, replace, and inject messages.

The basic Diffie-Hellman protocol shown so far is vulnerable to such an active attack.

Basic Diffie-Hellman does not authenticate the parties.

Alice has no way to know that the value she receives really came from Bob. Bob has no way to know that the value he receives really came from Alice.

This allows a man-in-the-middle attack.

Let Alice choose:

\[ x \xleftarrow{\$} \mathbb{Z}_p \]

and send:

\[ A = g^x. \]

Let Bob choose:

\[ y \xleftarrow{\$} \mathbb{Z}_p \]

and send:

\[ B = g^y. \]

Eve sits between them.

Attack against Alice.

Eve intercepts Alice’s value \(A = g^x\).

Instead of forwarding Bob’s real value to Alice, Eve sends Alice her own value:

\[ \widehat{B} = g^{\widehat{y}}. \]

Alice computes:

\[ \widehat{K}_A = \widehat{B}^x = g^{x\widehat{y}}. \]

Eve also knows this key, because she knows \(\widehat{y}\) and sees \(A = g^x\):

\[ \widehat{K}_A = A^{\widehat{y}} = g^{x\widehat{y}}. \]

Attack against Bob.

Eve intercepts Bob’s value \(B = g^y\).

Instead of forwarding Alice’s real value to Bob, Eve sends Bob her own value:

\[ \widehat{A} = g^{\widehat{x}}. \]

Bob computes:

\[ \widehat{K}_B = \widehat{A}^y = g^{\widehat{x}y}. \]

Eve also knows this key, because she knows \(\widehat{x}\) and sees \(B = g^y\):

\[ \widehat{K}_B = B^{\widehat{x}} = g^{\widehat{x}y}. \]

So Alice and Bob do not share one key with each other.

Instead:

\[ \text{Alice shares } \widehat{K}_A \text{ with Eve}, \]

and

\[ \text{Bob shares } \widehat{K}_B \text{ with Eve}. \]

Alice thinks she is talking to Bob. Bob thinks he is talking to Alice. In reality, both are talking to Eve.

After the man-in-the-middle key exchange:

• Alice encrypts messages under \(\widehat{K}_A\).
• Eve decrypts them using \(\widehat{K}_A\).
• Eve reads or modifies the plaintext.
• Eve re-encrypts the message under \(\widehat{K}_B\).
• Bob decrypts it and believes it came from Alice.

In the other direction:

• Bob encrypts under \(\widehat{K}_B\).
• Eve decrypts using \(\widehat{K}_B\).
• Eve reads or modifies the plaintext.
• Eve re-encrypts under \(\widehat{K}_A\).
• Alice decrypts it and believes it came from Bob.

Thus Eve can see the whole conversation.

This is why the lecturer emphasized:

\[ \boxed{ \text{Basic Diffie-Hellman protects only against passive eavesdroppers.} } \]

It does not by itself provide authentication.

The exact textbook Diffie-Hellman protocol shown in the lecture is not used directly in practice, because it is vulnerable to man-in-the-middle attacks.

However, enhanced versions of Diffie-Hellman-style key exchange are widely used.

Examples mentioned in the lecture:

• TLS;
• SSH;
• WireGuard.

These protocols add mechanisms that protect against man-in-the-middle attacks.

The general idea is that the exchanged Diffie-Hellman values must be authenticated somehow.

For example, in TLS, when a client connects to a server, the server provides a certificate. The certificate contains a public key or authenticated public-key information. This helps the client know that it is really talking to the intended server, not to a man-in-the-middle.

The protocol can then still use a Diffie-Hellman-style exchange to establish a fresh session key.

So the important practical point is:

\[ \boxed{ \text{Diffie-Hellman is still used, but in authenticated/enhanced forms.} } \]

The lecturer summarized the lecture with the following main points.

Private-key encryption is useful in closed systems with pre-shared keys.

Examples include:

• SIM/USIM cards;
• IoT devices and sensors;
• Wi-Fi pre-shared keys.

Symmetric-key cryptography remains important because it is efficient.

Open systems need a key-distribution mechanism.

In an open Internet setting, users cannot physically pre-share keys with everyone they may want to communicate with.

KDCs offer a partial solution.

A Key Distribution Center can help users establish a session key.

But this has serious limitations:

• the KDC knows the session keys;
• the KDC is a single point of failure;
• compromising the KDC compromises many channels.

Key exchange protocols offer a scalable solution.

Diffie-Hellman shows how two parties can establish a shared key over a public channel.

The shared key is:

\[ K = g^{ab}. \]

Alice and Bob can compute it using their own secrets and the other party’s public value.

A passive eavesdropper only sees:

\[ g^a \qquad \text{and} \qquad g^b, \]

and should not be able to distinguish \(g^{ab}\) from random under the DDH assumption.

Without setup or authentication, key exchange is vulnerable to man-in-the-middle attacks.

Basic Diffie-Hellman does not authenticate the parties.

Therefore, an active attacker can replace public values and establish separate keys with Alice and Bob.

Modern protocols solve this by using enhanced, authenticated key exchange.

1. Symmetric-key cryptography is efficient, but requires shared keys.

2. The central question is key distribution:

   \[ \text{How do remote parties obtain a shared secret?} \]

3. KDCs solve part of the problem but introduce a powerful trusted central point.

4. Public-key ideas come from computational asymmetry:

   \[ \text{easy forward computation, hard reverse computation.} \]

5. In suitable groups:

   \[ x \mapsto g^x \]

   is easy, but recovering \(x\) from \(g^x\) is hard.

6. Diffie-Hellman lets Alice and Bob compute:

   \[ g^{ab} \]

   without sending \(a\), \(b\), or \(g^{ab}\) directly.

7. The eavesdropping security of Diffie-Hellman is formalized by indistinguishability of the real key from a random key.

8. The relevant assumption is DDH:

   \[ (g^x,g^y,g^{xy}) \approx_c (g^x,g^y,g^r). \]

9. Basic Diffie-Hellman is not secure against active attackers.
10. Practical systems use authenticated or enhanced key exchange, such as in TLS, SSH, and WireGuard.