Understanding JWE: How RSA and AES Work Together

Introduction

JWE (JSON Web Encryption) is a standard for encrypting sensitive data in a structured, cryptographically sound way. The magic lies in understanding why we use two different encryption algorithms together: RSA (asymmetric) and AES (symmetric). This note explores the reasoning and mechanics.

The Core Problem

We want to send encrypted data securely, but we face a classic tradeoff:

Algorithm	Strength	Weakness
AES (Symmetric)	Fast, efficient for large messages	Both parties need the same secret key
RSA (Asymmetric)	Public key encryption — no shared secret needed	Slow for large messages

The solution? Use both. This is called Hybrid Encryption.

The Hybrid Encryption Strategy

Why This Design?

AES encrypts the actual message — it's symmetric and blazingly fast
- Used for large payloads
- Requires a key (CEK: Content Encryption Key)
RSA encrypts the AES key — it's asymmetric, slow but solves the key distribution problem
- Public key can be shared openly
- Only the private key holder can decrypt the AES key

The Trade-off

RSA for large messages? ❌ Slow, impractical
AES for key exchange? ❌ Both parties need to know the key first
Hybrid approach? ✅ Best of both worlds

JWE: The 5-Part Structure

A complete JWE packet has this structure:

Header.EncryptedKey.IV.Ciphertext.Tag

Let's understand each part:

Part-by-Part Breakdown

1. Header

Contains metadata about the encryption:

alg: Algorithm used (e.g., RSA-OAEP)
enc: Encryption method (e.g., AES-256-GCM)
kty: Key type (RSA)
kid: Key ID (which public key was used)
use: Purpose (enc for encryption, sig for signature)

{
  "alg": "RSA-OAEP",
  "enc": "A256GCM",
  "kty": "RSA",
  "kid": "key-id-1",
  "use": "enc"
}

2. Encrypted Key

A random AES key (CEK) is generated
This key is encrypted with the receiver's public RSA key
Only the receiver's private key can decrypt it
Problem: High dependency on private key security

3. IV (Initialization Vector)

Random bytes used as a salt in AES-GCM
Prevents the same message from producing the same ciphertext
Ensures identical messages encrypted twice look completely different

4. Ciphertext

The actual encrypted message
Produced by AES-GCM encryption
Only readable if you have the decrypted AES key

5. Authentication Tag

A cryptographic fingerprint (GHASH algorithm)
Proves the ciphertext hasn't been tampered with
Detects man-in-the-middle attacks

The Encryption Flow (Visual)

AES-GCM: Authenticated Encryption

AES-GCM = AES encryption + GHASH authentication

GCM Mode: Galois/Counter Mode — ensures both confidentiality and authenticity
Tag: A cryptographic fingerprint created by GHASH
Why needed?: Proves the message wasn't altered in transit

Key Security Concepts

🔓 The Private Key Problem

Reality Check: Depending entirely on private key security is a single point of failure.

🔑 JWK (JSON Web Key) & OAuth

When OAuth/OIDC services share their public keys via JWK endpoints:

They publish the public key (safe to share)
They keep the private key (secret)
Anyone can verify tokens but only they can create them

Common Questions Answered

Q1: Why does encryption happen with public key if PE (presumably "protocol endpoint") passes JWKs?

The public key in JWK is used to encrypt the AES key. The private key (held privately by the service) is used to decrypt it. JWK endpoints are meant to be public.

Q2: Why not just use RSA for everything?

RSA is slow. For a 1MB message, RSA encryption would be impractical. AES is 1000x faster.

Q3: Which is better — RSA or AES?

Use Case	Winner	Reason
Large message encryption	AES	Speed
Key exchange without shared secret	RSA	No pre-shared key needed
Combined (hybrid)	Both	Best of both worlds

Q4: When and why to use JWE?

Use JWE when:

You need to encrypt sensitive data (passwords, tokens, PII)
Data must be transmitted over untrusted channels
You need both confidentiality and authenticity
You want a standard, interoperable encryption format

Skip JWE if:

You're already using TLS/HTTPS (it handles encryption)
Data doesn't need encryption beyond transport security

The Complete Picture

Key Takeaways

Hybrid Encryption = RSA (slow, key exchange) + AES (fast, payload encryption)
JWE standardizes this pattern with 5 parts: Header.EncryptedKey.IV.Ciphertext.Tag
AES-GCM ensures both confidentiality and integrity
RSA public key is safe to share; private key is the crown jewel
Use JWE for application-level encryption; TLS handles transport security

Understanding JWE: How RSA and AES Work Together

Introduction

The Core Problem