How does public-key encryption work? Public and private keys explained

Updated: Oct 28, 2026

Public-key cryptography uses a related key pair. A public key can be shared with anyone; a private key must remain secret. One common use is to encrypt data for a recipient who can decrypt it with the private key, while digital signatures let others verify that a message came from the holder of the private key. This idea sits underneath HTTPS, SSH, encrypted messaging, software updates and most modern authentication, so it is worth understanding without the mathematics.

Encrypting with one key, decrypting with the other

Older encryption schemes used a single shared secret: whoever knew the key could both lock and unlock the message. That works until you ask how two strangers on the internet are supposed to agree on a secret without an eavesdropper hearing it. Public-key cryptography solves that problem by splitting the key in two.

The two keys are mathematically linked, but knowing the public key does not let anyone compute the private key in any realistic amount of time. Because of that asymmetry, the pair can be used in two directions:

• Encryption. Anyone can encrypt a message with the recipient’s public key. Only the matching private key can decrypt it. The public key can be printed on a website; the private key never leaves the owner’s device.
• Signatures. The owner computes a signature over a message using the private key. Anyone with the public key can check that the signature is valid, proving that the message was produced by the private key holder and has not been altered since.

In practice, public-key operations are slow compared with symmetric encryption, so real protocols combine them. A TLS connection, for example, uses public-key methods once to agree on a fresh symmetric session key, then encrypts the actual traffic with that faster key. The same pattern appears in encrypted email and messaging apps: the asymmetric part protects the key exchange, the symmetric part protects the content.

Where you meet it every day

HTTPS. A website’s certificate contains its public key. Your browser uses it to set up an encrypted session and to check that the server can prove possession of the corresponding private key. A certificate authority signs the certificate so the browser can trust that the key really belongs to that domain.

SSH keys. Instead of a password, you place your public key on the server. When you connect, the server challenges your client to prove it holds the private key. Nothing secret crosses the network.

Software updates. Vendors sign their packages. Your device verifies the signature before installing, which is why a tampered download fails even if it came from a mirror you have never heard of.

Passkeys and hardware security keys. A passkey is a private key stored on your device; the website keeps only the public part. Phishing sites cannot use it because the signature is bound to the real domain.

What the mathematics does not protect

The algorithms are rarely the weak point. The system around them is.

• A stolen private key. If an attacker copies the key file from a laptop or a poorly protected server, every guarantee disappears. Keys should be protected by file permissions, a passphrase or, better, hardware that never exports them.
• A substituted public key. If you accept the wrong public key at the start, you will happily encrypt messages for the attacker. This is why certificate authorities, SSH host key fingerprints and “safety numbers” in messaging apps exist: they are all ways of verifying that a public key belongs to the party you think it does.
• Weak key generation. Keys created from poor randomness can be guessed. Use well-known libraries and up-to-date defaults rather than custom code.
• No rotation or revocation plan. Keys age. Certificates expire on purpose so that a compromised key has a limited useful life. Organisations need a way to revoke and reissue keys quickly.

Using key pairs safely day to day

• Never invent your own encryption scheme or protocol. Use established libraries and the modern defaults they ship with.
• Keep private keys private: strong access controls, passphrases, hardware tokens where possible, and never in a chat message, a screenshot or a public repository.
• Verify public keys through a trusted channel before relying on them: check the fingerprint of an SSH host on first connection and take certificate warnings seriously.
• Plan for loss and compromise. Back up encrypted data together with a recovery method, and know how to revoke and replace a key.
• Prefer phishing-resistant methods such as passkeys or security keys for important accounts; they are public-key cryptography applied to login.

Frequently asked questions

If the public key is public, how can the system be secure?

Because the public key only allows operations that are meant to be public: encrypting to the owner and verifying the owner’s signatures. Decrypting and signing require the private key, which cannot be derived from the public one.

Is a longer key always better?

Up to a point. Recommended sizes already give a comfortable safety margin; the bigger gains come from protecting the key and using it correctly, not from doubling its length.

What happens when quantum computers arrive?

Some current algorithms would be weakened, which is why post-quantum algorithms are being standardised and gradually deployed in protocols like TLS. The design principle of a public and private half stays the same.

Encryption is a system of keys, identities and protocols; the algorithm alone is not the whole security model.

In short: Public-key cryptography lets strangers communicate securely and prove authorship without sharing a secret in advance. Its strength depends on protecting private keys and verifying public ones, not just on the mathematics.