Encryption Basics — Public Keys, Private Keys & How HTTPS Works

A junior engineer on your team asks: "Why can we not just use HTTP? HTTPS is slower and the certs are annoying."

You pull up Wireshark on the office WiFi. You open a page over HTTP and filter the stream. There it is — the full request in plaintext. The URL, the cookies, the Authorization header with a Bearer token. Every byte, readable by anyone on the same network.

"That is why," you say. "Anyone between the client and server — on this WiFi, at the ISP, at the cloud provider — can read, modify, or inject data into an HTTP connection. HTTPS encrypts all of it."

But how does HTTPS actually work? That is what this lesson covers. By the end, you will understand the three types of encryption that make HTTPS possible, and why TLS needs all three of them working together.

---

Part 1: The Problem — HTTP Is Plaintext

HTTP sends everything in cleartext. When your browser makes an HTTP request, the data travels through multiple networks — your local WiFi, your ISP, backbone routers, the cloud provider's network — and at every hop, anyone with access to the wire can read the full content.

This is not theoretical. Here is what an HTTP request looks like captured in a packet analyzer:

GET /api/user/profile HTTP/1.1
Host: app.example.com
Cookie: session=eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0fQ.abc123
Authorization: Bearer sk-prod-abc123def456
Content-Type: application/json

Every header, every cookie, every token — visible to anyone sniffing the network. Now here is the same request over HTTPS:

17 03 03 00 5a 8c 2f 1e 3b a7 44 91 0c d3 f8 7a
b2 18 55 6f e3 7c 90 11 4d 22 a8 c1 5b 73 0e 69
f4 3a 8d 27 bb 60 ce 15 98 d6 42 af 1c 7e 53 b0

Encrypted gibberish. The eavesdropper sees the destination IP address and port, but the HTTP method, path, headers, cookies, body — all encrypted.

The attacks that HTTP enables are not exotic. They are well-documented and trivial to execute:

Attack	How It Works	HTTPS Prevents It?
Eavesdropping	Read all data in transit	Yes — data is encrypted
Session hijacking	Steal cookies from the wire	Yes — cookies are encrypted
Man-in-the-middle	Modify data between client and server	Yes — tampering is detected
Content injection	ISP injects ads into your pages	Yes — integrity is verified
Credential theft	Capture login credentials	Yes — credentials are encrypted

So HTTPS encrypts everything. But how? The answer involves three types of cryptography working together.

---

Part 2: Symmetric Encryption — One Key, Two Operations

Symmetric encryption is the simplest concept: you have one key that both encrypts and decrypts the data. Think of it as a padlock where the same key locks and unlocks.

# Symmetric encryption with AES-256 using OpenSSL
# Encrypt a file
openssl enc -aes-256-cbc -salt -in secret.txt -out secret.enc -pass pass:MySecretKey

# Decrypt it with the same key
openssl enc -aes-256-cbc -d -in secret.enc -out decrypted.txt -pass pass:MySecretKey

AES-256 (Advanced Encryption Standard with a 256-bit key) is the gold standard for symmetric encryption. It is used by TLS, banks, governments, and every encrypted hard drive on the planet.

Why AES-256 is the standard:

• Fast: hardware-accelerated on modern CPUs (AES-NI instructions) — 10+ GB/s throughput
• Proven: decades of cryptanalysis, no practical attacks found
• 256-bit key space: 2^256 possible keys — brute-forcing would take longer than the age of the universe

The Symmetric Key Problem

Symmetric encryption has one fatal flaw for internet communication: both sides need the same key. If your browser wants to talk securely to a server it has never communicated with before, how do you get the shared key to both sides?

You cannot send it over HTTP — anyone listening would see the key. You cannot pre-install keys for every website in every browser. You need a way to agree on a shared secret over an insecure channel.

This is the key exchange problem, and it is the reason symmetric encryption alone cannot secure the internet. You need asymmetric encryption to solve it.

---

Part 3: Asymmetric Encryption — Two Keys, Split Responsibilities

Asymmetric encryption uses two mathematically linked keys: a public key and a private key. They are generated together as a pair, and they have a special relationship:

• Public key encrypts → only the private key can decrypt
• Private key signs → the public key verifies the signature

The public key is safe to share with the entire world. The private key must never leave the server.

# Generate an RSA key pair (private + public)
openssl genrsa -out private.key 2048

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

# Encrypt with the public key
echo "Hello, secret world" | openssl rsautl -encrypt -pubin -inkey public.key -out message.enc

# Decrypt with the private key (only the private key holder can do this)
openssl rsautl -decrypt -inkey private.key -in message.enc
# Output: Hello, secret world

RSA vs ECDSA

The two main asymmetric algorithms you will encounter:

RSA (Rivest-Shamir-Adleman): The classic. Based on the difficulty of factoring large prime numbers. RSA-2048 is the minimum for security today. RSA-4096 is more conservative. Larger keys are slower.

ECDSA (Elliptic Curve Digital Signature Algorithm): The modern choice. Based on the difficulty of the elliptic curve discrete logarithm problem. ECDSA P-256 provides equivalent security to RSA-3072 but with much smaller keys (32 bytes vs 384 bytes). Faster to compute, smaller certificates.

# Generate an ECDSA key (much faster and smaller than RSA)
openssl ecparam -genkey -name prime256v1 -out ec-private.key

# Compare key sizes
wc -c private.key    # RSA-2048: ~1700 bytes
wc -c ec-private.key # ECDSA P-256: ~300 bytes

Digital Signatures — The Other Direction

Asymmetric cryptography works in both directions. Encryption uses the public key to encrypt data that only the private key can decrypt. Signatures work the other way:

1. Hash the data (e.g., SHA-256) to produce a fixed-size digest
2. Encrypt the hash with the private key — this is the signature
3. Anyone with the public key can decrypt the signature and compare it to their own hash of the data
4. If the hashes match: the data was signed by the private key holder and has not been tampered with

# Sign a file with a private key
openssl dgst -sha256 -sign private.key -out signature.bin document.txt

# Verify the signature with the public key
openssl dgst -sha256 -verify public.key -signature signature.bin document.txt
# Output: Verified OK

Digital signatures are everywhere in infrastructure:

• TLS certificates (the CA signs your cert with its private key)
• Docker image signing (ensuring images have not been tampered with)
• Git commit signing (git commit -S)
• Kubernetes admission webhooks (validating webhook signatures)

---

Part 4: The Hybrid Approach — How TLS Actually Works

Here is the core insight: TLS uses both symmetric and asymmetric encryption together. Neither one alone is sufficient.

• Asymmetric is secure for key exchange but too slow for bulk data (1000x slower than AES)
• Symmetric is fast for bulk data but cannot solve the key exchange problem

The solution is a hybrid approach:

1. Use asymmetric encryption to securely agree on a shared symmetric key
2. Then use the fast symmetric key for all actual data encryption
3. Use digital signatures to verify the server is who it claims to be

This hybrid approach gives you the best of all three worlds: secure key exchange (asymmetric), fast data encryption (symmetric), and server authentication (digital signatures).

---

Part 5: Diffie-Hellman Key Exchange — Agreeing on a Secret in Public

The Diffie-Hellman (DH) key exchange is one of the most elegant algorithms in computer science. It allows two parties to agree on a shared secret over an insecure channel, without ever transmitting the secret itself.

The Paint Mixing Analogy

The classic explanation uses paint colors:

1. Alice and Bob publicly agree on a shared color (yellow)
2. Alice picks a secret color (red) and mixes it with yellow — gets orange. Sends orange to Bob.
3. Bob picks a secret color (blue) and mixes it with yellow — gets green. Sends green to Alice.
4. Alice mixes her secret (red) with Bob's mix (green) — gets brown.
5. Bob mixes his secret (blue) with Alice's mix (orange) — gets the same brown.
6. An eavesdropper sees yellow, orange, and green — but cannot derive the secret colors or the final brown.

The mathematical version uses modular exponentiation instead of paint, but the principle is identical: you can combine partial results to arrive at the same shared secret without ever revealing your private input.

ECDHE — The Modern Version

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is the key exchange used in TLS 1.3. It is Diffie-Hellman but using elliptic curve math instead of large prime numbers, making it faster and more secure at smaller key sizes.

The Ephemeral part is critical: a new key pair is generated for every single TLS session. This provides forward secrecy.

# See which key exchange a server uses
openssl s_client -connect google.com:443 2>/dev/null | grep "Server Temp Key"
# Server Temp Key: X25519, 253 bits

# X25519 is an ECDHE variant — ephemeral, forward-secret

---

Part 6: Putting It All Together — How HTTPS Uses All Three

When your browser connects to https://devopsbeast.com, here is what happens at the cryptographic level:

1. ECDHE key exchange (asymmetric): browser and server agree on a shared secret without transmitting it
2. Certificate verification (digital signature): browser checks that the server certificate is signed by a trusted CA
3. AES-256-GCM encryption (symmetric): all HTTP data is encrypted with the derived session key

The cipher suite name tells you exactly which algorithms are used. For example: TLS_AES_256_GCM_SHA384 in TLS 1.3 means:

• AES-256-GCM: symmetric encryption algorithm for data
• SHA-384: hash algorithm for message integrity
• Key exchange is always ECDHE in TLS 1.3 (not listed because there is no alternative)

# See the full cipher negotiation
openssl s_client -connect devopsbeast.com:443 2>/dev/null | grep -E "Protocol|Cipher"
#     Protocol  : TLSv1.3
#     Cipher    : TLS_AES_256_GCM_SHA384

---

Key Concepts Summary

• HTTP is plaintext — anyone between client and server can read, modify, or inject data into the connection
• Symmetric encryption uses one shared key for both encrypting and decrypting (AES-256) — fast but has the key distribution problem
• Asymmetric encryption uses a public/private key pair — public encrypts, private decrypts — secure but 1000x slower than symmetric
• Digital signatures use the private key to sign and the public key to verify — proves authenticity and integrity
• TLS uses all three together: asymmetric for key exchange, symmetric for data encryption, signatures for authentication
• Diffie-Hellman solves the key exchange problem — two parties agree on a shared secret without ever transmitting it
• ECDHE is the modern, ephemeral version used in TLS 1.3 — provides forward secrecy by generating new keys per session
• Forward secrecy means stealing the server private key does not compromise past recorded sessions
• AES-NI hardware acceleration makes symmetric encryption essentially free on modern CPUs

Common Mistakes

• Thinking HTTPS only protects the request body — it encrypts the entire HTTP conversation including URLs, headers, and cookies
• Confusing encryption (public key encrypts) with signing (private key signs) — they use the same key pair but in opposite directions
• Believing asymmetric encryption is "more secure" than symmetric — both are secure, they solve different problems
• Assuming the server private key can decrypt recorded traffic — with forward secrecy (ECDHE), it cannot
• Rolling your own encryption instead of using TLS — even experts get this wrong, use battle-tested protocols
• Not checking for AES-NI hardware support on servers — without it, TLS has a measurable performance cost

---

What is Next

You now understand the three cryptographic building blocks: symmetric encryption, asymmetric encryption, and digital signatures. You know how TLS combines all three in a hybrid approach.

In the next lesson, we will walk through the TLS handshake step by step — every message, every round trip, every decision point. You will learn exactly what happens in the 200 milliseconds between typing https:// and seeing encrypted data flow.