Asymmetric Cryptography
A public key anyone may hold and a private key only one party holds — enabling key exchange without a shared secret, signatures anyone can verify, and identity that does not require pre-sharing anything.
Frame the problem
Security starts with a concrete asset, attacker capability and trust crossing.
Four uses, not one
Asymmetric algorithms are not interchangeable and the uses are distinct. Encryption to a public key: only the private key decrypts — used to send a symmetric key, rarely for bulk data (too slow). Signatures with a private key: anyone with the public key verifies — authenticity and integrity (Digital Signatures). Key exchange (Diffie-Hellman, X25519): two parties derive a shared secret from their key pairs without transmitting it — how TLS gets its session key. Identity: possession of a private key proves you are the party whose public key was registered — SSH keys, passkeys, mTLS.
Different algorithms serve different uses. Ed25519 signs; X25519 exchanges keys; RSA can do both but is slower and easier to misuse. Do not use a signing key for encryption or vice versa.
| Use | Operation with public key | Operation with private key | Provides |
|---|---|---|---|
| Encryption | Encrypt | Decrypt | Confidentiality to one recipient |
| Signature | Verify | Sign | Authenticity, integrity, non-repudiation |
| Key exchange | Combine with own private | Combine with peer's public | Shared secret over a public channel |
| Identity | Registered as the identity | Prove possession by signing a challenge | Authentication without a shared secret |
The public-key distribution problem
The public key can be public, but you must know it is *the right* public key. An attacker who substitutes theirs reads everything and signs anything. Binding a public key to an identity is the job of certificates and a trust chain (Certificate Trust Chains), or of an out-of-band registration (SSH known_hosts, a passkey enrolled during an authenticated session).
Key points
- Public key: encrypt/verify; private key: decrypt/sign.
- Asymmetric crypto agrees or transports symmetric keys; it does not encrypt bulk data.
- Do not reuse one key pair across purposes.
- Knowing you have the *right* public key is the whole trust problem.
Boundary control exercise
This lesson uses the shared boundary-control exercise.
Follow the attack
Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.
- 1Attacker → private key from disk, CI, or memory; or substitute a public key where binding is unverified.
- Impersonation of the key holder; decryption of everything sent to them.
Defend, detect, recover
One prevention is a single point of security failure. Layer it and make failure observable.
- • Private keys in HSMs or KMS; never in repositories; rotate; bind public keys through certificates or authenticated enrolment.
- • Signatures from unexpected key ids; certificate transparency for your domains.
- • Revoke and rotate; re-issue certificates; invalidate tokens signed under the old key.
- • Long-lived keys accumulate exposure; post-quantum transitions are coming.