Symmetric vs Asymmetric Encryption Explained (2026)

One key or two: the 60-second version

Symmetric encryption is the padlock everyone shares an identical key to: the ICO describes it plainly as a secret key used to encode data, where anyone holding that same key can decode it again. Encrypt with the key, decrypt with the same key — one secret, two directions.

Asymmetric encryption replaces that single shared key with a mathematically linked pair: a public key anyone can hold, and a private key only one party ever holds. The ICO's own worked scenario for encrypted email is a good test case — it notes a user must first generate a key pair before they can send encrypted email at all. Think of the public key as a padlock you can hand out to strangers to click shut; only the matching private key opens it again.

If symmetric is faster and effectively uncrackable, why bother with asymmetric at all?

This is the question most explainers skip. Symmetric ciphers really are the faster, simpler tool — but they carry a bootstrap problem: both sides need the identical secret key before a single byte of protected traffic can move. Over the open internet there is no existing secure channel to hand that key across on. Send it in plain sight and anyone watching the wire copies it and reads everything that follows.

Asymmetric cryptography exists specifically to solve that bootstrap problem, not to replace symmetric encryption. Key-agreement protocols such as Diffie–Hellman or ECDH allow parties to derive a shared secret without transmitting that secret directly. That is the entire reason real systems never have to pick one scheme over the other: asymmetric cryptography runs briefly, once, to establish trust and agree a key; symmetric cryptography then carries every subsequent byte of data, because it is dramatically cheaper to run at volume.

Inside symmetric encryption: one key, maximum speed

Modern symmetric encryption protects the bulk of internet traffic, disk volumes and database fields because it is computationally light — this is the layer that has to run on every packet, every file write, every backup job, so it has to stay cheap. The cited guidance places algorithms providing 256-bit cryptographic strength for hashing and bulk encryption in its highest stated security category, including against a cryptographically relevant quantum computer. This rating applies to 256-bit hashing and bulk-encryption algorithms specifically, not a blanket guarantee that any given 256-bit implementation is quantum-safe.

Hash functions provide one-way digests; message authentication normally requires a MAC, digital signature or authenticated-encryption tag. Treat the guidance’s hashing-strength recommendation separately from bulk-encryption strength — readers who want to see this mechanic directly can experiment with a cryptographic hash generator. Symmetric encryption's one real limitation is the one described above: it has no built-in way to get the shared key to the other party safely. Everything downstream in enterprise architecture — TLS, envelope encryption, key management services — exists to manage that single limitation.

Inside asymmetric encryption: public keys, private keys and digital signatures

Asymmetric cryptography performs distinct cryptographic roles that must not be conflated: public-key encryption, key agreement, digital signatures and authentication. Direct asymmetric encryption encrypts data to a recipient's public key so that only their private key can decrypt it. Key agreement, by contrast, allows two parties (such as via Diffie-Hellman or ECDH) to combine public and private key material across an insecure channel to derive a shared secret without either party transmitting that secret directly. Digital signatures use a private key to sign data or a challenge, allowing anyone holding the corresponding public key to verify identity and message integrity. In TLS 1.3, this distinction is fundamental: public-key encryption is not used for bulk data transfer; instead, the connection relies on certificate-based digital signatures for authentication and ephemeral key agreement to establish shared session keys. TLS 1.3 uses ephemeral key exchange rather than legacy RSA key transport, providing forward secrecy in standard handshakes.

Two mathematical families traditionally deliver these capabilities: schemes built on the difficulty of factoring very large numbers (such as RSA), and schemes built on elliptic-curve point mathematics. Elliptic-curve schemes generally achieve comparable security with smaller public keys than traditional RSA, which makes them attractive for modern TLS key exchange. The hybrid mechanisms identified as examples by the guidance — including X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 — pair elliptic-curve key exchange with a post-quantum key-encapsulation mechanism. The cited Dutch TLS guidance lists these as hybrid examples and notes that quantum-safe alternatives were not yet part of TLS standards at publication; verify current protocol, library and interoperability support before deployment.

The hybrid reality: how TLS 1.3 and cloud key management actually work

The ICO states plainly that HTTPS is simply HTTP combined with TLS, delivering encrypted communication and secure identification of the server. In a typical certificate-authenticated TLS 1.3 connection, the client and server perform ephemeral key agreement, authenticate the server, derive traffic secrets and then use symmetric AEAD for application data. The ICO recommends TLS 1.2 or above for transmitting personal data, prefers TLS 1.3 where possible, and says not to use SSL; this is guidance on appropriate security rather than a blanket statutory TLS-version requirement. Anyone can inspect a given deployment's certificate chain and protocol version with an SSL certificate checker before trusting it.

Cloud platforms apply a similar hybrid division of labour to stored data through envelope encryption. Envelope-encryption designs commonly use a symmetric DEK for bulk data and wrap it with a KMS or HSM-protected key; implementations should be checked for their plaintext-key handling and lifecycle guarantees. The asymmetric or tightly-access-controlled master key never touches the bulk data directly; it only ever protects the small key that does, combining the computational speed of symmetric ciphers with granular access control.

Hands-on: generating and using both key types with OpenSSL 3.x

Because OpenSSL 3.x's command-line enc utility does not support AEAD ciphers like AES-GCM, authenticated encryption in practice is handled via supported AEAD workflows such as OpenSSL cms or dedicated application/library APIs. Using OpenSSL CMS with an authenticated cipher, an encrypted envelope can be created with: openssl cms -encrypt -aes-256-gcm -in payload.txt -out payload.msg -recip cert.pem, or handled programmatically via dedicated AEAD library calls. In symmetric encryption, the process generally adds modest, fixed per-message overhead, such as a nonce/IV and authentication tag, rather than overhead that is independent of the complete file format.

Generating asymmetric key pairs requires selecting the appropriate algorithm for the intended role: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out rsa_private.pem generates an RSA key pair, followed by openssl pkey -pubout -in rsa_private.pem -out rsa_public.pem to extract the public half. Direct public-key encryption with openssl pkeyutl -encrypt -pubin -inkey rsa_public.pem -pkeyopt rsa_padding_mode:oaep -in sessionkey.bin -out sessionkey.enc applies specifically to the RSA key pair using RSA-OAEP; it accepts only limited plaintext sizes determined by the modulus and hash, and produces ciphertext fixed to the key size. Standard elliptic-curve keys do not support direct encryption via pkeyutl -encrypt; instead, EC keys generated with openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ec_private.pem are used for signatures or key agreement. For example, deriving a shared secret between an EC private key and a peer's public key is performed with: openssl pkeyutl -derive -inkey ec_private.pem -peerkey peer_public.pem -out shared_secret.bin, showing how endpoints agree shared secrets without asymmetric bulk encryption.

The quantum threat: why only half of this pair is actually breaking

Quantum migration primarily affects widely used public-key key exchange and signature systems; symmetric encryption and hashing face a different, generally less severe search-speedup threat, with the cited guidance placing 256-bit-strength choices in its highest category. Shor's algorithm is the reason asymmetric cryptography is under genuine threat: it solves the factoring and discrete-logarithm problems that RSA, Diffie-Hellman and elliptic-curve schemes all rely on, efficiently enough that a sufficiently capable quantum computer would effectively crack them. That is precisely the finding behind the Dutch National Cyber Security Centre's TLS guidance, which states that common asymmetric cryptography used for authentication and key exchange is vulnerable to being effectively cracked by a cryptographically relevant quantum computer. The guidance notes that all algorithms in its quantum-threat table were currently sufficient for protection, but quantum-safe alternatives were not yet part of TLS standards at publication.

Grover's algorithm, by contrast, only offers a quadratic speed-up against brute-force key search rather than breaking the underlying mathematics of symmetric ciphers. This is why, as noted above, 256-bit cryptographic strength retains the guidance's highest security rating against quantum search. To counter asymmetric exposure, the guidance identifies hybrid key-exchange mechanisms—such as X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024—combining ECDHE with ML-KEM. However, because these quantum-safe alternatives were described as not yet part of formal TLS standards at publication, organisations must verify standards, library and deployment support before implementation rather than assuming immediate universal interoperability. Readers planning that migration should see our dedicated post-quantum cryptography roadmap, because the ICO's current encryption guidance explicitly does not cover quantum impact.

UK compliance anchor: ICO, UK GDPR and picking the right tool

UK GDPR does not specifically mandate blanket encryption of all personal information. The ICO is explicit that UK GDPR requires appropriate security and identifies encryption as one example of an appropriate technical measure. As noted above, its recommendation of TLS 1.2 or above (preferring TLS 1.3 and barring SSL) represents guidance on appropriate security rather than a statutory version mandate. Concurrently, the ICO recommends HTTPS across all website pages, even those without private content, sign-in functions or payment details. The ICO also recommends encryption for personal data in electronic transit, on PCs, laptops, smartphones and tablets, and on removable media, noting that controllers and processors remain responsible for personal data processing when they manage the encryption keys themselves.

Translating that into an engineering decision: use asymmetric cryptography directly in application code for narrow, low-volume jobs — signing a webhook payload, authenticating a client certificate, or deriving shared secrets. Delegate everything high-volume — database fields, object storage, backups, log encryption — to a symmetric data encryption key wrapped by a key management service or HSM, because that is the only pattern that scales without repeatedly hitting asymmetric cryptography's payload-size ceiling. Teams building this out for a UK estate can pair that architecture with wider enterprise cyber security solutions rather than treating key management as a bolt-on afterthought.

• •Use asymmetric directly for: certificate-based authentication, digital signatures, one-off key exchange with a new counterparty
• •Delegate to a symmetric DEK wrapped by KMS/HSM for: bulk file encryption, database fields, backups, high-volume data at rest
• •Recommended transport per ICO: TLS 1.2 or above for personal data (TLS 1.3 preferred, SSL prohibited), reflecting guidance on appropriate security rather than a statutory mandate, as noted above
• •Treat quantum migration as a separate project layered on top of today's TLS 1.3/AES-256 baseline, not a reason to delay it

Sources

Every figure in this article traces to the sources below.

• •ICO — UK GDPR encryption guidance (definitions, algorithm/key-size advice)
• •ICO — encryption scenarios (key pairs for encrypted email)
• •ICO — encryption and data transfer (HTTPS/TLS recommendations)
• •ICO — encryption and data protection (UK GDPR appropriate measures)
• •ICO — encryption guidance PDF (TLS 1.2/1.3, controller responsibility)
• •ICO — about this guidance (scope excludes quantum computing)
• •National Cyber Security Centre (Netherlands) — TLS security guidelines, quantum-threat and hybrid key-exchange detail