> Lesson 2 of PKI in 90 minutes: public and private keys, key exchange with ECDHE, forward secrecy, and why HTTPS still encrypts data with AES. Source: https://pkizerotohero.com/course/two-keys/ · Last reviewed: 2026-10-20 # Two keys About 9 minutesCrash course **In one sentence:** A key pair lets strangers agree a fresh secret over an open network, and fast symmetric encryption then protects the data: that is how every HTTPS connection starts. ## 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](https://pkizerotohero.com/handbook/glossary/#key-pair): two keys made together and linked by mathematics. - The [public key](https://pkizerotohero.com/handbook/glossary/#public-key) can be given to anyone. Publishing it is safe. - The [private key](https://pkizerotohero.com/handbook/glossary/#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. Common mistake Encrypting with the wrong key A classic mistake, seen again and again in usability studies of encrypted email, is encrypting with your own public key. The recipient then cannot open the message, and only you can. The public key never decrypts anything, and it does not need to be hidden. In the game The open padlock In the game, a public key is an open padlock. You hand out as many as you like and keep the only key that opens them. Anyone can snap one shut on a box for you; only you can open it. Where it stops being true: a real public key is copied, not handed out one by one, and the key exchange below is not a padlock at all. Both sides contribute to the secret. ### 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](https://pkizerotohero.com/handbook/glossary/#key-exchange) to agree on a shared secret, then switch to fast symmetric encryption such as AES. Using both together is called [hybrid encryption](https://pkizerotohero.com/handbook/glossary/#hybrid-encryption). The key exchange used by HTTPS today is [ECDHE](https://pkizerotohero.com/handbook/glossary/#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. *Diagram: A browser and a server each keep a private key. Each sends its public key across the open network. An eavesdropper in the middle sees both public keys but cannot compute the secret. Both sides compute the same shared secret locally, and fast symmetric encryption then protects the data.* ECDHE: only public keys cross the network, yet both sides end up with the same secret. “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](https://pkizerotohero.com/handbook/glossary/#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. Why it matters to the business Ask your team Are any of our systems still using old protocol versions (TLS 1.0 or 1.1), or TLS 1.2 with RSA key exchange, which has no forward secrecy? Who checks this, and how often? ## Try it *Interactive tool: Certificate decoder (runs in the browser at [/tools/decoder/](https://pkizerotohero.com/tools/decoder/))* 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](https://pkizerotohero.com/handbook/key-pairs/) - Handbook: [Key exchange and hybrid encryption](https://pkizerotohero.com/handbook/key-exchange/) - Next lesson: [Fingerprints and signatures](https://pkizerotohero.com/course/fingerprints-and-signatures/) **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=/course/two-keys/). Last reviewed 20 October 2026Edition 0.9 ## Go deeper in the handbook - [Chapter 3: Key pairs: public and private keys](https://pkizerotohero.com/handbook/key-pairs/) - [Chapter 4: Key exchange and hybrid encryption](https://pkizerotohero.com/handbook/key-exchange/)