Every TLS certificate, every SSH connection, every Bitcoin transaction, every digitally signed document relies on the same concept: a mathematically linked pair of keys where one is public (shared freely) and one is private (kept secret). Data encrypted with the public key can only be decrypted with the private key. Data signed with the private key can be verified by anyone with the public key.
This is asymmetric cryptography — and it solves the fundamental problem of secure communication: how do two parties establish trust without a pre-existing shared secret?
The Core Concept
A key pair consists of two mathematically related values:
Public key: Shared openly. Anyone can have it. Published in certificates, on key servers, in DNS records. Used to: encrypt data for the key owner, or verify signatures made by the key owner.
Private key: Kept absolutely secret. Only the owner possesses it. Never transmitted, never shared, never exposed. Used to: decrypt data encrypted with the matching public key, or create digital signatures.
The critical property: You cannot derive the private key from the public key. The math is one-way — easy to compute in one direction (private → public), computationally infeasible to reverse (public → private).
How They Work Together
Encryption (Confidentiality)
Alice wants to send a secret message to Bob:
1. Alice obtains Bob's PUBLIC key (from his certificate, key server, etc.)
2. Alice encrypts the message with Bob's public key
3. Alice sends the encrypted message (ciphertext)
4. Bob decrypts with his PRIVATE key (only he has it)
5. Nobody else can decrypt — only Bob's private key works
Eavesdropper sees: ciphertext (useless without Bob's private key)Digital Signatures (Authenticity + Integrity)
Bob wants to prove he wrote a document:
1. Bob hashes the document: hash = SHA-256(document)
2. Bob signs the hash with his PRIVATE key: signature = Sign(hash, private_key)
3. Bob publishes: document + signature
4. Anyone verifies with Bob's PUBLIC key: Verify(signature, public_key) == hash?
5. If yes: document is authentic (Bob signed it) and unmodified (hash matches)
Forger can't create valid signature without Bob's private keyTLS (Both Combined)
Browser connects to https://bank.com:
1. Server presents certificate (contains server's PUBLIC key)
2. Server signs the handshake with its PRIVATE key (CertificateVerify)
3. Browser verifies signature with server's public key (proves identity)
4. Both perform ECDHE key exchange (using public/private key math)
5. Shared secret derived → symmetric session keys → encrypted communication
Result: browser knows it's talking to the real bank.com (not an impersonator)Key Pair Algorithms
| Algorithm | Public Key Size | Private Key Size | Security Level | Use Case |
|---|---|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes | 112-bit | TLS certs (legacy) |
| RSA-4096 | 512 bytes | 512 bytes | ~140-bit | CA signing keys |
| ECDSA P-256 | 64 bytes | 32 bytes | 128-bit | TLS certs (modern) |
| ECDSA P-384 | 96 bytes | 48 bytes | 192-bit | High-security certs |
| Ed25519 | 32 bytes | 32 bytes | 128-bit | SSH keys, signatures |
| X25519 | 32 bytes | 32 bytes | 128-bit | Key exchange (TLS 1.3) |
Where Key Pairs Are Used
TLS/SSL Certificates
Every HTTPS website has a key pair:
- Private key: On the web server (or in an HSM). Used to prove server identity during TLS handshake.
- Public key: In the certificate. Sent to every connecting client. Used to verify the server’s identity.
# Generate key pair for TLS
openssl ecparam -genkey -name prime256v1 -out server.key # Private key
openssl req -new -key server.key -out server.csr # CSR contains public key
# CA signs the CSR → certificate (public key + identity + CA signature)SSH Authentication
# Generate SSH key pair
ssh-keygen -t ed25519 -C "user@example.com"
# Creates: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public)
# Public key → deployed to server (authorized_keys)
# Private key → stays on your machine (never leaves)
# Authentication: server challenges, client signs with private keyCode Signing
- Private key: In an HSM, used by the build pipeline to sign software
- Public key: In the code signing certificate, used by end users to verify the signature
Cryptocurrency
- Private key: Controls your wallet (spend funds)
- Public key: Derives your wallet address (receive funds)
- Lose the private key = lose all funds permanently
Email Encryption (S/MIME, PGP)
- Public key: Published, used by others to encrypt emails TO you
- Private key: Used to decrypt emails sent to you, and to sign emails FROM you
Protecting the Private Key
The private key is the single most critical secret in any cryptographic system. If it’s compromised:
| System | Impact of Private Key Compromise |
|---|---|
| TLS certificate | Attacker can impersonate your server (MITM) |
| SSH key | Attacker has access to all servers trusting that key |
| Code signing | Attacker can sign malware as your organization |
| CA signing key | Attacker can issue certificates for ANY domain |
| Cryptocurrency | Attacker steals all funds |
Protection Hierarchy
Best: HSM (key generated inside, never extractable)
Good: Cloud KMS (non-exportable, API-only access)
OK: Encrypted file with passphrase (ssh-keygen -p)
Bad: Plaintext file with restrictive permissions (chmod 600)
Worst: Plaintext in source code, config file, or emailWhat to Do If a Private Key Is Compromised
- Revoke immediately — contact your CA to revoke the certificate
- Generate new key pair — never reuse a compromised key
- Request new certificate — with the new key
- Deploy new certificate — to all servers
- Investigate — how was the key exposed? Fix the root cause.
- Notify — if the compromise affected customers or partners
Common Misconceptions
“The public key encrypts, the private key decrypts” Partially true. For encryption: yes. But for signatures: the private key signs (encrypts the hash), and the public key verifies (decrypts the signature). Both keys can perform cryptographic operations — just different ones.
“Longer keys are always better” Not necessarily. ECC P-256 (32-byte key) provides the same security as RSA-3072 (384-byte key). Key length comparisons only make sense within the same algorithm family.
“If I lose my private key, I can regenerate it from the public key” No. The entire security of asymmetric cryptography depends on this being impossible. If you lose the private key, you must generate a new key pair and get a new certificate.
“My private key is in the certificate” No. The certificate contains only the public key. The private key is a separate file that should never be in the same location as the certificate (except in PKCS#12/PFX bundles which are password-protected).
FAQ
Q: Can someone decrypt my HTTPS traffic if they have my public key? A: No. The public key is… public. Everyone has it (it’s in your certificate). Decryption requires the private key. That’s the entire point of asymmetric cryptography.
Q: What’s the difference between a key pair and a certificate? A: A key pair is the raw cryptographic material (public key + private key). A certificate is a signed document that binds the public key to an identity (domain name, organization). The certificate contains the public key + identity + CA’s signature. The private key is separate.
Q: Should I use RSA or ECC for new key pairs? A: ECC (P-256 or Ed25519) for new deployments. Smaller keys, faster operations, same security. RSA only for legacy compatibility.
Q: How do I check if my private key matches my certificate?
# Compare modulus (RSA) or public key point (ECC)
openssl x509 -noout -modulus -in cert.pem | md5sum
openssl rsa -noout -modulus -in key.pem | md5sum
# If both MD5 hashes match → key and cert are a pairQ: Can two people have the same key pair? A: Theoretically possible but astronomically unlikely. A 256-bit key has 2²⁵⁶ possible values — more than atoms in the observable universe. Collision is not a practical concern.