Reasons to Use PGP

For a few years now, I'm been considering using PGP or least trying it out. It's one of those things you see being used everywhere but don't really bother looking into it. This week I finally tried to at least set some stuff up.

Terminology

Before I start, I need to clarify some terminology. I've always been confused with PGP and GPG and used them interchangeably. PGP (Pretty Good Privacy) is technically a specific piece of proprietary software. GPG (GNU Privacy Guard) on the otherhand is free software. When I'm talking about PGP, I'm talking about OpenPGP, the protocol that both software implement and processes surrounding its use cases. Some of those processes involves using GPG so I might conflate the two.

Not About Privacy

Another thing to make clear is that using PGP alone doesn't provide privacy. Privacy is complicated to get right and it's about more than just the encryption you use.

For the most part, my use-cases for PGP are around verification. That is, a way to verify the thing I did was actually done by me.

The other use-cases are around one-off encrypted data. That is, while the data might be private, what I do with it isn't, nor what happens after it's decrypted.

Public Email

On the privacy point, one issue I have with PGP is that the public key makes my emails public. This is kind of required as most use cases use the email as a lookup against other public keys.

I've been wondering if I shoud drop the whole "public email, private email" thing I've been running with. Spam filters should be good enough, and I shouldn't get too comfortable as to lower my guard while scam emails get more and more elaborate.

The problem is I'll end up with one global identifier across the web. It's convenient, PGP is built to work like this, but it's also risky. Using a custom domain like jahed.dev only makes that worse since not only will someone know my email, but they'll also know my website and know that every other jahed.dev email is linked to the same person. So if I want to own my email address for private accounts and have a public website, I'll need at least two domains. That line between public and private is also blurred and any crossing over will link the two and make the entire thing pointless... Something to think about.

Low Level

Back on topic, one of the major issues with PGP is that it's not user-friendly. You won't see people storing and maintaining private keys. I've been trying to explain to people how Signal's verification process works, and even that goes over their head. Matrix also has a verification flow for encrypted chat and that's a bit clunky too in Element for non-technical people.

The general populace won't remember their passwords and pins, so they can't be expected to maintain private keys. This lack of trust means the benefits of PGP can only really be available in specific technical circles. I can't use PGP to send an encrypted attachment to anyone over email, the receiver needs to know how to handle it.

Possible Solutions

I haven't found any popular applications that makes PGP close to frictionless.

Keybase was trying to solve this issue by making it more friendly, but after being bought by Zoom, I have doubts on whether that's still their main goal.

Deltachat is another good example. They're using PGP to send encrypted emails with a instant-messaging-like interface on top. Email comes with so many caveats that goes against this usecase so I haven't used it myself but I'm keeping an eye on it.

And that's about it off the top of my head. So yeah, PGP is strictly for technical use-cases as far as I can tell.

Encrypting Data

I've always used PGP for storing one-off encrypted backups. It's as simple as generating a key and encrypting it for yourself. I say it's simple, but one thing about using GPG is that it has a lot of flags. So it's best to save common commands as scripts just to remind yourself. A GUI would also work, but personally, scripts are faster to use.

gpg --encrypt --recipient '[email protected]' backup.zip

Git Verification

In Git, anyone can use your name and email for tags and commits. There's no way of knowing it was actually you that made them. SSH keys are only used to access remote repositories, not to verify your actions. Git supports GPG so with a private key installed, it's as simple as:

git config --global user.signingkey 'keyid'

# Convenience so you don't need to add "-S" to every git command.
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# GitHub doesn't support signed pushes.
# git config --global push.gpgsign true

Getting the keyid is a bit odd. The easiest way is to run:

gpg --list-secret-keys --keyid-format LONG

Then find the series of alphanumerics on the sec line for the key you want, after the cryptosystem and /. Again, not user-friendly.

The great thing about signing your Git actions is that other people don't need to install your public keys. You can upload them to your remote host and let it do the verification. GitHub does exactly that and places a nice green "Verified" tag with a checkmark next to all of your actions in the web interface.

Email Verification

While pretty much everyone I send emails to isn't going to have my public key installed, it's still nice to provide a signature to let people know they can verify an email if they wanted to. Since I've already got PGP set up, it's a free feature.

Email clients also support encryption but like I said, no one's going to have my public key installed so they won't be able to read anything. And all it takes is one unencrypted email quoting an entire thread to compromise the entire conversation so it's kind of terrible for casual usage.

General Web Publishing

I could easily set up all of my publish scripts to sign my content but unlike email, there's no standard verification process, making it pointless.

It's odd that the for all the features the Web has, there's no way to verify the content we download is from who we'd expect. HTTPS ensures the connection is secure, but it's not verifying the actual content. I guess that's meant to be the job of the server?

For content, there's the integrity attribute that says the content is what the page expects, not that it's created by who we expect. Which is fine, but somewhere down the line, there should be a way to check the HTML document is authored by someone we personally trust. Not some giant Certificate Authority. Maybe something already exists in the endless pile of Web APIs, but I haven't come across it yet.

Conclusion

Anyways, before I go too deep into this rabbit hole, that's that. I have a PGP key installed and I'm open to using it on stuff that supports it. It's kind of tedious, a bit scary, but also pretty cool.

Thanks for reading.