Public-Key Crypto and Key Exchange

Public-key cryptography solves the problem symmetric keys cannot: how two parties who have never met agree on a secret over a channel an eavesdropper is watching. Each party has a key pair — a public key to share and a private key to guard — and the math lets anyone encrypt to your public key or verify your signature, while only you can decrypt or sign.

This topic makes RSA and elliptic-curve crypto concrete and explains the key exchange — Diffie-Hellman — that every HTTPS session with app.meridian.example depends on. The whole scheme rests on one thing: the private key never leaking, and the public key genuinely being yours.

The Key-Pair Idea, Operationally

The public key encrypts and verifies; the private key decrypts and signs. The public key is meant to be handed out freely — publishing it is the point — while the private key never leaves its holder. Confusing which key does what, or treating the public key as a secret, is a common beginner error; the security comes entirely from guarding the private key and from being sure a public key really belongs to who you think (which PKI, next topic, guarantees).

RSA vs Elliptic Curve

RSA is the well-known incumbent, but it needs large keys — 2048 to 4096 bits — to stay secure. Elliptic-curve cryptography (Ed25519 for signing, X25519 for key exchange) gives equivalent security with much smaller, faster keys, and it is now the default for new systems. Both are threatened in the long term by quantum computers, which is why post-quantum algorithms are beginning to arrive, but for today ECC is the pragmatic choice.

# generate an Ed25519 private key (signing) — keep this secret, ideally in a KMS/HSM
openssl genpkey -algorithm ed25519 -out meridian-svc.key

# derive the public key to share freely
openssl pkey -in meridian-svc.key -pubout -out meridian-svc.pub

# the .key never leaves the host; the .pub is distributed to anyone who verifies signatures

The private key stays on the host — better still, inside a hardware security module or KMS that never releases it — while the public key is distributed to anyone who needs to verify the service's signatures. If that private key leaks, every guarantee built on it collapses, which is why key protection is the real security boundary, not the algorithm.

Diffie-Hellman Key Exchange

Diffie-Hellman lets two parties derive a shared secret over a public channel without ever sending it. An eavesdropper sees the exchange but cannot compute the secret from what crosses the wire — and that shared secret becomes the symmetric session key for the conversation. Every TLS session starts with a key exchange like this, which is why the padlock can appear the instant you connect to a site you have never visited.

Forward Secrecy and the Hybrid Model

Using an ephemeral Diffie-Hellman key — a fresh one per session, written ECDHE — gives forward secrecy: even if the server's long-term private key is stolen later, past recorded sessions stay unreadable, because each used a throwaway key. And because public-key operations are slow, real systems use them only to exchange a symmetric key, then encrypt the bulk data with AES — the hybrid model behind TLS and every encrypted messenger.