Overview

Symmetric cryptography needs both parties to already share a secret. That leaves a chicken-and-egg problem: how do two strangers agree on a key over a wire that an attacker is reading? Asymmetric (public-key) cryptography solves it by splitting the secret into a keypair, and that single idea is what makes TLS, SSH, signed software, and end-to-end messaging possible.

The public/private key idea

Every entity holds a keypair: a private key it guards, and a public key it hands out freely. The two are linked by a math problem that is easy to run forward and infeasible to reverse. That asymmetry unlocks three distinct capabilities:

Capability	Who uses which key	What it gives you
Key exchange	Both derive a shared secret from the other’s public key	A symmetric key over a public channel
Encryption	Sender encrypts with recipient’s public key	Only the private-key holder can read it
Signatures	Signer signs with private key, anyone verifies with public	Authenticity and integrity

The private key is the whole game. If it leaks, every guarantee above collapses. That is why the sibling group Key Management exists at all.

A subtle but important point: public-key operations are slow and size-limited. In practice you almost never encrypt bulk data with them. Instead you use asymmetric crypto to establish or protect a symmetric key, then encrypt the actual payload symmetrically. This is hybrid encryption, and it is what tools like age and protocols like TLS do under the hood.

RSA and elliptic curves compared

Two families dominate. RSA rests on the difficulty of factoring large numbers. Elliptic-curve cryptography (ECC) rests on the elliptic-curve discrete-logarithm problem. ECC reaches the same security level with far smaller keys, which means less bandwidth, less CPU, and less to store.

Property	RSA	Elliptic Curve
Hard problem	Integer factoring	EC discrete log
Key size for ~128-bit security	3072 bits	256 bits
Signing speed	Slow	Fast
Verification speed	Fast	Fast
Maturity / ubiquity	Very high	High and growing
Recommended for new work	Only if a peer requires it	Yes

See the sibling pages RSA and Elliptic Curves for the details of each, and Digital Signatures for how both are used to sign.

Key exchange, forward secrecy, and signatures

Key exchange lets two parties agree on a shared secret without ever transmitting it. Diffie-Hellman (and its modern elliptic-curve form, ECDH) is the canonical method, covered in the sibling page Diffie-Hellman.

The upgrade that matters most in practice is forward secrecy: use a fresh, throwaway (ephemeral) keypair for each session. If a long-term key is later stolen, past sessions stay unreadable because their ephemeral keys are already gone.

But key exchange alone is defenceless against a man-in-the-middle who swaps public keys mid-flight. The fix is authentication via digital signatures: bind a public key to an identity so the peer can prove who they are. Exchange gives you confidentiality; signatures give you authenticity. Real protocols need both.

Hands-on: generate a keypair and inspect it

mkdir -p ~/crypto-lab && cd ~/crypto-lab
openssl genpkey -algorithm ed25519 -out id_ed25519.pem
openssl pkey -in id_ed25519.pem -pubout -out id_ed25519.pub.pem
openssl pkey -in id_ed25519.pem -text -noout

Expected output:

ED25519 Private-Key:
priv:
    a7:1c:3f:...:9b
pub:
    5e:88:0d:...:f2

The private key stays in id_ed25519.pem; the public key in id_ed25519.pub.pem is what you share.

Practical Guidance

1. Never encrypt bulk data directly with a public key. Use hybrid encryption: asymmetric to protect a symmetric key, symmetric for the payload.
2. For new keypairs prefer Ed25519 for signing and X25519 for key exchange. Use ECDSA P-256 where a peer requires NIST curves.
3. If you must use RSA, use at least 3072-bit keys and modern padding (OAEP for encryption, PSS for signatures).
4. Turn on forward secrecy wherever you control the protocol: use ephemeral key exchange so a future key compromise cannot decrypt past traffic.
5. Never run key exchange without authentication. Bind public keys to identities with signatures or certificates.
6. Guard private keys as your top priority and rotate them on a schedule, as covered in the Key Management group.