Two keys

The situation

Your browser has never met your bank’s website. They share no secret key. Yet within a fraction of a second they are talking privately, over Wi-Fi and networks that anyone could be listening to.

Lesson 1 said that should be impossible without meeting first. So how does it work?

What is going on

One key to share, one key to keep

The answer is a key pair: two keys made together and linked by mathematics.

• The public key can be given to anyone. Publishing it is safe.
• The private key stays with its owner and never leaves.

Working out the private key from the public key is not feasible with today’s computers. The two keys are not interchangeable: each has its own job.

With public-key encryption, anyone can encrypt a message to your public key, and only your private key can decrypt it. To send someone a secret, you use their public key, not yours.

Agreeing a secret in public

Public-key operations are much slower than symmetric ones, so nobody encrypts a whole web page this way. Instead, the two sides use key exchange to agree on a shared secret, then switch to fast symmetric encryption such as AES. Using both together is called hybrid encryption.

The key exchange used by HTTPS today is ECDHE (elliptic-curve Diffie-Hellman, ephemeral):

1. Each side creates a fresh key pair just for this connection.
2. Each side sends its public key across the open network.
3. Each side combines its own private key with the other side’s public key. Both arrive at the same shared secret.
4. Someone who saw both public keys still cannot compute that secret.

Swipe sideways to see the whole diagram.

“Ephemeral” matters. The key-exchange keys are thrown away after the connection. If someone records your traffic today and steals the server’s long-term key next year, they still cannot decrypt the recording. This property is called forward secrecy. In TLS 1.3, the version of HTTPS’s security protocol in wide use today, every full handshake uses an ephemeral exchange like this.

What is still missing

Key exchange agrees a secret with whoever answered. It does not tell you who that is. Someone sitting between you and the bank could run one exchange with you and another with the bank, and read everything in between. Lessons 3 and 4 add the missing proof of identity.

Try it

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

Find the public key in this sample certificate: its type, its size and its long string of bytes. Then notice what is not there: no private key. A certificate never contains one.

Check

Check yourself

You want to send a supplier a confidential file using public-key encryption. Which key do you encrypt it with?

1. Your own private key
2. Your own public key
3. The supplier's public key

Show answer

Answer C The supplier's public key

What happened

You encrypt with the supplier's public key, so only the supplier's private key can decrypt it.

Why

Encrypting with your own public key locks the file so that only you can open it. Private keys are never used to encrypt for someone else.

The rule

To send a secret, encrypt to the recipient's public key. Private keys stay with their owner.

Check yourself

Someone records all encrypted traffic between a browser and a server today, using TLS 1.3. Next year they steal the server's long-term private key. Can they decrypt the recording?

1. Yes, the long-term key encrypted the traffic
2. No, the session keys came from an ephemeral ECDHE exchange that both sides threw away
3. Only if the certificate has expired by then

Show answer

Answer B No, the session keys came from an ephemeral ECDHE exchange that both sides threw away

What happened

No. The keys that encrypted the traffic were derived from ephemeral key-exchange values that no longer exist.

Why

In TLS 1.3 the server's long-term key only signs, to prove who the server is. It never encrypts the session key. That is forward secrecy.

The rule

TLS 1.3 key exchange is ephemeral (ECDHE); the certificate's key authenticates, it does not encrypt.

Check yourself

Why does HTTPS encrypt the actual data with a symmetric cipher such as AES instead of with public keys?

1. Public-key operations are much slower, so they only set up the secret and AES does the bulk work
2. Symmetric encryption is always more secure than public-key encryption
3. Public keys can only encrypt text

Show answer

Answer A Public-key operations are much slower, so they only set up the secret and AES does the bulk work

What happened

Public-key cryptography agrees the shared secret; a symmetric cipher encrypts the data with keys derived from it.

Why

Public-key operations cost far more computing time per byte. Combining the two, called hybrid encryption, gets the best of both.

The rule

Public-key cryptography agrees keys and proves identity; symmetric cryptography moves the data.

Takeaways

• A key pair has a public key you share freely and a private key that never leaves its owner.
• ECDHE lets two strangers agree a fresh secret over an open network, and throwing the keys away afterwards gives forward secrecy.
• Key exchange alone does not tell you who answered. Signatures and certificates add that.

Go further

• Handbook: Key pairs: public and private keys
• Handbook: Key exchange and hybrid encryption
• Next lesson: Fingerprints and signatures

In the gameLevel 3: Two keys: the open padlockThe Locksmith, Keystone. In development