Antique lock on a wooden chest

How Asymmetric Encryption Works (In Oversimplified Terms)

Asymmetric encryption requires at least two entities (usually people) to exchange encrypted messages. It also requires each of those entities to have two keys:

  • a public key, which is shared
  • a private key, which is kept secret

Here's how it works, in simple terms:

Listen carefully; I will say this only once!

As with all systems/methods, some initial setup is required.

  • Michelle uses software to create a key pair (public and private keys) for herself.
  • Rene uses the same (or compatible software) for himself.
  • Michelle and Rene exchange their public keys over secure channels (such as Element or Signal, not email), storing their private keys somewhere safe (preferably not on their computers).

This process need only be repeated if a key is compromised/expired/lost and/or revoked.

Allo, Allo!

With that out of the way, exchanging encrypted messages can begin.

  • To send a message to Rene, Michelle uses her encryption software to encrypt the message, selecting her private key and Rene's public key.
  • The software derives (generates) a per-message session key based on the two supplied keys.
  • The software encrypts the message using the derived key.
  • Both the derived key and message are sent to Rene (usually with the derived key attached to the encrypted message, as one chunk of data).
  • Rene receives the encrypted message and enters it into his software, supplying his private key.
  • The software extracts the derived key.
  • Using the derived key with Rene's private key, the software decrypts the message and shows the plaintext to Rene.
  • The process is repeated when Rene sends a response to Michelle (except that Rene's private key and Michelle's public key are used).
  • Without Michelle or Rene's private key, anyone intercepting the message to that person cannot decrypt it (in theory, anyway).

PGP is not foolproof, but it's better than nothing.

Caveat: One potential pitfall with this approach may be that of sending metadata in the clear. If the content of a message is sensitive enough to warrant encryption, Michelle and Rene will do themselves a favour by not having the subject line in the clear as well. To follow a theme, they would discuss the movements of "onion sellers" instead of "British airmen". Obviously, the more elaborate and obscure the code used (a topic of discussion unto itself), the better, but you get the idea.

Note: Instead of using the standard characters for cryptography and science (Alice and Bob), I've used characters from the British TV series Allo, Allo, to add humour.

Post thumbnail: Photo by Pixabay

How do you rate this article?


Great White Snark
Great White Snark

I'm currently seeking fixed employment as a S/W & Web developer (C# & ASP .NET MVC, PHP 8+, Python 3), hoping to stash the farmed fiat and go full Crypto, quit the 07:30-18:00 grind. Unsigned music producer; snarky; white; balding; smashes Patriarchy.

Return to the Source
Return to the Source

Use the Force; read the source! This blog is mostly a collection of study notes on ASM, ASP .NET, Blender, BASIC, C/C++, C#, ChucK, Computer Architecture, Computer Literacy, CSS, Digital Logic, Electronics, F#, GIMP, GTK+, Haskel, Java, Julia, JavaScript (ES6+) & JSON, LISP, Nim, OOP, Photoshop, PLAD, Python, Qt, Ruby, Scheme, SQL (MySQL & SQLite), Super Collider, UML, Verilog, VHDL, WASM, XML. If I can learn it and make notes on it, I'll write about it. || Blog images copyright Markus Spiske and Pixabay

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.