One key pair, two capabilities. The public key encrypts messages only the private key can read. The private key signs messages anyone with the public key can verify. Together, encryption and signatures form the backbone of secure communication on the internet.
Diffie-Hellman gives two parties a shared secret, but requires both to be online and leaves them with equal knowledge. What if you need to encrypt for someone who is not there?
Diffie-Hellman requires both parties to be online at the same time, exchanging messages back and forth. That works for a live TLS connection. It does not work for email, where the recipient might not check their inbox for hours. It does not work for encrypting a file to upload to a server. It does not work for any scenario where the sender and receiver are not simultaneously present.
Key exchange also creates a shared secret that both parties hold equally. There is no concept of “encrypt for Bob specifically.” Both Alice and Bob end up with the same key. If Alice wants to send a message to Bob and a different message to Charlie, she needs separate key exchanges with each, and each one requires both sides to participate in real time.
Imagine a mailbox with a slot. Anyone walking by can drop a letter in. But only the mailbox owner has the key to open it and read what is inside. The slot is public. The key is private. The two are completely separate.
If Bob publishes the equivalent of a mailbox address, Alice can encrypt a message that only Bob can decrypt. She does not need to meet Bob first. She does not need Bob to be online. She just needs his public key. This is asymmetric encryption: the encryption key (public) is different from the decryption key (private). It inverts the fundamental assumption of everything before it.
Public-key cryptography needs a special kind of math: easy to compute in one direction, impossible to reverse without a secret shortcut. Try it yourself.
Bob publishes open padlocks (his public key). Anyone can snap one shut on a box. Only Bob's key can reopen it.
Only Bob holds the private key. The ability to lock is completely separated from the ability to unlock.
The math that makes this possible: easy one way, hard to reverse. The secret (the trapdoor) is what makes decryption fast.
Multiplying two primes is trivial. Factoring the product back? Try it yourself.
That asymmetry you just felt is the foundation of all public-key cryptography. For RSA, the trapdoor is integer factorization. For elliptic curve schemes, it is the Elliptic Curve Discrete Logarithm Problem: given a point on the curve, it is practically impossible to figure out how many times it was "added" to itself. Different math, same principle: easy forward, hard backward, fast with the secret.
Invented in 1977 by Rivest, Shamir, and Adleman. Walk through the math step by step: pick two primes, build a key pair, encrypt a message, and see why nobody can reverse it.
Pick two primes, build a key pair, encrypt a message, and see why nobody can reverse it.
is public. Everyone sees it. But the two primes that made it stay secret.
You have seen why RSA alone is not enough. The solution: combine asymmetric and symmetric encryption. Every real system follows this pattern.
Speed. The bulk data is encrypted with AES, which is hardware-accelerated on most processors and orders of magnitude faster than RSA.
Size. No limit on message size. The RSA portion is always exactly one key (32 bytes), well within the OAEP limit.
Security. The symmetric key is random and single-use. Even if the same message is sent twice, the ciphertext is different because the AES key and nonce change.
RSA encrypts a random AES key. AES encrypts the actual message. The result: asymmetric encryption that works for messages of any size.
RSA-based hybrid encryption works but requires large keys. ECIES replaces RSA with ECDH and a throwaway key. Walk through the full encryption and decryption flow.
ECIES is just ECDH + AES-GCM with a throwaway key. Each message gets its own key agreement, so compromising the long-term key does not reveal past messages.
Encryption lets anyone write to the mailbox. But it says nothing about who wrote the letter. Sign a message, verify it, then watch what happens when someone tampers with it.
Sign a message with a private key, verify it with the public key, then see what happens when someone tampers with the message.
Start with the problem: how do you prove you know a secret without revealing it? Try the naive solution, see why it fails, then derive the fix step by step. The algorithm you arrive at is Schnorr, the foundation of Ed25519 and ECDSA.
Before looking at any algorithm, start with the problem. Then try to solve it yourself. The solution you arrive at is Schnorr, the foundation behind Ed25519 and ECDSA.
You have a secret number (your private key). Everyone knows (your public key). Computing from is infeasible (the discrete log problem).
How do you prove you know without revealing it, and bind the proof to a specific message?
RSA-PSS: RSA with randomized padding. Still widely used for compatibility. Larger signatures (256 bytes for RSA-2048).
ECDSA (P-256): Powers most TLS certificates and blockchain transactions. 64-byte signatures, but requires careful nonce generation.
Ed25519: Deterministic, faster, simpler. 32-byte keys, 64-byte signatures. Fewer implementation choices, fewer ways to get it wrong. The default for new systems.
The math is sound. But the gap between textbook algorithms and secure implementations is enormous. Try tampering with a signed message and see what breaks.
A signed message arrives. Try these attacks and see what happens.
Use OAEP for RSA encryption, PSS for RSA signatures, and Ed25519 where possible. Textbook RSA is deterministic and malleable. ECDSA breaks catastrophically on nonce reuse. The question is not “is the math secure?” but “how hard is it to use correctly?”
Every HTTPS connection, every signed software update, every cryptocurrency transaction relies on the encryption and signature primitives from this chapter.
Every HTTPS certificate contains a public key. The server presents its certificate, and the browser verifies the certificate authority's signature to trust the server's identity. TLS 1.3 uses ephemeral ECDH for key exchange and digital signatures for authentication. The actual data flows through AES-GCM. Classic hybrid encryption plus signatures, working together.
PGP generates a key pair for each user. To send an encrypted email: generate a random session key, encrypt the email body with AES, encrypt the session key with the recipient's public key. The sender can also sign the email with their private key, giving the recipient both confidentiality and proof of authorship. How we verify that a public key actually belongs to the claimed person is the subject of the next chapter.
Operating systems verify cryptographic signatures on software updates and applications. Apple, Microsoft, and Linux distributions all sign their packages. An unsigned or incorrectly signed binary is rejected before it can run.
Git supports GPG and SSH signatures on commits and tags. GitHub shows a “Verified” badge on signed commits. This proves the commit was created by the key holder, not just by someone who set the right name in their git config.
Every Bitcoin or Ethereum transaction is signed with the sender's private key. The network verifies the signature before accepting the transaction. No valid signature, no transfer. Your “wallet address” is derived from your public key. Owning cryptocurrency means holding the private key that can produce valid signatures for that address.
Encryption and signatures work together everywhere. But one question remains: how do you know the public key you are encrypting to, or verifying against, actually belongs to Alice and not to Eve? Binding identities to public keys through certificates and chains of trust is the subject of Chapter 08.