> Why sharing secret keys is the hard part of encryption: open networks, out-of-band delivery, n(n−1)/2 keys, key distribution centres and the way out. Source: https://pkizerotohero.com/handbook/key-distribution/ · Last reviewed: 2026-10-20 Part I: Secrets · Chapter 2 # The key-distribution problem **In one sentence:** A shared secret key must reach each partner without anyone else seeing it, and every pair needs its own key, so sharing secret keys does not scale. ## Who is this for - [Beginner](https://pkizerotohero.com/start/#beginner) - [Leader](https://pkizerotohero.com/start/#leader) - [IT ops](https://pkizerotohero.com/start/#itops) - [Developer](https://pkizerotohero.com/start/#developer) - [Expert](https://pkizerotohero.com/start/#expert) Level: **Beginner** - [New to this? Start with The idea](https://pkizerotohero.com/handbook/key-distribution/#the-idea) - [Developer? Jump to How it really works](https://pkizerotohero.com/handbook/key-distribution/#how-it-really-works) - [IT ops? At work](https://pkizerotohero.com/handbook/key-distribution/#at-work) - [Leader? Why it matters](https://pkizerotohero.com/handbook/key-distribution/#why-it-matters-to-the-business) ## The idea - Beginner The chapter on [symmetric encryption](https://pkizerotohero.com/handbook/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](https://pkizerotohero.com/handbook/glossary/#key-distribution), 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](https://pkizerotohero.com/handbook/glossary/#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. *Diagram: Three ways to send a secret key. By network: Eve copies it, marked with a cross. In a separate message on the same network: Eve copies that too, marked with a cross. In person: safe from eavesdroppers, marked with a tick, but slow.* Every route over the open network exposes the key. Meeting in person works, but cannot keep up. In the game In the game: the courier stables In Level 2, Rosa must get the harbour key to three ports. Every road the Royal Post takes passes Eve, who copies whatever key she sees. Meeting each harbourmaster in person works, but the ropes between people on the Meeting Stones multiply until the plan collapses. **Where the picture stops being true:** a metal key cut in secret might show scratches, and you would notice it was gone for a while. A real key is a long number. Copying it takes no time, leaves no mark, and the original never leaves your hands. Also, meeting in person only protects the key from eavesdroppers. It does not prove the other person is who they say they are. That problem comes back in [chapter 7](https://pkizerotohero.com/handbook/binding-identity/). ## How it really works - Developer - Expert ### 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. | People | Keys for every pair | | --- | --- | | 2 | 1 | | 3 | 3 | | 10 | 45 | | 100 | 4,950 | | 1,000 | 499,500 | | 10,000 | 49,995,000 | 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. *Diagram: Five people drawn as circles, each joined to every other by a line. There are ten lines, one secret key per pair. Beside it: 3 people need 3 keys, 10 people need 45, 1,000 people need 499,500.* Five people need ten keys. The number of keys grows roughly with the square of the number of people. ### 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](https://pkizerotohero.com/handbook/hsm-and-key-ceremonies/)). 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](https://pkizerotohero.com/handbook/glossary/#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](https://www.rfc-editor.org/rfc/rfc9846#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](https://pkizerotohero.com/handbook/glossary/#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](https://pkizerotohero.com/handbook/glossary/#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](https://www.rfc-editor.org/rfc/rfc4120)), 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](https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview)). 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](https://pkizerotohero.com/handbook/key-pairs/). 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](https://pkizerotohero.com/handbook/key-exchange/). | Approach | Keys for *n* people | Main weakness | | --- | --- | --- | | A secret key for every pair | *n* × (*n* − 1) / 2 | Delivery, storage and rotation do not scale | | One key for the whole group | 1 | Everyone reads everything; one leak exposes all | | Key distribution centre | *n* | The centre must be online and is trusted with every key | | Key pairs and key agreement | *n* key pairs | You must know whose published key is whose | 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](https://pkizerotohero.com/handbook/binding-identity/) shows what goes wrong otherwise, and the certificate chapters show how PKI fixes it. ## At work - Developer - IT ops ### 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: ```bash echo $(( 50 * 49 / 2 )) ``` ```text 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](https://pkizerotohero.com/handbook/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: ```bash openssl rand -base64 32 ``` ```text 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](https://pkizerotohero.com/handbook/key-exchange/)). - **SSH keys** put only a public key on the server; the private key never leaves your machine ([key pairs](https://pkizerotohero.com/handbook/key-pairs/)). - **Client certificates** give each machine or user its own identity ([mutual TLS](https://pkizerotohero.com/handbook/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](https://pkizerotohero.com/handbook/binding-identity/) and certificates are for. ## Why it matters to the business - Leader Why it matters to the business Shared secrets are a hidden liability Every shared secret, from Wi-Fi passwords to API keys, must reach the right people, stay with them and change when they leave. With one key for everyone, a single leak exposes everything it ever protected, and each departure means a reset for all. Private links between every pair of 1,000 staff would need 499,500 keys. Ask your teams where passwords still travel in the same email as the file, which secrets a whole team shares, and who changes them on someone’s last day. Prefer systems that give each person or machine its own identity. ## 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)](https://www.rfc-editor.org/rfc/rfc4120): the best-known key distribution centre protocol; section 1.1 explains the model in one page. - [Microsoft Learn: Kerberos authentication overview](https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview): how Windows domains use a KDC on every domain controller. - [NIST SP 800-57 Part 1 Rev. 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final): key management, including how keys are established, distributed, stored and replaced. - [RFC 9846, section 2.2](https://www.rfc-editor.org/rfc/rfc9846#section-2.2): pre-shared keys in TLS 1.3, and their limits. - [NIST SP 800-56A Rev. 3](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final): the standard for Diffie-Hellman key agreement, the way out described in [chapter 4](https://pkizerotohero.com/handbook/key-exchange/). Short on time? The crash course covers this chapter and the previous one in [Lesson 1: Secrets and the sharing problem](https://pkizerotohero.com/course/secrets-and-sharing/). **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/handbook/key-distribution/). Last reviewed 20 October 2026Edition 0.9 ## Keep going Crash course: [Lesson 1: Secrets and the sharing problem](https://pkizerotohero.com/course/secrets-and-sharing/) ### Topics - [TLS and HTTPS](https://pkizerotohero.com/topics/tls/)