This guide is specifically pertaining to the concept of using public and private keys to securely transfer data. Concepts like signing and key verification will be covered in another post.

Asymmetrical encryption (also known as public and private key encryption) is a simple idea that often gets explained with the worst possible analogies.

Even the word “keys” can trip us up. We normally think of one key opening one lock, but GPG keys don’t work like that at all.

This post is my attempt to give a clearer illustration of how public and private keys work, and why we use them.

Important terminology

  • Encrypting: scrambling a file so its contents can’t be understood without the right key.
  • Decrypting: unscrambling the file so the original contents can be read.

My illustration

Think of each public/private key pair as a magic marker and a magic eraser.

  • The marker is like the public key: anyone can use it.
  • The eraser is like the private key: only the owner should have it.

They’re magically bound together, and anything written with the marker can only be erased with its matching eraser.

Here’s how it plays out:

  1. You write a letter with a pencil.
  2. You borrow your friend’s magic marker (their public key) and scribble over your letter. Now it looks like a messy blob no one can read.
  3. You pass the letter to your friend.
  4. They use their magic eraser (their private key) to remove the scribbles, revealing the pencil text underneath.

Why do we even need this?

Let’s say you want to send George this letter:

GWSeeeo'errgeyeo,mueetthienngatmidnightattheLostInn.

You need to send it over the internet, but you don’t want anyone else snooping. So you ask George for his “magic marker”, his public key.

When you encrypt your letter with George’s public key, it’s like covering it in ink only he can remove. Even if someone intercepts it, all they’ll see is scrambled nonsense.

But what’s actually happening?

Rather than a magic marker writing over a letter, encryption is transforming the data behind a file in a predictable, mathematically driven way.

The same key, given the same input file, will always produce the same output file.

It’s worth noting GPG also adds a bit of random “session data”, thus the same file encrypted for the same person will vary a bit.

The math gets really complicated when you consider how we can use a private key to decrypt a file encrypted by a public key, so we’ll shelf the math and really try to understand what’s happening:

  • A public key can be used to encrypt a file into random data, and the original contents can only be restored by its corresponding private key.
  • The public key cannot be used to decrypt the data back to its original form, it’s a one way street.
  • The math is clever, a private key cannot be derived from the public key. This way you can post your public key on your blog, site, etc., allowing people to securely send you files.

Although not covered in this post, private keys can also be used to “sign” files. Public keys can be used to validate the authenticity of these signatures.

When would I ever use this?

Most private messaging apps are using a similar method, but at a more advanced and under-the-hood level.

That being said, there are still valid reasons to use GPG encryption when transferring files, even when using a generally secure platform.

Uploading sensitive information to public servers

Say you want to disperse a file of sensitive information to your community on Discord. Discord files are stored on a public server, meaning files uploaded to it are always publicly available. All you need to access the file is the related link.

But if you ask your community members to provide you with their public keys, you could create one-off encrypted versions, unique to each user.

Whistleblowers and journalists

Edward Snowden famously used a GPG email client to securely communicate with journalists, eventually uncovering a vast surveillance network employed by the US government.

Generating your own key pair

Generating your own keypair is as simple as running the following command:

$ gpg --full-generate-key

You will be asked to provide a name, an email, and a passphrase. It is important you provide an accurate email address, as it is used by others when encrypting a file with your public key.

You can also optionally set an expiration date for the key, which can later be extended.

Your new key is stored in your local “keychain”. You can see what keys you have stored with the following:

$ gpg --list-keys

[keyboxd]
---------
pub   ed25519 2025-08-29 [SC]
      2FE85E547FA7E26536DF733B445719E43214E8E8
uid           [ultimate] Joshua Lee <joshpaullee@gmail.com>
sub   cv25519 2025-08-29 [E]

You can then export your public key to a text file (the .asc extension indicates it’s in ASCII-armored format, making it human-readable text rather than binary):

$ gpg --export --armor your_email@example.com > public_key.asc

Using someone’s public key to encrypt a file

Now that you have your key setup, let’s see how we can import someone else’s public key to encrypt secret-note.txt.

For this example, I’ll use a public key generated for “George Freeman”, using the email george@free.io. We’ll pretend I copied the key off of his blog, and is saved to a text file named george.asc.

First, this public key needs to be imported into my keyring:

$ gpg --import george.asc

gpg: key D04B6D7873E18E48: public key "George Freeman <george@free.io>" imported
gpg: Total number processed: 1
gpg:               imported: 1

⚠️ Security Note: This is a simple introduction, but it’s paramount you understand the importance of verifying the authenticity of any public key before you import it. What if poor George had his blog compromised, and a third party replaced his key with theirs?

Verification (e.g., via fingerprints) will be covered in a future post.

We can list the keys again to verify it’s been added to my keyring:

$ gpg --list-keys

[keyboxd]
---------
pub   ed25519 2025-08-29 [SC]
      2FE85E547FA7E26536DF733B445719E43214E8E8
uid           [ultimate] Joshua Lee <joshpaullee@gmail.com>
sub   cv25519 2025-08-29 [E]

pub   ed25519 2025-08-29 [SC] [expires: 2028-08-28]
      5BECEF3C026112BAB597B5E0D04B6D7873E18E48
uid           [ unknown] George Freeman <george@free.io>
sub   cv25519 2025-08-29 [E] [expires: 2028-08-28]

Now I can encrypt my secret note with George’s public key:

$ gpg --encrypt --recipient "george@free.io" secret-note.txt

Which produces a new file: secret-note.txt.gpg. I can now confidently send my note to George, knowing only he can decrypt the file with his private key.

Conclusion

And that’s that! While many modern apps handle this encryption for you automatically, understanding GPG gives you direct control for situations where those apps aren’t an option.

This isn’t the full picture, and the power of GPG really comes into play when we start signing files. But these fundamentals are important to understand when diving into other encryption topics.