Two keys, and what each one is for
Watch a real signature being made and checked, step by step, with real keys generated in your browser. The point is the distinction people find hardest: signing and encrypting are opposite operations, and which key does which is the whole idea.
Alice
Has both keys. Signs with the private one.
travels in the open
Bob
Has only Alice's public key. Checks with it.
Signing — the private key locks, the public key checks
Anyone can verify. Only one person can sign.
Alice signs with her private key. Everyone holds her public key and can check the signature. The message is not hidden — signing proves origin and integrity, and does nothing about secrecy.
Encrypting — the public key locks, the private key opens
Anyone can send. Only one person can read.
Anyone encrypts to Bob using his public key. Only Bob, holding the matching private key, can decrypt. The sender is not proven — anyone can use a public key, so encryption alone says nothing about who sent it.
Which is why real systems do both
Sign, then encrypt. The signature establishes who wrote it; the encryption keeps everyone else out. Doing only one leaves a gap that is easy to miss — an encrypted message from nobody in particular, or a signed message anyone can read.
This site's tools are split the same way: signatures for the first, encryption for the second. The encryption tools here use a password rather than a public key, which is a third arrangement — simpler, and it needs the two sides to already share a secret.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
These are real keys and a real signature
Nothing on this page is simulated. Pressing Run calls crypto.subtle.generateKey to make an actual ECDSA P-256 key pair, signs the actual bytes of your message with the private key, and verifies with the public one. The values shown are the real ones, truncated to fit.
That matters because toy demonstrations of public-key cryptography usually use small numbers and a made-up scheme, which teaches the shape of the idea and quietly misleads about everything else. What you are watching here is the operation a browser performs when it checks a certificate.
What the private key is, in one sentence
A number you keep, from which a matching public number can be derived — but from which the reverse cannot be computed in any practical amount of time. Everything else follows from that asymmetry.
For ECDSA the private key is essentially a large random integer, and the public key is a point on a curve reached by adding a fixed starting point to itself that many times. Adding is fast; working out how many additions happened is not, and nobody has found a way to make it fast. That gap is the security, and it is a gap that has resisted attack rather than one that has been proven to exist — which is why post-quantum work exists at all.
The problem this does not solve
Knowing that a public key belongs to who you think. Every step here works perfectly if Bob has the wrong public key — he would verify signatures from an impostor and be entirely satisfied.
That is the hard problem, and it is not a mathematical one. It is solved by certificate authorities vouching for keys, by comparing fingerprints in person or over the phone, by keys published somewhere already trusted, or by having met before. Every real system has an answer to it, and the answer is never arithmetic.
The two mistakes worth not making
"I encrypted it, so they know it is from me." No — anyone can encrypt to a public key, because that is what makes it public. Encryption alone identifies nobody.
"I signed it, so it is private." No — a signature is a value attached to a message that remains perfectly readable. Signing hides nothing.
Both mistakes come from thinking of the key pair as one thing that "does cryptography". It is two operations that happen to share a pair of numbers, and they point in opposite directions.
Related
Generate a real key pair, sign something, or inspect a key somebody sent you.
Questions people actually ask
Are these real keys or a simulation?
Real. Pressing Run calls crypto.subtle.generateKey to make an actual ECDSA P-256 key pair, signs the actual bytes of your message with the private key, and verifies with the public one. The values shown are the real ones, truncated to fit. Toy demonstrations with small made-up numbers teach the shape of the idea and mislead about everything else.
What is the difference between signing and encrypting?
They point in opposite directions. Signing uses the private key to produce something anyone with the public key can check — it proves origin and hides nothing. Encrypting uses the public key so only the private key holder can read it — it hides the content and proves nothing about the sender. Real systems do both, in that order.
Why does it fail when Bob uses the wrong key?
Because the signature is tied to one specific key pair. But notice what that implies: if Bob had been handed an impostor's key while believing it was Alice's, the impostor's signatures would verify perfectly. Establishing whose key you hold is the genuinely hard problem here, and it is solved by certificate authorities, fingerprint comparison and prior contact — never by arithmetic.
What actually is a private key?
For ECDSA, essentially a large random integer. The public key is a point reached by adding a fixed starting point to itself that many times. Adding is fast; working out how many additions happened is not, and nobody has found a way to make it fast. That gap is the security — and it is a gap that has resisted attack rather than one proven to exist, which is why post-quantum cryptography is being developed.
Can I use this page's keys for anything real?
They are real keys, but they exist only while the page is open and are discarded when you press reset. If you want a key pair to keep, use the key pair generator, which exports both halves as PEM.
Is anything sent anywhere?
No. The keys are generated in your browser, the signing and verification happen there, and nothing is transmitted.