Almost every secure thing you do online — loading an HTTPS page, signing into your bank, sending an encrypted email — quietly relies on two different styles of encryption working together. They're usually called symmetric and asymmetric encryption, and the easiest way to tell them apart is to count the keys: symmetric uses one shared key for both locking and unlocking, while asymmetric uses a pair of related keys, one public and one private. Each solves a problem the other can't, which is exactly why SSL/TLS uses both in a single connection. This guide explains how each one works, where they differ, and how HTTPS combines them.
In short
Symmetric encryption uses a single shared key to encrypt and decrypt — it's fast, but both sides must somehow agree on that secret key first. Asymmetric encryption uses a public/private key pair — it's slower and works on small data, but it lets strangers establish a secret without ever transmitting it. TLS uses asymmetric cryptography to authenticate the server and agree on a key, then switches to symmetric encryption (typically AES) to protect the actual traffic.
Two families of encryption
Encryption turns readable data (plaintext) into scrambled data (ciphertext) using a key, so that only someone with the right key can turn it back. Every modern cipher falls into one of two families, and the dividing line is simple: does encrypting and decrypting use the same key, or two different keys?
Symmetric
One shared secret key does both jobs. Whoever has the key can both encrypt and decrypt. Think of an ordinary door lock where the same key locks and unlocks it.
Asymmetric
A mathematically linked key pair: a public key anyone can hold and a private key kept secret. What one key locks, only the other can unlock. Like a mailbox slot anyone can drop letters into, but only the keyholder can open.
That single difference cascades into everything else — speed, what each is good for, and above all how you get the key to the other party in the first place. The rest of this guide walks through both, then shows how TLS stitches them together.
How symmetric encryption works
In symmetric encryption, both the sender and the receiver hold the same secret key. The sender runs the plaintext and the key through a cipher to produce ciphertext; the receiver runs the ciphertext and the same key back through to recover the plaintext. The dominant symmetric cipher on the web is AES (Advanced Encryption Standard), usually with 128- or 256-bit keys.
Its great strength is speed. Symmetric ciphers are computationally cheap and often hardware-accelerated, so they can encrypt huge volumes of data — entire web pages, file downloads, video streams — with negligible overhead. This is why, once a connection is established, almost all of your actual traffic is protected symmetrically.
The key distribution problem
Symmetric encryption has one stubborn weakness: both parties must already share the secret key — and if you send that key over the same untrusted network you're trying to protect, an eavesdropper can simply grab it and decrypt everything. For two computers that have never met, "just agree on a secret key" is the entire problem. Solving it without a pre-shared secret is precisely what asymmetric encryption was invented for.
How asymmetric encryption works
Asymmetric encryption — also called public-key cryptography — uses two keys that are generated together as a pair and linked by hard math. One is the public key, which you can publish freely; the other is the private key, which you guard. Their defining property is that data transformed with one key of the pair can only be reversed with the other key, and knowing the public key doesn't let anyone feasibly compute the private one.
That asymmetry unlocks two distinct superpowers:
- Confidentiality. Anyone can encrypt a message to you using your public key, and only your private key can open it — so a secret can be sent to you without you first having to share anything secret.
- Authentication and signatures. You can sign data with your private key, and anyone can verify that signature with your public key. Because only you hold the private key, a valid signature proves the data came from you and wasn't altered. This is the basis of every CA-signed certificate.
The trade-off is cost. Asymmetric operations are dramatically slower than symmetric ones and are meant for small inputs — a session key, a hash, a signature — not bulk data. They're the foundation of public key infrastructure (PKI), and the two big families you'll meet are RSA and elliptic-curve cryptography (ECC).
Symmetric vs asymmetric, side by side
The two approaches differ on almost every practical axis. The point of the table isn't that one wins — it's that their strengths are mirror images, which is what makes them complementary.
| Property | Symmetric | Asymmetric |
|---|---|---|
| Keys used | One shared secret key | A public + private key pair |
| Speed | Very fast; suits large data | Much slower; small data only |
| Key distribution | Hard — the secret must reach both sides safely | Easy — the public key can be shared openly |
| Main job in TLS | Encrypting the actual traffic | Authentication + agreeing on the session key |
| Typical algorithms | AES, ChaCha20 | RSA, ECC (ECDSA, ECDHE) |
| Typical key size | 128 or 256 bits | RSA 2048-bit; ECC P-256 |
Notice the standout rows: symmetric is fast but struggles with key distribution; asymmetric distributes keys safely but is slow. Put them together and each one's weakness is covered by the other's strength.
Why TLS uses both
A web server and your browser have never met, share no secret in advance, and yet need to exchange a fast, encrypted session in milliseconds. Neither family alone can do that. Pure symmetric encryption can't bootstrap a shared key over an open network; pure asymmetric encryption is too slow to carry the page itself. So TLS does the obvious thing: it uses each one for the job it's best at. This combination is sometimes called a hybrid cryptosystem.
The hybrid handshake in one sentence
TLS uses asymmetric cryptography to authenticate the server and let both sides agree on a fresh secret, then uses that secret as a symmetric session key to encrypt all the real traffic — getting asymmetric's safe setup and symmetric's speed in a single connection.
There's a subtle but important detail in modern TLS. In TLS 1.2 and earlier, one option was to encrypt a client-chosen secret directly with the server's RSA public key. TLS 1.3 removed that static RSA key exchange entirely. Today every TLS 1.3 connection establishes its session key with an ephemeral Diffie-Hellman exchange (usually elliptic-curve, ECDHE), and the certificate's asymmetric key is used to sign the handshake rather than to encrypt the secret. The payoff is forward secrecy — because the secret is freshly negotiated and then discarded, capturing today's traffic and stealing the server's private key later still won't decrypt it.
Where each shows up in a handshake
It helps to map the two families onto the steps of a real connection. Here's the simplified flow of a TLS 1.3 handshake, with the encryption type called out at each stage:
- Key share (asymmetric). The browser and server each send an ephemeral Diffie-Hellman public value. Combining your own private value with the other side's public value lets both independently derive the same shared secret — without that secret ever crossing the wire.
- Authentication (asymmetric). The server presents its certificate and a digital signature over the handshake, created with its private key. Your browser verifies that signature with the public key in the certificate and checks the certificate chains to a trusted CA — proving you're really talking to the right server.
- Key derivation. Both sides feed the shared secret through a key derivation function to produce the actual symmetric session keys.
- Application data (symmetric). Every byte of real traffic from here on — the page, the form data, the API responses — is encrypted with a fast symmetric AEAD cipher such as AES-GCM. This is where the connection spends almost all of its time.
So the asymmetric work is a brief, expensive setup at the very start, and symmetric encryption does the long, cheap haul afterward. If you want the full play-by-play, our guide to how SSL works walks the entire handshake step by step.
The algorithms and key sizes
Key sizes aren't comparable across the two families — a 256-bit symmetric key and a 2048-bit RSA key represent very different amounts of work to break, because the underlying math is different. Here are the names you'll actually encounter:
Symmetric: AES and ChaCha20
AES with 128- or 256-bit keys is the standard, typically in an AEAD mode like GCM that encrypts and authenticates at once. ChaCha20-Poly1305 is a fast software-friendly alternative common on mobile. TLS 1.3 reduced its symmetric options to a short list of AEAD suites — including TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256. Our deep dive on cipher suites breaks the names down.
Asymmetric: RSA and ECC
RSA certificates use keys of at least 2048 bits. ECC achieves comparable security with far smaller keys — the CA/Browser Forum permits the NIST P-256, P-384, and P-521 curves, and a P-256 key is roughly equivalent in strength to RSA-3072 while being faster to compute. Elliptic curves also power ECDSA (signatures) and ECDHE (the ephemeral key exchange). If you're choosing for your next CSR, see ECC vs RSA.
One practical note: the certificate you buy or generate carries the asymmetric public key (RSA or ECC). The symmetric key is never in the certificate — it's generated fresh for each session and thrown away when the session ends.
What quantum computing changes
The two families face very different futures under quantum computing, and the split is worth understanding. A large enough quantum computer running Shor's algorithm would break today's asymmetric systems — RSA and elliptic curves alike — because their security rests on problems (factoring, discrete logarithms) that quantum machines solve efficiently. Symmetric encryption like AES is far more resilient: the best known quantum attack only halves its effective strength, so AES-256 still offers a robust margin.
That's why the post-quantum transition is concentrated on the asymmetric half — the key exchange in particular. Both Chrome and Firefox now enable a hybrid key exchange, X25519MLKEM768, by default: it runs the classical X25519 elliptic-curve exchange alongside the post-quantum ML-KEM-768 algorithm and combines both outputs, so the connection stays secure even if one of them is later broken. The symmetric AES that protects the traffic afterward needs no such overhaul. Our guide to post-quantum cryptography covers where this is heading.
Frequently Asked Questions
Answers to common questions about certificates and our services.
What is the difference between symmetric and asymmetric encryption?
Symmetric encryption uses one shared secret key to both encrypt and decrypt data — the same key on both ends. Asymmetric encryption uses a mathematically linked pair of keys: a public key that anyone can hold and a private key that stays secret, where data scrambled with one key can only be undone with the other. The practical consequence is how the keys are handled. Symmetric is fast and ideal for encrypting large amounts of data, but it leaves you with the problem of getting that one shared key to the other party without an eavesdropper grabbing it. Asymmetric is slower and works on small payloads, but it solves key distribution: you can publish your public key to the world without weakening the private one. TLS uses asymmetric techniques to safely agree on a symmetric key, then switches to symmetric encryption for the actual conversation.
Is symmetric or asymmetric encryption more secure?
Neither is inherently more secure — they solve different problems, and a strong implementation of either resists attack. At comparable, properly chosen key sizes, AES-256 (symmetric) and an ephemeral elliptic-curve exchange backed by a 2048-bit RSA or P-256 certificate (asymmetric) are both considered secure against classical computers today. The risk in real systems almost never comes from the math being broken; it comes from how keys are generated, stored, and exchanged. Asymmetric encryption's advantage is not stronger ciphertext but safer key distribution — you never have to transmit the secret half. That is exactly why TLS pairs them rather than choosing one.
Why does HTTPS use both symmetric and asymmetric encryption?
Because each covers the other's weakness. Asymmetric encryption can safely bootstrap a connection between two parties that have never met — no pre-shared secret required — but it is computationally expensive and impractical for encrypting an entire web page, video stream, or file upload. Symmetric encryption is fast enough to encrypt unlimited data with negligible overhead, but it needs both sides to already share the same secret key. TLS combines them: it uses an asymmetric key exchange (in TLS 1.3, an ephemeral Diffie-Hellman exchange authenticated by the server's certificate) to let both sides derive the same symmetric session key, then encrypts all the real traffic with that fast symmetric key. You get asymmetric's safe setup and symmetric's speed in one connection.
Is AES symmetric or asymmetric?
AES (the Advanced Encryption Standard) is a symmetric algorithm: the same key encrypts and decrypts, and it is the workhorse that protects the bulk of HTTPS traffic. In TLS 1.3 it appears inside AEAD cipher suites such as TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. RSA and ECC, by contrast, are asymmetric: RSA uses a public/private key pair, and ECC (elliptic-curve cryptography) underpins both ECDSA signatures and the ECDHE key exchange. A single TLS connection typically uses an asymmetric algorithm to set things up and AES to do the heavy lifting.
Can asymmetric encryption replace symmetric encryption entirely?
In principle you could encrypt everything asymmetrically, but in practice it would be far too slow and is never done that way. Asymmetric operations are orders of magnitude more expensive than symmetric ones and are designed for small inputs — a key, a hash, a signature — not megabytes of page content or streaming media. That is why every mainstream secure protocol, TLS included, uses asymmetric cryptography only to authenticate the parties and establish a shared secret, then hands the actual data encryption to a symmetric cipher. The two are complements, not competitors.
Does the SSL certificate contain a symmetric or asymmetric key?
An SSL/TLS certificate contains the public half of an asymmetric key pair — never a symmetric key, and never the private key. The certificate binds that public key to a verified domain name and is signed by a certificate authority. During the handshake the public key (and the certificate's signature) is used to authenticate the server and help establish a fresh symmetric session key. The matching private key stays on your server and is never sent anywhere; the symmetric session key is generated per connection and discarded when the session ends.
The bottom line
Symmetric and asymmetric encryption aren't rivals — they're a partnership. Asymmetric cryptography solves the introduction problem (authenticating a stranger and agreeing on a secret without sharing it), and symmetric cryptography does the fast, heavy work of encrypting the conversation. Every HTTPS connection you make uses both, dozens of times a day, without you noticing. To go deeper, start with how SSL works or, when you're ready to secure your own site, our guide to which SSL certificate you need.