The key-distribution problem

The chapter on symmetric encryption ended with a good result and a hidden problem. One secret key scrambles a message, and the same key unscrambles it. But both sides need that key before they can talk safely. How does it get there?

This is the key-distribution problem, and it is harder than it looks. Try the obvious answers one by one.

Send the key over the internet. The key is just a long number, so you could email it or put it in a chat. But that is the same open network you wanted to protect. Anyone who copies the message now has the key. From then on they can read everything you encrypt with it. Worse, you will never know. Copying a number leaves no trace: the copy is exactly the same as the original.

Send it separately. “I’ll send the file today and the password tomorrow, in a different email.” It feels safer, but both messages cross the same network. Someone who reads the network every day collects both.

Lock the key with another key. You could encrypt the new key before sending it. But the other side needs a key to unlock it, and that key had to reach them somehow. You have moved the problem one step back, not solved it.

Meet in person. Hand the key over on a USB stick or read it out face to face. Nobody on the network sees it. This is called out-of-band delivery: the key travels by a different, safer route than the data. It works. It is also slow, and it does not scale.

Why does it not scale? Because every pair of people who want a private conversation needs their own key. If three friends each want to talk privately with each other, they need three keys. Ten people need 45. A company of 1,000 people would need 499,500 keys, each one handed over safely, stored and eventually replaced.

The shortcut is to give everyone the same key. Then anyone in the group can read everybody’s messages, and one lost laptop exposes the whole group’s traffic.

Swipe sideways to see the whole diagram.

How many keys does a group need?

If every pair of people in a group of n needs its own secret key, the number of keys is n × (n − 1) / 2. Each new person who joins a group of n adds n new keys, one with each existing member.

The count is only half of the cost. Each key must be:

• generated from a secure random source;
• delivered without anyone else seeing it;
• stored safely at both ends;
• replaced when it may have leaked, or when one of its two holders leaves.

Swipe sideways to see the whole diagram.

What is out-of-band delivery?

Out-of-band means the key travels by a channel the attacker cannot read, separate from the network the data uses. Examples:

• handing over a device or a paper sealed envelope in person;
• loading a key into a device in the factory before it ships;
• reading a short value aloud over a phone call to a voice you recognise.

Out-of-band delivery is still used for the most important keys, such as the root keys of certificate authorities (see guarding the keys). But it costs time and people, so it cannot be the everyday answer for millions of connections.

What is a pre-shared key?

A pre-shared key (PSK) is a symmetric key that everyone in a group was given in advance. You use them all the time:

• the password of a home Wi-Fi network;
• the shared secret in many site-to-site VPN setups;
• an API key or webhook secret that two systems both know;
• the external PSK mode of TLS 1.3 (RFC 9846, section 2.2), used mainly between machines that were configured together.

Everyone who holds a PSK is in one trust group. Anyone in the group can read, and usually forge, the group’s traffic. When one member leaves or one device is lost, the key must change for everyone.

What is a key distribution centre?

The first big improvement was a trusted middleman. In a key distribution centre (KDC) design, each person shares one long-term key with the centre, so n people need only n keys. When Alice wants to talk to Bob, the centre makes a fresh session key and gives Alice two copies: one encrypted under her own long-term key, and one inside a “ticket” encrypted under Bob’s key, which she passes on to Bob. Only Alice and Bob (and the centre) can read the session key.

The best-known KDC protocol is Kerberos (RFC 4120), which is designed for an open network where, in its own words, “packets traveling along the network can be read, modified, and inserted at will”. Section 1.1 of the RFC describes the basic exchange just as above. Real Kerberos adds one step: at logon, Alice’s long-term key gets her a ticket-granting ticket, and she uses that, not her long-term key, to ask for tickets to each service. In a Windows domain, the KDC runs on every domain controller (Microsoft Learn).

The price is central trust:

• the centre must be online to hand out keys for new conversations (tickets can be reused until they expire);
• it creates every session key, so it could read every conversation;
• it holds everyone’s long-term keys, so it is the single most valuable target in the network. RFC 4120 expects the authentication servers to run on “physically secure hosts”.

What is the way out?

In 1976, Whitfield Diffie and Martin Hellman published “New Directions in Cryptography”. It described two ideas that change the maths of key distribution:

1. Key pairs. Each person has two related keys: one they publish freely and one they never share. To send someone a secret, you only need their published key. A group of n people needs n key pairs, not n × (n − 1) / 2 shared secrets. That is chapter 3.
2. Key agreement. Two people can agree a fresh shared secret across an open network, without ever sending the secret itself. Someone who copies every message still cannot work it out. That is chapter 4.

The last row’s weakness is the reason certificates exist. A published key is safe to copy, but you still need to know that it really belongs to the person you think. The chapter on binding identity shows what goes wrong otherwise, and the certificate chapters show how PKI fixes it.

Where does the key-distribution problem hide?

You rarely see the words “key distribution” in a ticket, but the problem is everywhere:

• a password-protected ZIP file, with the password in the same email;
• a database password pasted into a chat so a colleague can debug;
• one API key shared by every service and every developer;
• a Wi-Fi password printed on the wall of a meeting room;
• a VPN pre-shared key that has not changed since the person who set it up left.

Each case has the same shape: a secret that many people or systems hold, delivered over a channel that others can read, and never replaced.

Count the keys before you build a mesh

Platform teams meet the n × (n − 1) / 2 rule when every service must talk privately to every other service. With 50 services and one shared secret per pair:

echo $(( 50 * 49 / 2 ))

1225

That is 1,225 secrets to create, deliver, store and rotate, and the number grows with the square of the service count. This is why service meshes give each workload its own key pair and certificate instead (see mutual TLS). Each service then needs one identity, not one secret per partner.

When you must use a shared secret

Sometimes a pre-shared key is the right tool: a webhook secret, a Wi-Fi network, a small VPN. Then:

1. Generate it, do not invent it. Use a secure random source:

   openssl rand -base64 32

   dc8mgsyYY3bXLqcAgDWSTs2FqrjedWoItO4nHqD/78o=

2. Deliver it out of band, or not at all. Put it in a secrets manager or key vault that both sides read with their own credentials, so the secret itself never travels through email or chat.

3. One secret per pair or per purpose. Do not reuse the webhook secret as the database password.

4. Write down who holds it. Keep an inventory: which secret, which systems and people, when it was created, when it was last rotated.

5. Rotate on every leaver and every suspicion. When someone who knew the secret leaves, change it that day.

Prefer designs where no secret travels

Where you can, choose protocols that avoid shared secrets altogether:

• HTTPS and TLS agree a fresh session key for every connection (key exchange).
• SSH keys put only a public key on the server; the private key never leaves your machine (key pairs).
• Client certificates give each machine or user its own identity (mutual TLS).

In a Windows domain, Kerberos already does this work for you behind the scenes: the domain controllers act as the key distribution centre. On a domain-joined Windows machine, klist lists the tickets the KDC has issued to your logon session.

Common mistakes

• “Send the password in a separate email.” A second message on the same network is still the same open channel. A separate channel means one the attacker cannot read, such as a phone call to a known number or a secrets manager.
• “Just encrypt the key with another key.” That only helps if the receiver already holds a key that was delivered safely. Otherwise you have moved the problem back one step.
• “One shared key for the team is simpler.” It is simpler to hand out and much harder to live with: everyone can read everything, one leak exposes all of it, and every leaver means a new key for everyone.
• “We handed it over in person, so we know who has it.” In-person delivery protects the key from eavesdroppers. It says nothing about what the receiver does with it next, and it does not prove identity on its own.
• “Public-key cryptography removes the need for trust.” It removes the need to deliver secrets. You still need to know whose public key you are using. That is what binding identity and certificates are for.

Check yourself

Check yourself

A team of six people wants every pair to have its own private secret key. How many keys do they need?

1. 6
2. 15
3. 36

Show answer

Answer B 15

What happened

Six people form 15 different pairs: 6 × 5 / 2 = 15.

Why

Each key is shared by exactly two people, so you count pairs, not people. Counting 6 × 6 counts each pair twice and includes people paired with themselves.

The rule

With pairwise secret keys, n people need n × (n − 1) / 2 keys. The number grows much faster than the group.

Check yourself

A colleague sends you a password-protected ZIP file and, a minute later, the password in a second email. What is the real problem?

1. ZIP encryption is too weak
2. Anyone who can read the mailbox or the mail traffic gets both the file and the password
3. Nothing: the password and the file are in separate messages

Show answer

Answer B Anyone who can read the mailbox or the mail traffic gets both the file and the password

What happened

The key travelled over the same channel as the data it protects.

Why

A separate message is not a separate channel. Whoever can read one email on that route can read the other.

The rule

Never send a key the way you send the data. Use a channel the attacker cannot read, or a protocol that agrees keys without sending them.

Check yourself

A company replaces its pairwise keys with a key distribution centre, such as Kerberos. What is the trade-off?

1. It still needs n × (n − 1) / 2 keys, just stored in one place
2. Each person needs only one key, but the centre must be online and is trusted with every session key
3. It removes the need for any secret keys at all

Show answer

Answer B Each person needs only one key, but the centre must be online and is trusted with every session key

What happened

Each person shares one long-term key with the centre, and the centre hands out session keys.

Why

The centre creates every session key and holds every long-term key, so it must be available and it is the most valuable target in the network.

The rule

A key distribution centre turns n × (n − 1) / 2 keys into n, at the price of trusting one central service with everything.

Go deeper

• RFC 4120: The Kerberos Network Authentication Service (V5): the best-known key distribution centre protocol; section 1.1 explains the model in one page.
• Microsoft Learn: Kerberos authentication overview: how Windows domains use a KDC on every domain controller.
• NIST SP 800-57 Part 1 Rev. 5: key management, including how keys are established, distributed, stored and replaced.
• RFC 9846, section 2.2: pre-shared keys in TLS 1.3, and their limits.
• NIST SP 800-56A Rev. 3: the standard for Diffie-Hellman key agreement, the way out described in chapter 4.

Play itLevel 2: The key-sharing problemCourier Stables, Keystone. Play now

Short on time? The crash course covers this chapter and the previous one in Lesson 1: Secrets and the sharing problem.