Public-key cryptography

You hand out your public key as freely as your email address, and nothing bad happens. The private key is the one thing you never give to anyone – not even to a very friendly support chat.

The short answer

Public-key cryptography uses two related keys: a public key that you can share and a private key that you keep secret. Given the public key, it is computationally infeasible to derive the private key [1]. What is each key for? Whatever you sign with the private key, anyone can verify with the public key, and with your public key others can protect data or agree on a shared secret that only you, the private-key holder, can use [1]. SSH, TLS, WireGuard and passkeys all build on this. Our assessment: you rarely need the math, but you always need to know which of your keys is private and where it lives.

How it works

1. The key pair. NIST describes public-key cryptography as cryptography with two related keys, one to encrypt or sign and one to decrypt or verify [1]. The private key stays secret, while the public key can be handed out freely [1].
2. Signing. You sign data with your private key, and anyone can check the signature with the matching public key [1]. Ed25519, a signature scheme described in RFC 8032, uses public keys of 32 bytes and signatures of 64 bytes [2].
3. Agreeing on a key. Public-key methods let two parties communicate securely without sharing a secret beforehand [1]. TLS 1.3 does this with (EC)DHE, Diffie-Hellman over finite fields or elliptic curves, and the server proves its identity with a signature over the whole handshake, made with the private key that belongs to the public key in its certificate [3].
4. SSH. SSH logins follow the same pattern: the server knows your public key, and your client proves that it holds the matching private key. Since version 9.5, OpenSSH's ssh-keygen generates Ed25519 keys by default and points to their small public keys as the reason [4].
5. WireGuard. Every WireGuard interface has a private key and a list of peers, and each peer is identified by its public key; a connection is set up by exchanging public keys, "exactly like exchanging SSH keys" [5]. WireGuard lists Curve25519 among its cryptographic building blocks [5].
6. Passkeys. Passkeys bring the same idea to website logins; our Passkey entry explains how.
7. Whose key is it? A public key is only useful if you know whose it is. In TLS, the certificate ties the public key to a name [3]; with SSH and WireGuard, you check that yourself when you add a key.

A practical example

You create an SSH key pair on your laptop:

ssh-keygen -t ed25519

The command writes a private key file and a matching public key file whose name ends in .pub. Only the .pub file goes onto the server, typically into ~/.ssh/authorized_keys; the private key never leaves your laptop. With OpenSSH 9.5 or newer, Ed25519 is the default anyway, so -t ed25519 only makes it explicit [4]. WireGuard follows the same pattern: you give your peer the line with your PublicKey and keep the PrivateKey to yourself [5]. This is a generic walk-through, not a copy of our server configuration.

Checklist

• Protect every private key with a passphrase or a hardware key, and never send it to anyone.
• Share only public keys: the .pub file for SSH, the PublicKey value for WireGuard [5].
• Prefer Ed25519 for new SSH keys; OpenSSH has used it by default since version 9.5 [4].
• Check that a public key really belongs to the other side before you trust it [3].
• Replace a key pair right away if a private key may have leaked.