Asymmetric Encryption — RSA, ECDSA, and Key Pairs

You want to encrypt a message so that only one specific person can read it — and you have never met them. No pre-shared secret exists. No secure channel to exchange a key. Just the open, hostile internet between you.

This is the situation every browser faces when connecting to a server for the first time. It is the situation every kubectl command faces when talking to the API server. It is the situation cert-manager faces when proving your domain ownership to Let's Encrypt.

Symmetric encryption cannot solve this. You need a fundamentally different approach — one where the key used to encrypt is different from the key used to decrypt.

---

Part 1: The Key Pair Concept

Asymmetric encryption uses two mathematically linked keys:

• Public key — share with everyone. Used to encrypt data or verify signatures.
• Private key — keep secret. Used to decrypt data or create signatures.

What one key encrypts, only the other can decrypt. The public key cannot decrypt its own ciphertext. The private key cannot be derived from the public key (with current technology and key sizes).

Encryption:   plaintext + public_key  → ciphertext
Decryption:   ciphertext + private_key → plaintext

Signing:      message + private_key → signature
Verification: message + signature + public_key → valid/invalid

This solves the key distribution problem from Lesson 1. Alice publishes her public key. Bob encrypts a message with it. Only Alice's private key can decrypt it. Eve can intercept the public key, the ciphertext, and everything else on the wire — and still cannot read the message.

Where You Already Use Asymmetric Encryption

As a Kubernetes engineer, you use asymmetric key pairs constantly:

System	Key Pair Usage
SSH	~/.ssh/id_ed25519 (private) + ~/.ssh/id_ed25519.pub (public)
TLS certificates	Certificate contains public key; private key stored separately
Kubernetes API server	Serves a TLS cert; clients verify with the CA's public key
cert-manager	Generates key pairs for each Certificate resource
Cosign (image signing)	Signs container images with private key; verification uses public key
GPG/age (secret encryption)	Encrypts Kubernetes Secrets for GitOps (SOPS, sealed-secrets)

---

Part 2: RSA — The Original Asymmetric Algorithm

RSA (Rivest-Shamir-Adleman, 1977) was the first practical asymmetric encryption algorithm. It is still widely used in TLS certificates, though it is being replaced by elliptic curve algorithms.

The Math (Simplified)

RSA's security rests on one mathematical fact: multiplying two large prime numbers is easy, but factoring the product back into those primes is computationally infeasible.

Key Generation (simplified):
1. Choose two large prime numbers: p and q
   p = 61, q = 53  (real RSA uses 1024-bit primes)

2. Compute n = p × q
   n = 61 × 53 = 3233

3. Compute the totient: φ(n) = (p-1)(q-1)
   φ(3233) = 60 × 52 = 3120

4. Choose public exponent e (commonly 65537)
   e = 17  (must be coprime to φ(n))

5. Compute private exponent d such that (d × e) mod φ(n) = 1
   d = 2753  (because 2753 × 17 = 46801, and 46801 mod 3120 = 1)

Public key:  (e=17, n=3233)    ← share this
Private key: (d=2753, n=3233)  ← keep this secret

Encryption: ciphertext = plaintext^e mod n
Decryption: plaintext = ciphertext^d mod n

The security of RSA depends entirely on key size — which determines how large those prime numbers are and how hard they are to factor.

RSA Key Sizes

Key Size	Security Bits	Status	Notes
1024-bit	~80	Broken	Factored in practice; never use
2048-bit	~112	Minimum	NIST minimum through 2030
3072-bit	~128	Recommended	Equivalent to AES-128
4096-bit	~152	High security	Slower; used for root CAs

# Generate a 4096-bit RSA key pair
openssl genrsa -out private.pem 4096

# Extract the public key
openssl rsa -in private.pem -pubout -out public.pem

# View key details
openssl rsa -in private.pem -text -noout | head -5
# RSA Private-Key: (4096 bit, 2 primes)
# modulus: (4096 bit)
# publicExponent: 65537 (0x10001)
# ...

# Check the size of an existing certificate's key
openssl x509 -in cert.pem -noout -text | grep "Public-Key"
# Public-Key: (2048 bit)

Why RSA Is Slow

RSA encryption and decryption involve modular exponentiation with very large numbers (2048 to 4096 bits). Even with optimized algorithms, this is roughly 1000x slower than AES for bulk data.

# Benchmark comparison: RSA vs AES
openssl speed rsa2048 aes-256-gcm

# RSA 2048-bit:
#   sign:    ~1000 operations/sec
#   verify:  ~30000 operations/sec

# AES-256-GCM:
#   ~9,600,000 KB/sec = ~9.6 GB/sec

---

Part 3: Elliptic Curve Cryptography — Smaller, Faster, Stronger

RSA's weakness is key size. To get 128 bits of security (equivalent to AES-128), you need a 3072-bit RSA key — that is 384 bytes just for the key. Elliptic Curve Cryptography (ECC) achieves the same security with dramatically smaller keys.

The Elliptic Curve Intuition

ECC is based on the algebraic structure of elliptic curves over finite fields. The equivalent "hard problem" is the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a point on the curve and the result of multiplying that point by a secret number, finding that secret number is computationally infeasible.

You do not need to understand the math. You need to understand the practical implications:

The key takeaway: 256-bit ECC provides the same security as 3072-bit RSA, with 12x smaller keys and 3-10x faster operations. This is why the industry is moving from RSA to ECC for TLS certificates.

The Curves That Matter

Not all elliptic curves are equal. In practice, you will encounter these:

Curve	Key Size	Security	Used By	Notes
P-256 (secp256r1)	256-bit	128-bit	TLS, AWS, most CAs	NIST standard; most widely supported
P-384 (secp384r1)	384-bit	192-bit	Government, high-security TLS	Required by CNSA Suite
X25519	256-bit	~128-bit	TLS 1.3 key exchange	Designed by Daniel Bernstein; fast, safe
Ed25519	256-bit	~128-bit	SSH, code signing	Signature algorithm; deterministic

# Generate an EC private key using P-256
openssl ecparam -genkey -name prime256v1 -noout -out ec-private.pem

# Extract the public key
openssl ec -in ec-private.pem -pubout -out ec-public.pem

# View key details
openssl ec -in ec-private.pem -text -noout
# ASN1 OID: prime256v1
# NIST CURVE: P-256

# Generate an Ed25519 key pair (for SSH)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
# Your public key: ssh-ed25519 AAAA... user@host

# cert-manager Certificate with ECDSA
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-tls-cert
spec:
  secretName: my-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - app.example.com
  privateKey:
    algorithm: ECDSA
    size: 256        # P-256 curve
    # For RSA, you would use:
    # algorithm: RSA
    # size: 2048

ECDSA vs Ed25519

Both are elliptic curve signature algorithms, but they differ in important ways:

ECDSA (Elliptic Curve Digital Signature Algorithm):

• Uses NIST curves (P-256, P-384)
• Requires a random nonce for each signature — if the nonce is bad, the private key leaks (this is how the PlayStation 3 signing key was recovered in 2010)
• Widely supported in TLS and X.509 certificates
• The standard choice for TLS certificates today

Ed25519 (Edwards-curve Digital Signature Algorithm):

• Uses Curve25519 (designed by Bernstein, not NIST)
• Deterministic — no random nonce needed, so no nonce-reuse vulnerability
• Faster than ECDSA for signing
• Used for SSH keys, code signing (cosign), and some newer protocols
• Not yet widely supported in X.509 certificates by CAs

---

Part 4: The Hybrid Approach — How TLS Actually Works

Neither symmetric nor asymmetric encryption alone solves all problems:

	Symmetric (AES)	Asymmetric (RSA/ECC)
Speed	Fast (10+ GB/s)	Slow (1000x slower)
Key distribution	Unsolved	Solved (public key)
Bulk encryption	Excellent	Impractical
Authentication	No (key is shared)	Yes (only private key holder)

TLS uses both — asymmetric encryption to solve the key distribution problem, then symmetric encryption for everything else:

What This Means for Kubernetes

Every TLS connection in your cluster follows this pattern:

• Ingress controller terminates TLS: ECDHE key exchange + AES-256-GCM data encryption
• mTLS in service mesh (Istio/Linkerd): both client and server present certificates, ECDHE exchange, AES-GCM data
• etcd communication: API server to etcd uses TLS with client certificates
• Webhook calls: API server to admission webhooks over TLS
• kubelet to API server: client certificate authentication + TLS

In every case, the certificate (asymmetric) authenticates the parties, and AES (symmetric) encrypts the data. Understanding both halves lets you debug TLS issues intelligently — is the problem with the certificate (authentication) or with the cipher negotiation (encryption)?

---

Part 5: Key Management in Practice

Protecting Private Keys

The security of asymmetric encryption depends entirely on keeping the private key private. Common mistakes:

# Check file permissions on your private key
ls -la /etc/ssl/private/server.key
# -rw------- 1 root root 1704 Jan 15 10:00 server.key
#  ^^^^^^^^^ Only root can read

# BAD: world-readable private key
# -rw-r--r-- 1 root root 1704 Jan 15 10:00 server.key
# Anyone on the system can read this key

# Kubernetes TLS Secret — contains both certificate and private key
apiVersion: v1
kind: Secret
metadata:
  name: my-tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded certificate>
  tls.key: <base64-encoded private key>  # This is the crown jewel

Key Rotation

Unlike symmetric keys (which can theoretically be used forever if not compromised), asymmetric keys should be rotated periodically:

• TLS certificates: 90 days (Let's Encrypt default) to 1 year (most CAs)
• SSH keys: annually or when team members leave
• Signing keys: depends on usage; high-value keys may use HSMs with no rotation

cert-manager automates TLS certificate rotation in Kubernetes — it watches for approaching expiry and renews automatically. This is one of the strongest arguments for using cert-manager: manual certificate rotation is error-prone and the number one cause of production TLS outages.

---

Key Concepts Summary

• Asymmetric encryption uses two keys: a public key (encrypt/verify) and a private key (decrypt/sign) — solves the key distribution problem
• RSA security is based on the difficulty of factoring large numbers — minimum 2048-bit keys, 3072-bit recommended
• Elliptic Curve Cryptography provides equivalent security with 12x smaller keys — P-256 (256-bit) matches RSA-3072
• ECDSA is the standard signature algorithm for TLS certificates — uses NIST curves, requires careful random nonce generation
• Ed25519 is a deterministic signature algorithm — no nonce-reuse risk, used for SSH keys and code signing
• Asymmetric encryption is 1000x slower than AES — impractical for bulk data, used only for key exchange and authentication
• TLS uses the hybrid approach: asymmetric crypto for the handshake (authentication + key exchange), symmetric crypto (AES-GCM) for data
• Private key security is paramount — restrictive file permissions, RBAC on Kubernetes Secrets, automated rotation with cert-manager

Common Mistakes

• Using RSA 1024-bit keys — these are broken and must be replaced immediately
• Storing private keys with world-readable permissions (0644 instead of 0600)
• Confusing encryption with signing — encryption uses the public key (confidentiality), signing uses the private key (authenticity)
• Choosing RSA over ECDSA for new certificates without reason — ECDSA is faster, smaller, and equally secure
• Forgetting to rotate keys and certificates — expired certificates are the number one cause of TLS outages
• Implementing ECDSA with a poor random number generator — a single bad nonce leaks the entire private key
• Assuming quantum computers break everything tomorrow — current quantum computers cannot break any real cryptographic key; plan for migration but do not panic

---