Updated 8 hours ago
For thousands of years, secret communication required a prior secret. If you wanted to send an encrypted message, you first had to meet in person to agree on a code. Armies, diplomats, lovers—everyone faced the same problem. You couldn't communicate securely until you'd already communicated securely.
Public-key cryptography broke this ancient constraint. In 1976, Whitfield Diffie and Martin Hellman published an idea that seemed almost paradoxical: two keys, mathematically related, where knowing one tells you nothing useful about the other.
You can publish your public key on a billboard. Shout it from rooftops. Post it on every website on the Internet. None of that helps an attacker, because the math only works in one direction. Only your private key can decrypt what your public key encrypts. Only your private key can create signatures your public key can verify.
This is the foundation of SSL/TLS. Every certificate contains a public key. The corresponding private key never leaves the server.
The One-Way Street
The security of public-key cryptography rests on mathematical operations that are easy in one direction and practically impossible in reverse.
RSA exploits the fact that multiplying two large prime numbers is trivial, but factoring their product is extraordinarily hard. Your private key includes two primes (p and q). Your public key includes their product (n = p × q). A computer can multiply million-digit numbers in microseconds. Factoring n back into p and q, when n is 2048 bits or larger, would take longer than the age of the universe with current technology.
Elliptic Curve Cryptography (ECC) uses a different one-way street. The private key is a number. The public key is computed by multiplying a point on an elliptic curve by that number. Going forward is fast. Going backward—finding the number given only the result—is computationally infeasible.
These aren't arbitrary problems. Mathematicians have studied integer factorization for centuries and the elliptic curve discrete logarithm problem for decades. The best attacks we know would still take impossibly long. Not just impractically long—longer than the sun will burn.
What the Keys Actually Do
Public key encrypts, private key decrypts. Anyone can send you a secret using your public key. Only you can read it.
Private key signs, public key verifies. You can prove a message came from you—and hasn't been tampered with—by signing it with your private key. Anyone with your public key can verify the signature.
Together, they solve key exchange. The actual data in a TLS session is encrypted with fast symmetric encryption (same key on both sides). But how do two strangers agree on that symmetric key without an eavesdropper learning it? Public-key cryptography solves this. The handshake uses asymmetric encryption to securely exchange a symmetric key, then switches to symmetric encryption for speed.
The Public Key Lives in Your Certificate
When a browser connects to your server over HTTPS, your server sends its certificate. That certificate contains your public key, wrapped in a Certificate Authority's signature that says: "Yes, this public key really belongs to this domain."
The browser extracts the public key and uses it to verify that your server actually possesses the corresponding private key. If someone intercepted the certificate and tried to impersonate your server, they'd fail—they can show the public key, but they can't prove they have the private key.
The public key is meant to be public. Publishing it doesn't weaken your security. That's the whole point.
The Private Key Is Everything
Your private key is the most sensitive secret your server holds. Anyone who obtains it can:
Become you. They can complete TLS handshakes as your server, intercepting traffic intended for you. Users would see a valid certificate, a green padlock, everything normal—while talking to an attacker.
Read your past. For connections that didn't use Perfect Forward Secrecy, recorded traffic can be decrypted retroactively.
Sign as you. They can create digital signatures that appear to come from your organization.
Private key compromise isn't a minor incident. It's catastrophic. The only response is immediate revocation, generating a completely new key pair, obtaining a new certificate, and deploying it everywhere.
Generating Your Keys
You create the key pair before requesting a certificate. Both keys are generated together—they must be, since they're mathematically bound.
For RSA:
This creates a 2048-bit RSA private key. The file actually contains both keys (the public key can be derived from the private key, though not vice versa).
To extract just the public key:
For Elliptic Curve:
This generates a 256-bit ECC key using the P-256 curve.
Key Sizes: Bigger Isn't Always Better
RSA 2048-bit is the current standard—about 112 bits of security. Each additional bit of security doubles the work required for an attacker, so 112 bits means 2^112 possible keys to brute-force. That's beyond any computer that will ever exist.
RSA 4096-bit provides more margin but is slower. Most sites don't need it.
ECC 256-bit provides roughly 128 bits of security—equivalent to RSA 3072-bit—with much smaller keys and faster operations. This is why ECC is increasingly preferred.
RSA 1024-bit is broken. Don't use it.
Protecting Your Private Key
File permissions matter. On Unix systems, set your private key to 400 or 600—readable only by the owner.
Hardware Security Modules (HSMs) are specialized devices that store private keys and perform cryptographic operations without ever exposing the key material. The key literally cannot be extracted. High-security environments use these.
Cloud key management services provide similar protection through software, with access controls and audit logging.
Passphrase protection encrypts the private key file itself. This adds security but means someone must enter the passphrase every time the server restarts—problematic for automation.
How Private Keys Get Compromised
Server breaches. Attackers gain shell access and copy the key file.
Exposed backups. The backup tape sitting in an unlocked cabinet contains your private key.
Insider access. An employee or contractor with server access walks out with a copy.
Software bugs. Heartbleed let attackers read server memory, potentially including private keys.
Supply chain attacks. Compromised certificate management tools exfiltrate keys during normal operations.
If you suspect compromise, don't wait to confirm it. Revoke immediately.
Perfect Forward Secrecy: Limiting the Damage
Perfect Forward Secrecy (PFS) uses ephemeral keys—generated fresh for each session, then discarded. Even if your long-term private key is stolen, past sessions remain encrypted. The attacker can impersonate you going forward, but they can't retroactively decrypt the traffic they recorded last year.
Modern TLS requires PFS. Your long-term private key proves your identity during the handshake, but the actual session encryption uses ephemeral keys that exist only in memory and vanish when the connection closes.
This is why stealing a private key is still catastrophic but not infinitely catastrophic. With PFS, the past stays private.
Key Formats
Private keys come in several encodings:
PKCS#1 is the traditional RSA format: -----BEGIN RSA PRIVATE KEY-----
PKCS#8 is more general, supporting various key types: -----BEGIN PRIVATE KEY-----
PEM is the text format with Base64 encoding and header/footer lines (the above are both PEM).
DER is binary encoding of the same data.
Most tools handle all formats and convert between them automatically.
Rotate Your Keys
When renewing a certificate, you can reuse the old private key or generate a new one. Generate a new one.
New keys provide defense in depth. If your old key was compromised without your knowledge, generating a new key limits the exposure. It's cryptographic hygiene—the marginal effort of generating new keys is trivial compared to the marginal risk of reusing old ones.
Frequently Asked Questions About Public and Private Keys
Was this page helpful?