RSA key pairs explained: public, private, and what each one does

You run ssh-keygen, or you generate a signing key for a JWT, and you get two blobs: a public key you're told to hand out freely and a private key you're told to guard with your life. The asymmetry is the whole point of RSA, but it's easy to use the keys for years without a clear picture of which half does what. The rules are small, and getting them straight prevents the mistakes that actually bite.

Two keys, one math problem

Symmetric encryption uses a single shared secret — the same key locks and unlocks. RSA is asymmetric: it generates a mathematically linked pair where what one key does, only the other can undo. They're built from a large number (the modulus) that is the product of two big primes. The security rests on a simple asymmetry of effort: multiplying the primes is trivial, factoring the modulus back into them is infeasible at the right size. The public key can be shared because knowing it doesn't reveal the primes; the private key is the one that secretly knows them.

If the words encrypt, sign, and hash feel interchangeable, they aren't — the separation in hashing, encryption, and encoding is worth pinning down before the next part, because RSA does two of those three and people routinely mix them up.

The two operations, and which key goes where

RSA supports two distinct operations, and they use the keys in opposite directions. This is the single most confused point, so it's worth stating flatly:

• Encryption — anyone encrypts with the public key; only the holder of the private key can decrypt. This is how you send a secret to someone: their public key locks it, their private key opens it.
• Signing — the owner signs with the private key; anyone verifies with the public key. This proves a message came from the key's owner and wasn't altered. It does not hide the message — a signature is authenticity, not confidentiality.

The mirror image trips people up: encrypting uses the public key, signing uses the private key. A useful way to hold it: the private key is the one only you have, so the operations only you should be able to do — decrypting messages meant for you, and signing as you — are the private-key operations.

Key size, and why 2048 is the floor

RSA security scales with the modulus size, measured in bits. The practical baseline today is 2048 bits; 3072 or 4096 buy more margin at the cost of slower operations and larger keys. Anything 1024 or below is considered broken and should be rotated out. The jump isn't linear — a 3072-bit RSA key is roughly comparable to a 128-bit symmetric key in strength, which is part of why the keys feel so large relative to the protection they give.

That bulk is RSA's main drawback, and the reason for the alternative below.

Where RSA shows up

You meet RSA key pairs in a handful of everyday places:

• TLS — historically the server's RSA key authenticated the handshake (modern TLS increasingly uses elliptic-curve keys for the exchange itself).
• SSH — ssh-keygen -t rsa produces the pair whose public half you paste into authorized_keys.
• JWTs — the RS256 algorithm signs a token with an RSA private key so any holder of the public key can verify it, the pattern compared against the alternatives in JWT signing algorithms.

RSA vs the elliptic-curve options

For signing, RSA is no longer the obvious default. EdDSA (Ed25519) and ECDSA reach equivalent security with far smaller keys — an Ed25519 key is 32 bytes where a comparable RSA key is hundreds — and sign faster. RSA's advantages now are mostly compatibility: some older systems only speak RSA, and RSA can encrypt directly while the EC schemes are sign-only (encryption there goes through a key-exchange step). For a new signing key with no legacy constraint, Ed25519 is usually the better pick; reach for RSA when something in the stack requires it.

The PEM format you'll actually see

Keys are stored as PEM: base64 wrapped in -----BEGIN ... ----- markers. The header tells you the layout. BEGIN PUBLIC KEY and BEGIN PRIVATE KEY are the modern PKCS#8/SPKI encodings that hold the algorithm identifier alongside the key; BEGIN RSA PRIVATE KEY is the older PKCS#1 form that's RSA-specific. They carry the same key in different envelopes, which is why tools sometimes ask you to convert between them. The base64 itself is just encoding — readable by anyone, no protection — so a private key PEM is only as safe as the file permissions and passphrase around it.

What to be careful about

The honest limits matter more here than with most tools:

• Don't implement RSA yourself. Textbook RSA without correct padding (OAEP for encryption, PSS for signing) is exploitable. Use a vetted library and the right padding mode.
• A public key is not a license to skip TLS. Encrypting a payload to someone's public key protects that payload, not the rest of the connection.
• Guard and rotate the private key. Its only protection is secrecy; once leaked, every signature and decryption it ever guarded is compromised, and there's no revoking math.

To see the two halves of a real pair without installing anything, our RSA key pair generator creates one in the browser so you can inspect the PEM structure described above. Generate a throwaway pair, look at where the PUBLIC/PRIVATE markers fall, and the rest of this stops being abstract.