Public key cryptography (also called asymmetric cryptography) is the foundation of SSL/TLS. It uses a pair of mathematically related keys — one public, one private — to encrypt data, verify identities, and establish secure connections. Every HTTPS connection depends on it.
The key pair concept
| Public key | Private key | |
|---|---|---|
| Who has it | Everyone (it’s in the certificate) | Only the server owner |
| Can encrypt | ✅ | ✅ |
| Can decrypt | Only what private key encrypted | Only what public key encrypted |
| Share it? | Yes — that’s the point | Never |
The magic: data encrypted with the public key can only be decrypted with the matching private key. And vice versa. The two keys are mathematically linked, but you can’t derive the private key from the public key.
How it’s used in SSL/TLS
Public key cryptography serves three purposes in every HTTPS connection:
1. Key exchange — establishing a shared secret
During the TLS handshake, the server and browser need to agree on a shared session key for encrypting traffic. They can’t send this key in plaintext — someone might intercept it.
Solution: Diffie-Hellman key exchange (specifically ECDHE in modern TLS). Both sides contribute random values, and mathematics lets them compute the same shared secret without ever transmitting it. The server’s private key signs its contribution, proving the server’s identity.
2. Authentication — proving identity
The server’s SSL certificate contains its public key. The certificate is signed by a Certificate Authority. During the handshake, the server proves it holds the matching private key. This proves the server is who the certificate says it is.
Without this step, anyone could claim to be google.com.
3. Digital signatures — proving data integrity
The private key can create a digital signature — a mathematical proof that a specific piece of data was signed by the key holder and hasn’t been modified. The TLS handshake messages are signed to prevent tampering.
Symmetric vs asymmetric encryption
| Asymmetric (public key) | Symmetric (session key) | |
|---|---|---|
| Keys | Two (public + private) | One (shared secret) |
| Speed | Slow (~1000x slower) | Fast |
| Used for | Key exchange + authentication | Encrypting actual data |
| Algorithms | RSA, ECDSA, ECDHE | AES-GCM, ChaCha20 |
| In TLS | During handshake only | After handshake (all traffic) |
HTTPS uses both: asymmetric encryption for the handshake (proving identity, exchanging keys), then symmetric encryption for the actual data transfer (because it’s much faster).
The algorithms behind SSL
RSA
The oldest public key algorithm still in use (1977). Based on the difficulty of factoring large prime numbers. Used for both signatures and key exchange, though RSA key exchange (without Diffie-Hellman) doesn’t provide forward secrecy and is removed from TLS 1.3.
ECDSA (Elliptic Curve Digital Signature Algorithm)
Modern signature algorithm using elliptic curve math. A 256-bit ECC key provides equivalent security to a 3072-bit RSA key — smaller keys, faster signatures. GetHTTPS defaults to ECDSA P-256.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
The key exchange mechanism used in modern TLS. “Ephemeral” means a new key pair is generated for every connection — providing forward secrecy. Used in both TLS 1.2 and 1.3.
AES-GCM
The symmetric cipher used after the handshake to encrypt actual traffic. AES (Advanced Encryption Standard) with GCM (Galois/Counter Mode) provides both encryption and authentication. Hardware-accelerated on modern CPUs via AES-NI instructions.
How GetHTTPS uses public key cryptography
When you use GetHTTPS:
- Your browser generates a key pair using the Web Crypto API — the same cryptographic primitives that TLS itself uses
- The public key goes into a CSR sent to Let’s Encrypt
- The private key stays in your browser memory — never transmitted
- Let’s Encrypt signs the public key and returns your certificate
- You download both the certificate (public) and private key to your server
The private key existing only in browser memory is why GetHTTPS is more private than tools that generate keys on a remote server.
Frequently asked questions
Can quantum computers break public key cryptography?
Current quantum computers cannot. But a sufficiently powerful quantum computer running Shor’s algorithm could break RSA and ECC. The industry is preparing with post-quantum cryptography — new algorithms (ML-KEM, ML-DSA) resistant to quantum attacks. TLS will adopt these in a hybrid mode (classical + post-quantum) without changing how certificates work.
Why not just use asymmetric encryption for everything?
Speed. Asymmetric operations are roughly 1000x slower than symmetric. Encrypting a webpage with RSA would be impractically slow. Instead, TLS uses asymmetric crypto only for the handshake (~1ms), then switches to symmetric (AES) for the data — which runs at hardware speed.
Is 256-bit ECC key really secure enough?
256-bit ECC provides ~128 bits of security — meaning an attacker would need approximately 2^128 operations to break it. That’s more operations than atoms in the observable universe. It’s secure for the foreseeable future (excluding quantum computers, which require different algorithms entirely).
What’s the difference between encryption and signing?
Encryption: Protect confidentiality. Encrypt with the recipient’s public key → only their private key can decrypt. Signing: Prove authenticity. Sign with your private key → anyone with your public key can verify it came from you and wasn’t modified. TLS certificates use signatures; TLS data transfer uses encryption.