Symmetric vs asymmetric crypto in TLS: what each one does

In this article

1. Before you start
2. Why interviewers ask this
3. What each one is
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one part of the cyber security interview questions guide.

Why interviewers ask this

The question separates a candidate who memorised "TLS uses encryption" from one who knows which kind of cryptography does which job and why. A short answer to "symmetric or asymmetric?" is never enough, because the real design is a split of labour inside one protocol.

A weak answer says "asymmetric is more secure, so TLS uses it for everything" or "TLS encrypts data with the server's private key." A strong answer names the two jobs: asymmetric cryptography to agree keys and authenticate the server, symmetric encryption for the traffic.

A Staff-level answer adds the order of the TLS 1.3 handshake, why a longer key is not automatically stronger, why the secret is never sent, and what changes with quantum computers. Neighbouring topics such as JavaScript Object Notation (JSON) Web Token (JWT) questions and application security questions reuse the same split between shared-secret and public-key mechanisms. Role guides for security operations centre (SOC) analysts, threat intelligence analysts and identity and access management (IAM) analysts sit next to this topic.

What each one is

Symmetric encryption

Symmetric encryption is a method of scrambling data that uses the same secret key to encrypt and to decrypt, so both sides must hold that key and keep it private; it is the tool for protecting the bulk of the data in a connection.

Asymmetric cryptography

Asymmetric cryptography, also called public-key cryptography, is a method that uses a linked pair of keys, a public key that can be shared and a private key that stays secret, for encryption, digital signatures and key agreement. "Asymmetric encryption" names only the encryption use.

TLS handshake

A TLS handshake is the opening exchange of a TLS connection in which the client and the server agree on the protocol version and the cipher suites, authenticate the server and generate the session keys before any application data is protected.

Session key

A session key is a symmetric key created for one connection and used only for that session's traffic, so a new handshake produces new keys each time.

In plain words

Think of a padlock factory. Anyone can take an open padlock (the public key) and snap it shut on a box, but only the factory holds the key that opens it (the private key). That is asymmetric. A symmetric key is a single house key that you and a friend both own: whoever has it can lock and unlock. The analogy breaks in one place. A real public key is also used to check signatures, which a padlock cannot do.

In one precise sentence, symmetric cryptography uses one shared secret for both directions, and asymmetric cryptography uses two mathematically linked keys where knowing the public key does not reveal the private key.

Symmetric encryption: one shared key

Symmetric encryption uses one secret key for both encrypting and decrypting. The National Institute of Standards and Technology (NIST) says that symmetric-key algorithms "transform data in a way that is fundamentally difficult to undo without knowledge of a secret key," and that the key is "symmetric" because the same key is used for an operation and its inverse (NIST Special Publication (SP) 800-57 Part 1 Rev. 5, section 4.2). The same family also produces a message authentication code (MAC), a short tag that lets a receiver who holds the key check that a message was not altered.

The weakness is distribution: both sides need the key before they can talk, and over an open network they have no safe way to send it. That problem is what the other kind of cryptography solves.

Asymmetric cryptography: a public and a private key

Cloudflare describes asymmetric encryption as a public key and private key pairing in which data encrypted with the public key can only be decrypted with the private key. NIST adds that "knowledge of the public key cannot be used to determine the private key."

NIST lists two main uses. A digital signature is data computed with a private key that anyone holding the matching public key can verify, which proves source, identity and integrity. The second use is to establish keying material through key agreement or key transport. So asymmetric cryptography is not only "encrypt with the public key": it also signs, and in key agreement it encrypts nothing at all. In TLS 1.3 it signs and agrees keys, and encrypts nothing.

Why RSA keys are so much longer than AES keys

The two families use different mathematics, so an asymmetric key needs far more bits than a symmetric key for the same security strength. NIST's comparable-strength table pairs the Advanced Encryption Standard (AES) with Rivest–Shamir–Adleman (RSA) keys: at 128-bit strength, AES needs 128 key bits and RSA needs 3,072 (NIST SP 800-57 Part 1 Rev. 5, Table 2).

Key length is not the same as strength either. NIST notes that "the security strength is not necessarily the same as the length of the key due to attacks on those algorithms that provide computational advantages." A 3,072-bit RSA key therefore matches a 128-bit AES key (Table 2); it does not beat it. The worked example below puts numbers on the gap.

Side by side: what each one does in TLS

Symmetric encryption protects the traffic from the ServerHello message on. Asymmetric cryptography agrees the keys and signs the server's identity proof, once per handshake.

The choice follows the job. Use symmetric encryption when both sides already share a key. Use key agreement to set up a key with a stranger. Use a signature and a certificate to prove identity.

Text description of the diagram

• Use symmetric encryption when both sides already share a key.
• Use key agreement to set up a key with a stranger.
• Use a signature and a certificate to prove identity.

How one TLS connection uses both

TLS is designed "to prevent eavesdropping, tampering, and message forgery" (Request for Comments (RFC) 8446; the RFC Editor now marks it obsolete in favour of RFC 9846, the current standard, and the section numbers here refer to RFC 8446). Cloudflare lists what the handshake does: agree the version and cipher suites, authenticate the server through its public key and a certificate authority's digital signature, and generate session keys for symmetric encryption.

The order in TLS 1.3 is the one in the message flow of RFC 8446 section 2, which marks the encrypted messages. First, the ClientHello and ServerHello messages carry the key shares, the public values of a Diffie-Hellman key agreement. Both sides then derive handshake keys from the shared secret. Next, the server sends its Certificate and a CertificateVerify message, a signature over the handshake transcript; both already travel under symmetric encryption. Finished messages, each a keyed hash called a hash-based message authentication code (HMAC), confirm the handshake. Application traffic keys then protect the data.

So key agreement comes first, the server's signature is checked under handshake encryption, and application data then uses the traffic keys. Symmetric encryption therefore protects most of the handshake, and the asymmetric signature arrives after a symmetric key already exists. Each new session starts a new handshake and uses new session keys, a point also made on Cloudflare's asymmetric encryption page.

Text description of the diagram

• Key agreement comes first and handshake keys are derived from it.
• The server's signature is checked under handshake encryption.
• Application data then uses the traffic keys.

What TLS 1.3 actually uses, and why it gives forward secrecy

Forward secrecy is the property that recorded traffic stays unreadable even if a server's long-term private key is stolen later. RFC 8446 section 1.2 says: "Static RSA and Diffie-Hellman cipher suites have been removed; all public-key-based key exchange mechanisms now provide forward secrecy." That is why TLS 1.3 dropped RSA key transport.

The named pieces are these. Key agreement is an elliptic-curve Diffie-Hellman exchange with ephemeral keys, commonly over the X25519 curve. Signatures use the Elliptic Curve Digital Signature Algorithm (ECDSA), RSA-PSS (the RSA probabilistic signature scheme) or Ed25519 (RFC 8446 section 4.2.3). Record protection uses authenticated encryption with associated data (AEAD), an encryption mode that protects secrecy and detects tampering in one operation, such as AES in Galois/Counter Mode (GCM), written AES-GCM, or ChaCha20-Poly1305 (RFC 8446 section 5.2). An AEAD tag replaces the separate MAC of older versions.

Key transport and key agreement: two ways to share the secret

Key transport is a method in which the key is encrypted using the public key of the receiver and later decrypted with the receiver's private key, according to the NIST definition. Key agreement is a method in which both sides contribute information and compute the shared key "without actually sending the keying material."

Older TLS versions could use an RSA key exchange, which is key transport. Cloudflare says that RSA key exchange is now considered not secure and that TLS 1.3 does not support it. With an ephemeral Diffie-Hellman handshake the two sides compute a matching secret separately from the parameters they exchanged. An ephemeral key is a key generated for each execution of a cryptographic process such as key establishment, then discarded. In that handshake the server's private key signs the exchange but does not protect the session key; Cloudflare notes that not every handshake uses the private key to generate session keys.

Worked example

The key sizes below come from NIST's comparable-strength table; the ratios were computed by dividing the RSA key length by the strength in bits.¹ At 128-bit strength, RSA needs 3,072 bits against 128 for AES, a ratio of 24.¹

The 112-bit row names Triple DES (3TDEA) as Table 2 does; NIST has since disallowed it for applying encryption protection (SP 800-131A Rev. 2). At 256-bit strength, RSA needs 15,360 bits and AES needs 256 bits.¹ The chart shows the same gap for the three AES levels.

Text description of the diagram

• At 128-bit strength, RSA needs 3,072 bits and AES needs 128 bits.
• At 256-bit strength, RSA needs 15,360 bits and AES needs 256 bits.

The weakest part sets the strength. NIST states that "the strength of cryptographic protection is determined by the weakest algorithm and key size used" (section 5.6.2). Its example pairs the Secure Hash Algorithm (SHA) SHA-256 with a 2,048-bit RSA key and gives no more than 112 bits of security, the strength Table 2 assigns to RSA-2048. A 112-bit strength is acceptable through 2030 and disallowed for applying protection from 2031 (Table 4).

Trade-offs and edge cases

Asymmetric keys cost more. NIST notes that for public-key algorithms such as RSA, "larger keys may take longer to generate, require more memory and transmission bandwidth, and take longer to process data" (section 5.6.2). That is a main reason TLS runs the asymmetric steps once per connection and leaves the bulk of the data to a symmetric session key.

Secrecy is not authenticity. Encryption alone does not prove who is at the other end, which is why the handshake adds a certificate and a signature, and why TLS also detects tampering: the Cloudflare handshake page describes the checks that detect tampering.

Quantum computers mainly change the asymmetric side. NIST notes that Shor's algorithm on future quantum computers is projected to defeat the currently approved asymmetric algorithms (SP 800-57 Part 1 Rev. 5, section 4). Grover's algorithm weakens symmetric keys in theory, which is why the effect is mostly on the asymmetric side.

In August 2024 NIST published the Federal Information Processing Standard (FIPS) FIPS 203, which specifies a Module-Lattice-Based Key-Encapsulation Mechanism (KEM) named machine learning (ML)-KEM, built to resist quantum attacks, and its draft Interagency or Internal Report (IR) NIST IR 8547 (November 2024) addresses the transition away from quantum-vulnerable public-key algorithms. TLS deployments are adding hybrid key exchange, which pairs a classical exchange such as X25519 with ML-KEM so the session stays safe if either one holds. Reported practice differs on timing; this page does not state a migration date.

How to answer it in an interview

The spoken structure: say both are used, give key agreement first, then the signature, then the symmetric traffic keys and the reason for the split.

Common mistakes

• "TLS encrypts the traffic with the server's public and private keys." (wrong) The asymmetric keys serve the handshake. (right) "Symmetric session keys encrypt the traffic."
• "The asymmetric steps finish first, and only then does symmetric encryption start." (wrong) In TLS 1.3 handshake keys come from the key agreement, and the server's signature is checked under symmetric encryption. (right) "Key agreement comes first, then the signature, under handshake encryption."
• "Asymmetric is stronger, so it is the better choice." (wrong) Strength depends on algorithm and key size, and a 3,072-bit RSA key matches a 128-bit AES key (NIST Table 2). (right) "They do different jobs; compare them by security strength, not key length."
• "Every handshake uses the server's private key to protect the session key." (wrong) In an ephemeral Diffie-Hellman handshake the private key signs and the key comes from exchanged parameters. (right) "The private key authenticates; the session key is agreed, not sent."
• "Encryption alone secures the connection." (wrong) Without authentication you may be encrypting to an attacker. (right) "TLS authenticates the server and detects tampering as well."

Follow-up questions

Why does TLS use both symmetric and asymmetric encryption?

Asymmetric cryptography solves the problem of agreeing a secret and proving identity over an open network, and symmetric encryption protects the data once both sides share a key. Each does the job it is suited to, and larger public-key sizes make it costlier to use for everything.

Which is faster, symmetric or asymmetric?

Symmetric is faster. NIST notes that larger public-key sizes take longer to generate and to process data and need more memory and bandwidth (section 5.6.2), which is why TLS runs the asymmetric steps once per connection.

Is asymmetric encryption more secure than symmetric encryption?

No. Security strength depends on the algorithm and key size, and at 128-bit strength NIST pairs a 3,072-bit RSA key with a 128-bit AES key. Overall protection is limited by the weakest component.

Is TLS, RSA or AES symmetric or asymmetric?

TLS is a protocol that uses both kinds. RSA is asymmetric, and in TLS 1.3 it is used for signatures. AES is symmetric, and in TLS it protects the records, usually in an AEAD mode.

Does TLS 1.3 still use RSA?

TLS 1.3 removed RSA key transport: RFC 8446 section 1.2 says static RSA cipher suites have been removed, and Cloudflare likewise says TLS 1.3 does not support RSA key exchange. RSA signatures are still allowed, as the RSA-PSS schemes (rsa_pss_rsae_*) of section 4.2.3, so RSA certificates remain common.

Is public-key cryptography safe against quantum computers?

NIST projects that future quantum computers could defeat the currently approved asymmetric algorithms, so the algorithms in use today are not considered safe in the long run. New standards such as ML-KEM (FIPS 203) and hybrid key exchange address this. Signature-based designs such as JSON Web Token signing face the same transition, and the security guide collects the neighbouring topics.

Sources

1. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor (IETF); accessed 2026-10-26, page marks it obsolete in favour of RFC 9846, 10 Aug 2018
2. NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 - General — NIST (E. Barker); accessed 2026-10-26, 1 May 2020
3. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard — NIST; accessed 2026-10-26, 13 Aug 2024
4. NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards — NIST; accessed 2026-10-26, 12 Nov 2024
5. What Happens in a TLS Handshake? — Cloudflare Learning Center (undated page; the date shown is the access date), 26 Oct 2026
6. What is asymmetric encryption? — Cloudflare Learning Center (undated page; the date shown is the access date), 26 Oct 2026