Notes on Asymmetric Encryption

Overview

The previous note ended on a loose end: Symmetric Encryption scrambles messages beautifully, yet both sides need the identical key, and delivering that key across a hostile network hands it straight to the eavesdroppers. Asymmetric encryption unties this knot with a counter-intuitive trick: instead of one key, each side owns a pair. One half (the public key) is handed out to anyone who asks; the other (the private key) never leaves our machine. Whatever is locked with the public key can only be unlocked by its private twin, which suddenly lets complete strangers exchange secrets without ever agreeing on anything beforehand.

How it works

Suppose Bob wants to receive secret messages from the world, including from us, whom he has never met. He crafts a matching pair of keys, publishes the public one (his website will do) and guards the private one on his own machine. When we write him "meet me at noon", we fetch his public key, scramble the message with it and send it on its way. Eve intercepts everything: the ciphertext, certainly, but also Bob’s public key, which sits in plain sight anyway. It does her no good; knowing the key that locked the box does not open it, any more than snapping a padlock shut teaches us how to unsnap it. Only Bob, holding the private twin, restores the message:

encryption:  plaintext + recipient's public key  → ciphertext
decryption:  ciphertext + recipient's private key → plaintext

Good asymmetric algorithms

• RSA: the veteran of the family; its security rests on the difficulty of factoring enormous numbers;
• Elliptic Curve cryptography (ECC): the modern favourite; equivalent strength with far smaller keys, which is why curves such as Curve25519 power much of today’s web.

An example in practice

Let’s watch the whole exchange through OpenSSL. First Bob creates his key pair:

openssl genpkey -algorithm RSA -out bob_private.pem

openssl pkey -in bob_private.pem -pubout -out bob_public.pem
# No output; the private file stays with Bob,
# the public one can be published anywhere

Then we send him our secret:

echo "meet me at noon" > message.txt

openssl pkeyutl -encrypt -pubin -inkey bob_public.pem \
  -in message.txt -out message.enc
# No output; Eve may inspect message.enc at leisure

openssl pkeyutl -decrypt -inkey bob_private.pem \
  -in message.enc -out decrypted.txt

cat decrypted.txt
# meet me at noon

Notice how the commands mirror the theory: encryption reaches for the public file, decryption for the private one, and no shared secret ever crossed the network. There is a limit hiding here, though: try feeding a large file into -encrypt and OpenSSL refuses, because RSA can only swallow messages smaller than the key itself (a few hundred bytes at typical sizes).

The catch

And that limit points to a broader truth: asymmetric encryption is slow and small-minded, unfit for bulk data such as videos or disk images. Nobody uses it alone; instead, protocols rely on a hybrid scheme: asymmetric encryption delivers a freshly generated symmetric key (small enough for one encrypted trip), after which Symmetric Encryption carries all the actual data. This is precisely what TLS does during every handshake, and it closes our circle elegantly: symmetric encryption needed a safe way to deliver keys, and asymmetric encryption turns out to be exactly that delivery service.

One question remains dangling, however: when we download a public key claiming to be Bob’s, how do we know it is really his? That is where Certificates enter the story.