Symmetric vs asymmetric encryption: what is the difference?

There are two families of encryption, and almost every secure connection uses both. Symmetric encryption uses one shared secret key. Asymmetric encryption, also called public-key encryption, uses a pair of keys: one public and one private. This guide explains how each works, where each is used and why HTTPS, messaging apps and encrypted email combine them. For a gentler start, read How does public-key encryption work?.

At a glance

	Symmetric	Asymmetric (public-key)
Keys	One secret key shared by both sides	A key pair: a public key for everyone, a private key kept secret
Speed	Very fast, suited to large amounts of data	Much slower, used for small pieces of data
Main problem	How to share the key safely	How to know a public key really belongs to someone
Typical algorithms	AES, ChaCha20	RSA, elliptic-curve (ECDH, ECDSA, Ed25519)
Typical key size	128 or 256 bits	RSA 2048–4096 bits; elliptic curves 256 bits
Used for	Encrypting files, disks, the data in a connection	Key exchange, digital signatures, identity

How symmetric encryption works

With symmetric encryption, the same key locks and unlocks the data. Alice encrypts a file with the key, and Bob, who has the same key, decrypts it. Modern algorithms such as AES (the Advanced Encryption Standard) and ChaCha20 do this extremely fast. Many processors have built-in AES instructions, so encrypting a whole disk or a video stream barely affects performance.

A 256-bit key has 2²⁵⁶ possible values, far too many to try one by one with any foreseeable computer. In practice, attacks target how the key is stored or shared, not the mathematics.

That is the weakness: both sides need the same secret. If Alice and Bob have never met, how does Alice send Bob the key without someone copying it on the way? With a thousand users, each pair would need its own key, which is almost half a million keys. Symmetric encryption alone does not scale to strangers on the internet.

How asymmetric encryption works

Public-key cryptography, published in the 1970s by Diffie and Hellman and then by Rivest, Shamir and Adleman (RSA), solved the key-sharing problem. Each person creates a key pair. The two keys are mathematically linked, but you cannot work out the private key from the public one.

• Anyone can encrypt a message with Bob’s public key, but only Bob’s private key can decrypt it.
• Bob can sign data with his private key, and anyone can check the signature with his public key. This proves the data came from Bob and was not changed.

Bob can publish his public key on a website or in a directory, and nothing bad happens. There is no secret to deliver. The cost is speed. Asymmetric operations are hundreds to thousands of times slower than symmetric ones, and RSA can only encrypt a message shorter than its key. That is why asymmetric encryption is rarely used for the actual data.

Hybrid encryption: how real systems combine both

Real protocols use asymmetric cryptography to agree on a symmetric key, and then use that key for everything else:

1. The two sides run a key exchange, usually elliptic-curve Diffie–Hellman (ECDHE). Each side combines its own private value with the other side’s public value and gets the same shared secret. The secret itself never travels over the network.
2. The server proves its identity with a digital signature made by its private key. A certificate ties that key to the domain name.
3. Both sides turn the shared secret into symmetric session keys.
4. All the data, including pages, passwords and files, is encrypted with fast symmetric encryption such as AES-GCM or ChaCha20-Poly1305.

This is roughly what happens in TLS 1.3 every time you open an HTTPS site. The same pattern appears in Signal and WhatsApp, in SSH and VPNs, and in PGP email, where a random symmetric key encrypts the message and the recipient’s public key encrypts that key.

Forward secrecy

Modern key exchanges create fresh, temporary (“ephemeral”) keys for every session and throw them away afterwards. Suppose a server’s long-term private key is stolen years later. The attacker still cannot decrypt old recorded sessions, because the session keys no longer exist anywhere. This property is called forward secrecy, and TLS 1.3 requires it.

The trust problem in public-key systems

Public keys solve secrecy but create a new question: is this really Bob’s key, or an attacker’s? There are three common answers:

• Certificate authorities (the web). A trusted organisation signs a certificate that links a key to a domain name.
• Trust on first use (SSH). Your computer remembers a server’s key the first time and warns you if it ever changes.
• Manual verification (messaging apps). You compare a “safety number” or QR code with the other person in person or by phone.

What about quantum computers?

A large enough quantum computer could break today’s RSA and elliptic-curve algorithms. It would only weaken symmetric algorithms, and a 256-bit AES key remains strong. Standards bodies have therefore published post-quantum public-key algorithms. In 2024, NIST standardised ML-KEM for key exchange and ML-DSA for signatures. Browsers and messaging apps already use hybrid key exchanges that combine a classic algorithm with a post-quantum one.

Which one should you use?

As a user, you usually do not choose. Your browser, operating system and apps do it for you. As a developer, do not build either from scratch. Use well-reviewed libraries and protocols: TLS for connections, libsodium or the platform’s crypto API for data, and age or GPG for files. Encrypting stored data with a symmetric key (for example AES-256-GCM) is common. When you need to share data with people or systems you cannot meet in advance, you also need public keys.

Summary

Symmetric encryption is fast but needs a shared secret. Asymmetric encryption removes the need to share a secret and adds signatures, but it is slow. Secure systems use public keys to agree on a symmetric key and confirm identity, then switch to symmetric encryption for the data.