Understand public and private keys through three interactive analogies - padlock, colour mixing and mailbox - plus where asymmetric crypto is used daily.
Public key cryptography is the idea that makes the modern internet possible, and it is genuinely counter-intuitive the first time you meet it: two strangers who have never communicated before can establish a secret that an eavesdropper watching every byte between them cannot work out. This tool explains how, using three interactive analogies that you can click through, plus a tour of where the technique is actually used.
It is aimed at people who need the concept rather than the arithmetic — students, help-desk and IT staff, developers who use TLS and SSH daily without ever having been taught what is underneath, and anyone explaining security to a non-technical audience. No maths is required to follow it. If you want the arithmetic afterwards, the tool links onward to a working RSA implementation.
Traditional (symmetric) encryption uses one key for both locking and unlocking. That works well, but it has a bootstrapping problem: both parties need the same key, and getting it to the other person securely is the very problem you were trying to solve.
Asymmetric cryptography breaks the symmetry. You generate a key pair: a public key you publish to the world, and a private key you never share with anyone. What one key does, only the other can undo. Anyone can encrypt a message to you using your public key, and only your private key can decrypt it — including the person who encrypted it, who cannot read their own message back. Conversely, only you can produce a signature with your private key, and anyone can verify it with your public key.
The pair is mathematically linked, but the link runs one way. Deriving the private key from the public key requires solving a problem — factoring a very large number, or computing a discrete logarithm on an elliptic curve — that is easy to state and, at the sizes used in practice, computationally infeasible. That one-way asymmetry is the entire foundation.
Imagine handing out thousands of open padlocks, all of which only your one key can open. Anyone can put a message in a box, snap one of your padlocks shut on it, and send it. Once it clicks closed, not even the sender can reopen it. The open padlocks are your public key; the key in your pocket is your private key. This analogy captures the essential asymmetry: locking and unlocking are different capabilities, and only one of them is a secret.
The colour-mixing analogy explains something the padlock cannot: how two parties agree on a shared secret in public. Both start from a common public colour. Each privately picks a secret colour and mixes it with the public one. They exchange the resulting mixtures openly — an eavesdropper sees both mixtures. Each then adds their own private colour to the mixture they received. Both arrive at the same final colour, containing both private colours plus the public base. The eavesdropper, holding only the public colour and the two mixtures, cannot reach it, because separating a mixed colour back into its components is hard while mixing is easy.
That is Diffie–Hellman key exchange, and paint is a fair model of it: mixing is the easy direction, un-mixing is the hard one. In the real protocol the “colours” are numbers and the hard direction is the discrete logarithm problem.
A public mailbox with a slot anyone can post through, but a locked door only your key opens. It is a good model for the mechanics: your address is public, delivery is open to anyone, retrieval is exclusively yours. It also exposes the honest limitation of all these analogies — a mailbox tells you nothing about who posted a letter. That gap is why digital signatures exist as a separate operation.
These are two different uses of the same key pair, and confusing them is the most common misunderstanding in this area.
| Encrypting to someone | Signing something | |
|---|---|---|
| Key used to create | Recipient’s public key | Your private key |
| Key used to undo/verify | Recipient’s private key | Your public key |
| Who can perform it | Anyone | Only you |
| What it gives you | Confidentiality | Authenticity and integrity |
Encryption answers “only the intended recipient can read this”. Signing answers “this came from me and has not been altered”. A signed message is not secret, and an encrypted message does not prove who sent it. Protocols that need both do both.
authorized_keys on the server.Every analogy above assumes you have the right public key. Nothing in the mathematics guarantees that. If an attacker can substitute their public key for the one you think belongs to your bank, they can decrypt everything you send and you will notice nothing.
Solving that is a separate problem, addressed by different systems in different contexts: certificate authorities and the browser trust store for the web, the web of trust for PGP, and trust-on-first-use with fingerprint checking for SSH. When you compare an SSH host-key fingerprint, or a security tool warns that a certificate is issued by an unknown authority, you are watching that layer do its job. The cryptography is rarely what fails — the trust decisions around it are.
Once the concept lands, go and use it: generate an SSH key pair, create PGP keys for encrypted email, or step through the actual arithmetic in the RSA playground. For the symmetric side of the story, the block cipher mode visualizer shows why how you encrypt matters as much as what you encrypt with, and the hash generator demonstrates the one-way functions signatures rely on.
The public key is meant to be shared freely; anyone can use it to encrypt a message to you or to verify a signature you made. The private key is never shared and is the only thing that can decrypt those messages or produce those signatures.
Not in practice at the key sizes in use. Doing so requires solving a problem — factoring a large number, or an elliptic curve discrete logarithm — that is computationally infeasible with current technology. The realistic threats are your private key being stolen from disk, backed up carelessly, or protected by a weak passphrase.
Speed. Asymmetric operations are orders of magnitude slower than symmetric ones. Real protocols use asymmetric cryptography to authenticate and to agree a symmetric session key, then encrypt the actual data symmetrically.
A method for two parties to agree on a shared secret over a channel an eavesdropper can read in full. The colour-mixing analogy models it: mixing is easy, un-mixing is hard, so both sides reach the same final mixture while the observer cannot.
No. Signing uses your private key and proves authorship and integrity; anyone can verify it and the content stays readable. Encrypting uses the recipient’s public key and hides the content from everyone else. They are independent and often used together.
That is the trust problem, and it is handled outside the mathematics — certificate authorities for the web, fingerprint verification for SSH, the web of trust for PGP. Verifying key ownership is where real-world attacks concentrate.
Anything encrypted to it becomes unreadable and you can no longer sign as that identity. There is no recovery mechanism by design. Generate a new pair, distribute the new public key, and revoke the old one where a revocation mechanism exists.
No. Understanding which key is public, which is private, and which operation each performs is enough to use TLS, SSH and PGP correctly. Use vetted libraries rather than implementing anything yourself.
Public key cryptography (also called asymmetric cryptography) is a cryptographic system that uses mathematically linked key pairs: a public key that can be freely shared and a private key that must be kept secret. Unlike symmetric encryption where both parties share a single secret key, public key cryptography solves the key distribution problem — two parties can communicate securely without ever having exchanged a secret in advance.
Public key cryptography is the foundation of digital signatures, TLS/HTTPS, SSH, PGP email encryption, cryptocurrency, and certificate-based authentication. Invented independently by Diffie-Hellman (1976) and Rivest-Shamir-Adleman (RSA, 1977), it remains one of the most important innovations in the history of computer science.
A key pair is generated using a mathematical trapdoor function — an operation that is easy to compute in one direction but computationally infeasible to reverse:
| Operation | Uses | How It Works |
|---|---|---|
| Encryption | Public key | Anyone can encrypt a message using the recipient's public key. Only the matching private key can decrypt it. |
| Decryption | Private key | Only the private key holder can decrypt messages encrypted with their public key. |
| Signing | Private key | The sender signs a message using their private key, creating a digital signature. |
| Verification | Public key | Anyone can verify the signature using the signer's public key, confirming authenticity and integrity. |
| Algorithm | Based On | Key Sizes | Status |
|---|---|---|---|
| RSA | Integer factorization | 2048-4096 bit | Widely used; 2048-bit minimum recommended |
| ECDSA | Elliptic curve discrete logarithm | 256-384 bit | Preferred for performance; same security with smaller keys |
| Ed25519 | Twisted Edwards curve | 256-bit | Modern; fast, constant-time, resistant to side channels |
| X25519 | Montgomery curve | 256-bit | Key exchange (Diffie-Hellman); used in TLS 1.3 and WireGuard |
| Kyber | Lattice-based | Various | Post-quantum candidate; NIST standardized as ML-KEM |