Glossary
What is public-key cryptography — encrypting and signing with a key pair
Public-key cryptography uses a public + private key pair: the public key encrypts and verifies signatures, the private key decrypts and signs. This explains how it underpins TLS (HTTPS), digital signatures, and passkeys — and the practical defenses: don't roll your own crypto, protect the private key.
"Public key" and "private key" show up everywhere — TLS (HTTPS), digital signatures, passkeys. No attack steps here — just the idea of public-key cryptography and the practical defenses worth knowing.
The roles of the public and private key
The keys come as a pair, with opposite roles — that's the whole point.
What it's used for
Encryption (private exchange)
- encrypt with the recipient's public key
- only the holder of the matching private key can decrypt
- in TLS, used to safely share a symmetric key
Digital signatures (proving authenticity)
- the sender signs with their private key
- the receiver verifies with the public key — identity + integrity
- used for TLS certificates, software distribution, passkey auth
Real TLS (HTTPS) is hybrid: public-key crypto safely shares a symmetric key, then the fast symmetric cipher protects the rest. Passkeys sign with a private key held on your device and verify with the server's public key — phishing-resistant authentication.
What to get right
Don't roll your own crypto
Even correct theory gets broken by implementation details — randomness quality, padding, timing. Use standard protocols and battle-tested libraries; avoid custom implementations.
Protect the private key
Keep private keys out of code and repos. Isolate them in a keystore / secret manager, and run things so you can revoke and reissue (rotate) on leak (→ keep secrets out of public directories).
Keep key length and algorithms current
Recommendations change over time. Don't leave old key lengths or deprecated algorithms in place. Auto-renew certificates with Let's Encrypt and friends.
This site's view: the user's job is key management
Public-key crypto itself is strong — there's rarely a need to break it. Real-world incidents aren't about the math but about where the private key lives, whether you can revoke it, and stale settings left in place. This site isolates private keys off the public surface and rotates on any suspicion of leak, treating it as "assume it was read." Don't roll your own; ride the standards — that's the safest shortcut.
Read next
FAQ
QHow is public-key crypto different from symmetric (shared-key) crypto?
Symmetric crypto uses the same key to encrypt and decrypt — fast, but you have to get that key to the other party safely. Public-key crypto uses a public + private pair, and the public key can be shared with anyone. In practice TLS (HTTPS) is hybrid: public-key crypto safely shares a symmetric key, then the bulk of the data is protected with the fast symmetric cipher.
QHow does a digital signature prove something is genuine?
The sender creates a signature over the data with their private key, and the receiver verifies it with the sender's public key. Because only the owner holds the private key, a passing check means 'the holder of that public key signed it, and the content wasn't tampered with.' TLS certificates and software-distribution authenticity rely on this signature mechanism.
QCan I implement my own crypto?
Avoid it. Even correct theory gets broken by implementation details — weak randomness, padding, timing differences. The rule is 'don't roll your own; use battle-tested libraries and standard protocols.' Design how keys are generated, stored, and revoked (rotated), and keep key lengths and algorithms on the current recommendations.