Educatifu
Open menu

Keys, and how strangers share a secret

Encryption needs a shared key — but how do two strangers agree on one over a channel everyone can see? Public-key ideas make the impossible routine.

FoundationsCyber Security~13 min

Before this lesson

  • Lesson: Hashing — a fingerprint for data

Encryption scrambles a message so only someone with the right key can read it — the tool for confidentiality. But encryption raises a chicken-and-egg problem that stumped cryptographers for centuries: to talk securely you need a shared key, but how do you share the key securely without already having a secure channel?

Symmetric encryption: one shared key

The oldest approach is symmetric encryption (modern standard: AES). One secret key both encrypts and decrypts. It is fast and strong — but everyone who needs to communicate must somehow already hold the same key. For two people who have never met, across the open internet, that is exactly the problem we started with.

Asymmetric encryption: two keys

The breakthrough is asymmetric (public-key) cryptography. Each person has a key pair: a public key they hand out freely, and a private key they never reveal. Anything locked with your public key can only be unlocked with your private key. Now anyone can send you a confidential message using your public key, and only you can read it — no shared secret needed in advance. (The same maths, run the other way, produces digital signatures that prove who sent something.)

Diffie–Hellman: agreeing on a secret in the open

A beautiful special case is deriving a shared symmetric key over a public channel, using Diffie–Hellman key exchange. Both sides agree on public numbers, each picks a private number, each sends a value computed from theirs — and from the exchange both compute the same secret, which was never transmitted. An eavesdropper sees everything sent and still cannot get the secret.

Try it below. Alice and Bob each choose a private key; the widget shows the public values they exchange and the shared secret they both land on. Change either private key and watch both sides still agree — while the eavesdropper's view (p, g, A, B) never reveals it.

Why it's safe: hard problems

The security rests not on hiding the method but on a computationally hard problem. For Diffie–Hellman it is the discrete logarithm: given g, p and g^x mod p, recover x. With the toy p = 23 in the widget that's trivial, but with the 2048-bit-plus primes used in practice it would take longer than the age of the universe. Modern cryptography is this pattern everywhere — easy to compute one way, infeasible to reverse.

Put the pieces together and you have the backbone of secure communication: asymmetric crypto to exchange or establish a key, fast symmetric crypto to encrypt the actual data, and hashing to guarantee integrity. Every time you see the padlock in your browser, this is what just happened. From here the Core level moves up the stack to how real systems are attacked and defended.

Try it: sharing a secret in the open

Public, known to everyone: p = 23, g = 5

Alice

sends A = g6 mod p = 8
computes B6 mod p = 2

Bob

sends B = g15 mod p = 19
computes A15 mod p = 2

Public channel (an eavesdropper sees all of this)

p = 23, g = 5, A = 8, B = 19

Shared secret: 2 — both derived the same key, but it was never sent.

Alice and Bob agree on a shared secret (2) without ever transmitting it. An eavesdropper knows p, g, A and B — yet to recover the secret they must find a private exponent from gx mod p, the discrete logarithm problem, which is easy here (p = 23) but astronomically hard for the huge primes used in practice. That gap is what keeps HTTPS safe.

Key takeaways

  • Symmetric encryption uses one shared key for both locking and unlocking — fast, but the key must be shared safely.
  • Asymmetric (public-key) crypto uses a public key to lock and a private key to unlock, solving key distribution.
  • Diffie–Hellman lets two parties derive a shared secret over a public channel; its safety rests on a hard maths problem.

← All Cyber Security lessons

Bring us the problem, not a perfect specification

Tell us what needs to change, who it affects and any important deadline. We will review the context and reply with useful next questions.

  1. 01Share contextDescribe the workflow, constraint or risk.
  2. 02Clarify togetherWe identify missing facts and useful options.
  3. 03Choose a startAgree a focused assessment or delivery step.
Start a conversation