TL;DR: Symmetric cryptography (AES-GCM, ChaCha20-Poly1305) uses one shared key; it is fast and protects bulk data, but both sides need the key first. Asymmetric cryptography (RSA, elliptic curves) uses a key pair; it is slow but solves key distribution through key exchange and signatures. Real protocols use both: asymmetric to authenticate the other side and agree on a fresh key, then symmetric to encrypt the data. TLS, SSH and Signal all follow this pattern.
How to approach it
Define both in one line each, then state their strengths and weaknesses side by side, and land on hybrid use with TLS as the example. Mention what makes the asymmetric step trustworthy (authentication) to show you know where attacks happen.
A strong answer
Key exchange
ECDHE, slow, small
Signature
proves who you talk to
Derive keys
HKDF
Bulk data
AES-GCM, fast
| Symmetric | Asymmetric | |
|---|---|---|
| Keys | One shared secret | Public key plus private key |
| Speed | Very fast, often hardware-accelerated | Orders of magnitude slower |
| Solves | Encrypting and authenticating data at volume | Agreeing on keys with strangers; proving identity |
| Hard part | Getting the key to both sides securely | Knowing a public key really belongs to its claimed owner |
| Examples | AES-GCM, ChaCha20-Poly1305, HMAC | X25519 / ECDHE, Ed25519, ECDSA, RSA |
Why both. Two parties who have never met cannot use symmetric encryption until they share a key, and they cannot send a key over a network an attacker watches. Asymmetric cryptography solves exactly that, but it is too slow and too constrained to encrypt large data. So protocols combine them:
- Authenticate the server (and optionally the client) with signatures and certificates.
- Agree on a session key with ephemeral Diffie-Hellman (ECDHE), which also gives forward secrecy.
- Encrypt all traffic with an AEAD cipher under that key.
In TLS 1.3 the handshake does steps 1 and 2 in one round trip, and the record layer does step 3. The same shape appears in encrypted storage: a data key (symmetric) encrypts the object, and that data key is wrapped by a key held in a KMS, sometimes an asymmetric one.
Where it fails. Key exchange without authentication is open to a man in the middle. Asymmetric schemes in use today (RSA and elliptic curves) are expected to be broken by large quantum computers, which is why hybrid post-quantum key exchange, X25519 combined with ML-KEM (NIST FIPS 203, 2024), is being deployed in TLS. Symmetric ciphers with 256-bit keys are not meaningfully threatened.
What interviewers probe next
- "Why not encrypt everything with RSA?" Slow, size-limited, and RSA key transport lacks forward secrecy; use it to set up a symmetric key instead.
- "How do you know the server's public key is real?" A certificate chain to a trusted root, checked including the hostname.
- "What changes with quantum computers?" Asymmetric key exchange and signatures need replacing; symmetric crypto mostly needs adequate key sizes.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Two services in different companies need to exchange confidential messages over the internet, and have never met or shared any secret.
Start here
Why not just use symmetric encryption?
How would they share the key?
Symmetric cryptography such as AES-GCM or ChaCha20-Poly1305 is fast and protects bulk data well, but both sides need the same key first. With no shared secret, they have no safe way to agree one over an untrusted network.
Carry it forwardSymmetric crypto needs a key already shared.
Weak answerEmailing a shared key.
Constraint changes
What does asymmetric cryptography solve?
Which operations need key pairs?
Key pairs let them do key exchange (agree a fresh secret over the network) and signatures (prove who they are). It is slow, so it is used for these small operations, not bulk data.
Carry it forwardAsymmetric crypto solves key exchange and authentication.
Weak answerEncrypting large data directly with RSA.
Constraint changes
How do real protocols combine them?
Which part encrypts the messages themselves?
Asymmetric crypto authenticates the other side and agrees a fresh key; symmetric crypto then encrypts the traffic. TLS works exactly this way.
Carry it forwardAsymmetric to agree, symmetric to encrypt.
Weak answerInventing a custom protocol.
Constraint changes
How does each side know the public key belongs to the other company?
What stops someone swapping the public key?
Through certificates from a trusted CA, or keys exchanged and verified out of band. Without authentication, an attacker in the middle can substitute their own key.
Carry it forwardPublic keys need authentication.
Weak answerTrusting a key fetched over an unauthenticated channel.
Constraint changes
What would you actually build?
Is there a standard protocol for this?
Mutual TLS with certificates each side can verify, or an established message format with signatures and encryption, using maintained libraries. Rolling your own combination is where most mistakes happen.
Carry it forwardUse standard protocols and libraries.
Weak answerCustom crypto designs.
Now defend it
What would you recommend?
Use mutual TLS (or a standard signed-and-encrypted message format) built on maintained libraries: certificates or out-of-band verified keys authenticate each side, ephemeral key exchange agrees fresh keys, and AEAD symmetric encryption protects the messages.
How it's scored
Weak: Says asymmetric is "more secure" or describes only one side.
Hire: Explains the trade-off and the hybrid pattern with TLS as the example.
Strong Hire: Adds authentication of the exchange, forward secrecy and the post-quantum direction, and applies the pattern beyond TLS (envelope encryption).
Common mistakes
- Claiming the data in TLS is "encrypted with the server's public key".
- Forgetting that key exchange needs authentication.
- Treating symmetric and asymmetric as alternatives rather than partners.