AES vs RSA: When to Use Symmetric vs Asymmetric Encryption

AES and RSA are both encryption algorithms, but they solve different problems. You need to understand both — not to choose one over the other, but because real-world systems use them together: RSA to exchange a key, AES to encrypt the actual data. TLS, PGP, and SSH all work this way.

AES — symmetric encryption

AES (Advanced Encryption Standard) is a symmetric cipher: the same key is used to encrypt and decrypt. It operates on fixed-size 128-bit blocks using key sizes of 128, 192, or 256 bits. AES-256 is the current gold standard for data-at-rest encryption.

• Speed — extremely fast, hardware-accelerated on modern CPUs (AES-NI instructions). Can encrypt gigabytes per second.
• Key size — 128, 192, or 256 bits. AES-256 provides 2²⁵⁶ possible keys — computationally unbreakable.
• Modes of operation — the mode determines how blocks are chained. Use GCM (Galois/Counter Mode) for authenticated encryption. Avoid ECB (Electronic Codebook) — it leaks patterns.
• The problem — both parties must share the same secret key. How do you securely exchange it with someone you have never met before?

RSA — asymmetric encryption

RSA is an asymmetric cipher: it uses a key pair — a public key that anyone can have, and a private key that only you hold. Data encrypted with the public key can only be decrypted with the private key.

• Speed — slow. RSA-2048 encryption is roughly 1000× slower than AES-256. Never use RSA to encrypt large payloads directly.
• Key size — 2048-bit minimum (4096-bit for long-lived keys). The security comes from the difficulty of factoring large integers.
• What it solves — the key distribution problem. You can publish your RSA public key anywhere. Anyone can encrypt a message that only your private key can read.
• Signatures — RSA works in reverse for signing: you sign with the private key, anyone with the public key can verify. This is how code signing, SSL certificates, and JWT RS256 work.

Side-by-side comparison

How TLS combines both

TLS (the protocol behind HTTPS) uses RSA (or Elliptic Curve Diffie-Hellman) to establish a shared secret, then switches to AES for the actual data transfer. This is called a hybrid encryption scheme:

1. The server sends its RSA public key (in its SSL certificate)
2. The client generates a random AES session key
3. The client encrypts the session key with the server's RSA public key and sends it
4. The server decrypts the session key with its RSA private key
5. Both parties now share a secret AES key — all further communication is AES-encrypted

RSA secures the key exchange; AES handles the fast bulk encryption. Neither could replace the other in this flow.

Modern alternatives to RSA

RSA is being phased out in favour of Elliptic Curve Cryptography (ECC). A 256-bit ECC key provides equivalent security to a 3072-bit RSA key, with much smaller key sizes and faster operations. Specifically:

• ECDH (Elliptic Curve Diffie-Hellman) — replaces RSA for key exchange in TLS 1.3
• Ed25519 — replaces RSA for signatures (SSH keys, JWT EdDSA)
• X25519 — replaces RSA for key encapsulation in modern protocols

AES-256-GCM remains the standard for symmetric encryption regardless of which asymmetric algorithm you choose.

When to use each

• Use AES-256-GCM when encrypting files, database fields, or any data where both sides already share a key (e.g. a password-derived key)
• Use RSA or ECDH when you need to establish a shared secret with a party you have no pre-shared key with
• Use RSA or Ed25519 signatures when you need to prove authenticity without sharing a secret (code signing, JWTs, API request signing)
• Never use RSA directly for bulk data — it will fail or produce insecure output for payloads over ~245 bytes