PGP encryption

I can never remember how PGP encryption works, so I'm writing this to help me remember. If it helps someone else well that's just fine & dandy. I'm going to try and run through it as quickly as possible, since this post is meant to act as a refresher, but if you want a proper introduction to PGP (and the perils thereof), Robert Heaton's guide to Off-The-Record messaging has a fantastic overview.

This isn't meant to be a user guide to any of the bunch of PGP tools out there. The internet is full of those already & doesn't need me cluttering stuff up.

PGP encryption is asymmetric, which is basically synonymous with public-key encryption. A sender encrypts with the receiver's public key, and the receiver decrypts with their private key, which is cryptographically linked to their public key using Advanced Math. The point here is that there's not a common passphrase that can be used to both encrypt and decrypt (as in symmetric cryptography).

The above isn't strictly true: asymmetric encryption & decryption is expensive and takes a lot of time, so PGP actually uses the receiver's public key to encrypt a symmetric session key, which is sent along with the encrypted message. Then the receiver's private key decrypts the session key, which decrypts the message.

PGP encryption can be used to encrypt any data that you don't want to be accessible or tamper-proof in transit, but these days it's most often used in sending emails and other text-based communications.

PGP encryption breaks down into 2 basic steps:

1. Encrypting and decrypting
2. Signing and verifying

In encrypting/decrypting, the receiver's public key is used to encrypt, and the receiver's private key is used to decrypt. Then the opposite is used for signing and verifying: the sender signs the message with their private key, and the receiver verifies the signature using the sender's public key.

Encrypting and decrypting

Before getting started with sending data, you have to know who you're sending the data to. You need the receiver's public key to encrypt your message.

Once you've encrypted your message using a public key, the only thing that can decrypt this message is the corresponding private key. Assuming everyone's security posture is nice and defensive, the only person that'd have the private key to decrypt the message should be the receiver. Meaning that even you can't decrypt the message that you've just encrypted.

On receipt, the receiver then uses their private key—the one that corresponds to the public key that you encrypted the message with—to decrypt the message.

Signing and verifying

Encryption is all well and good, but it doesn't guarantee that the message hasn't been tampered with in transit—or that it was even you sending the message in the first place. The receiver can decrypt the message, but they don't have any assurances about where the message has come from.

Message tampering: If the receiver's private key has been compromised, it's possible that some malicious actor in the middle could use the compromised key to decrypt the message, change its contents, and then send it on to the receiver. The receiver (who presumably doesn't know that their private key has been compromised) would then decrypt the message with no notice that what you originally sent isn't the same as what they're reading.

Identity verification: Even if the receiver's private key is secure and hasn't been compromised, the receiver has no guarantees that you are who you say you are. Your email account could have been hacked, or your address could have been spoofed.

Signing your message puts both of the above guarantees in place. What you do here is basically the reverse of encrypting/decrypting: you use your private key, along with the message contents (actually, a hash of the message contents called a message digest), to create a signature that you send with the message. Then, when the receiver decrypts it on the other end, they use your public key to check the signature.

If the public key doesn't match the private key—that is, if you aren't who you say that you are—then the check fails.

If the signature doesn't match the message digest—that is, if the message has been changed since the signature was created—the check fails.

This way, the receiver can be as sure of the message they've received as you are of the message that you've sent.

Further reading

How asymmetric cryptography enables HTTPS - Cloudflare