Asymmetric Encryption — Public & Private Keys

The key exchange problem, solved

For thousands of years, every encryption system shared the same weakness: both parties needed the same key, and exchanging it securely required a secure channel that didn't yet exist.

In 1976, Whitfield Diffie and Martin Hellman published a paper that changed everything: "New Directions in Cryptography."

Their insight: you don't need to share a secret to establish one.

Two keys, one pair

Asymmetric encryption uses a mathematically linked pair of keys:

• Public key — shared freely with anyone. Can be published on a website.
• Private key — kept secret. Never leaves your possession.

The relationship between them is one-way: you can derive the public key from the private key, but you cannot reverse the process. The math guarantees it.

Encryption: anyone with your public key can encrypt a message that only your private key can decrypt.

Signatures: you can sign a message with your private key. Anyone with your public key can verify the signature came from you — and that the message hasn't been altered.

<div style={{ marginTop: "1.5rem", marginBottom: "1.5rem" }}> !Assymetric Encryption simplified </div>

The math underneath

The security of asymmetric cryptography rests on hard mathematical problems.

RSA (1977) uses the difficulty of factoring large integers. Multiplying two large primes p × q is trivial. Factoring the product N back into p and q — when N is 2048 bits — is computationally infeasible with current technology.

Elliptic Curve Cryptography (ECC) uses the discrete logarithm problem on elliptic curves. Given a point P on a curve and a scalar k, computing k × P is fast. Reversing it — finding k given P and k × P — is hard.

ECC achieves equivalent security to RSA with much smaller keys. A 256-bit ECC key matches the security of a 3072-bit RSA key. This is why Ethereum, Bitcoin, and ZK proof systems all use elliptic curves.

A concrete example: key exchange

Alice and Bob want a shared secret. Eve is watching the entire conversation.

1. Alice and Bob agree publicly on a large prime p and a base g 2. Alice picks a secret a, sends Bob A = g^a mod p 3. Bob picks a secret b, sends Alice B = g^b mod p 4. Alice computes B^a mod p = g^(ab) mod p 5. Bob computes A^b mod p = g^(ab) mod p

Both arrive at the same shared secret g^(ab) mod p — without ever sending it.

Eve saw p, g, A, and B. To find the shared secret, she'd need to solve the discrete logarithm: find a from g^a mod p. For large enough primes, this is computationally infeasible.

This is the Diffie-Hellman key exchange — the foundation of nearly every secure channel on the internet.

Digital signatures

Asymmetric keys don't just encrypt — they authenticate.

A digital signature works in reverse:

1. Alice hashes her message: h = SHA-256(message) 2. Alice signs the hash with her private key: sig = sign(h, privateKey) 3. Alice sends the message and sig to Bob 4. Bob hashes the received message independently 5. Bob verifies: verify(sig, hash, alicePublicKey) → true or false

If the signature verifies, Bob knows two things: - The message was signed by whoever holds Alice's private key - The message hasn't been altered (any change would produce a different hash)

Where this leads

Asymmetric cryptography solves the key distribution problem. But it also unlocks something deeper: the ability to prove things about private information without revealing it.

If you can sign a message with your private key to prove you own it — can you prove you know something without signing it directly? Can you prove a computation was done correctly without showing the inputs?

That's the question that leads directly to zero-knowledge proofs.