💾 Archived View for kota.nz › notes › gpg captured on 2022-04-28 at 17:20:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
2021/03/23
There are two basic forms of encryption -- symmetric and asymmetric, each with advantages and disadvantages. Many encryption systems use both. Symmetric is simpler and more performant. It works by generating a key, using that key as a cipher for your message, and then anyone with the key can decrypt your message. It's very fast and is predictably as strong as your key.
Asymmetric, or public-key encryption, is a bit more complicated. All participants must generate a public and private key. This is done by creating a large random number and passing it into a key generation program. Like the name suggests, you are meant to share your public key with anyone you would like to communicate with, however this doesn't need to be done securely. In fact you can find my pgp public key here on my website. There are also large keyservers hosted by universities and non-profits where many people upload their keys, usually tied to an email address. However, some people have spoken out about the risk entailed with giving that much trust to a centralized organization. As a rule of thumb, check if the person has a key on their personal website, most news organizations do this for whistleblowers. When in doubt you can send an email to your recipient asking for their key.
large keyservers hosted by universities
You can never share your private key! If you have potentially lost it, you're meant to create and share a special key revocation certificate. When encrypting a message, you combine your private key and the public keys of all recipients (including your own public key if you want to decrypt your message later). Any recipient can use their matching private key to decrypt the message.
OpenPGP is an open asymmetric\* standard, originally based on PGP (Pretty Good Privacy), a closed source implementation. GPG (GNU Privacy Guard) is an open source implementation of OpenPGP, which is what most people actually use. Technically, PGP is not a pure asymmetric algorithm, as it would be unable to encrypt a message larger than its key size. Instead, PGP uses asymmetric encryption to encrypt a symmetric key. Private keys are also usually stored encrypted with a symmetric algorithm so that you must enter a passphrase before using your private key. This gives your private key a tiny bit of security if you loose it, hopefully enough time to put out a key revocation.
PGP can be used to securely transfer, store, or sign any arbitrary data. The three most common uses being encrypted email, storing encrypted files, and signing software releases.
Like I said, you can use PGP to secure any communication medium, be it text messages or whatever New Spyware Texting App™. Email is a simple, federated, and open communication system, but is unencrypted by design, so GPP/OpenPGP finds most of it's use in securing email communications. Famously, it was used by Edward Snowden to whistleblow on the NSA's illegal spying regime.
For setting up and using GPG with email I highly suggest you follow this guide put together by the FSF. It explains how to install plugins for several popular email clients and even has a test bot you can send emails to in order to verify everything is working. For more advanced users, the plugins aren't needed since you can just use gpg --encrypt --armor
--recipient email@example.org to encrypt your message on the command line (and convert the output to an email character set with --armor).
this guide put together by the FSF
PGP is also popular for encrypted file storage/transfer and is the backbone for pass, a popular unix style password manager. This is the password manager I use myself and I feel it has a few advantages over other (open source and offline) options.
First of all, the design is very simple. As a result, many well made clients exist to compliment the original CLI tool. Android/IOS apps, a graphical qt app (with Windows/macOS support), and even some browser plugins. Pass stores every "password" in a single encrypted file. The first line is considered the "password" and the rest can be used to store any additional information such as username, email, "security questions", or even just notes. I use it to store credit card info and medical information, for example.
This design makes it easy to track your password collection with a VCS like git, which allows you to sync your passwords to all your computers. Most pass clients expect you to do this and will automatically make commit messages for you, if the folder is a git repo. This is a huge advantage compared to Keepass. When I used keepass, I would sometimes add passwords on my laptop -- then add a password from my phone before I got a chance to sync the password file to all my computers. This left me with two different password databases. I then had to manually dig through and create the "one true version" to sync to all my computers. This virtually never happens with pass.
Storing your passwords online can seem a bit sketchy, and you might as well set the repo to "private/unlisted", but GPG's encryption is so strong that having those files public doesn't make guessing your passwords any easier. After all, GPG is designed for the messages to be publicly available and yet still remain uncrackable with the best super computers now or ever if our basic laws of physics are correct. Most password managers implement solid, well tested, encryption algorithms, but the problem is implementing them in the first place leaves more room for error. Every line of code added to a project creates more room for security bugs. Pass doesn't contain "encryption" code. It just calls battle hardened GPG for everything. Hell, you can even use your "pass database" without pass installed by using the GPG commands directly.
basic laws of physics are correct
Since data can be signed with PGP, it gets used for software releases to prove a specific release file was signed by the maintainer. You can sign any public message, statement, or file in order to prove are who you say you are, or at least that you have their private key.
Signing a software release is as simple as running gpg --armor --detach-sign
oftware-0.4.tar.gz which will create software-0.4.tar.gz.asc. Then, when you upload your release file you simple upload the asc file with it. On Github and most other project hosting sites you'll find a dedicated option for this on the release creation page.
An alternative method is to sign a git release tag which is useful for software that doesn't have a tarball distribution system. Chapter 7.4 of the git book explains this process. To summarize, you need to figure out which key you'd like to sign with, run a command like git config --global user.signingkey 0A46826A to configure git to use your key for signing, and then create signed tags like this git tag
-s v1.5 -m 'my signed 1.5 tag'. I do this on most of my projects, this is what the release tags look like for pcf.
this is what the release tags look like for pcf.
Now any user can download both your tarball release and your asc signature and verify that the person in control of your private key (hopefully just you) did in fact run that command to generate that file. This process makes it extremely hard for a bad actor that gains the login credentials for an important software project to put out a fake release with backdoors. Normally your distro's maintainers use these signatures to verify software before they package it up into a new release.
To verify a release signature you need to have the author's public key(s) in your keyring. If you've done that you just run a command like the following gpg --verify software-0.4.tar.gz.asc software-0.4.tar.gz or in the case of checking git tags you can use git tag -v v1.6.2 for the version you'd like to test. Again, you will get an error if you haven't imported the author(s) public keys. Go check their website, download their key, and run gpg --import
somedude.gpg before trying out these commands.
Creating your own GPG keys is pretty straight forward and I highly encourage you to use the default options. They are updated with the latest GPG releases to make sure you're using the best and most modern algorithms. Typically the maintainers of GPG have a better idea of what to use than "some dude on stackexchange".
Generate a key. Option 1 will make both of the keypairs which is what you probably want. Next you'll be asked for a keysize. The default is strong enough that it would likely be cheaper for an attacker to circumvent GPG, install a backdoor on your computer, or pay someone to beat you with a wrench until you give them your key. Higher keysizes are slower so I just stick with the default.
or pay someone to beat you with a wrench until you give them your key.
$ gpg --gen-key
gpg (GnuPG) 0.9.4; Copyright (C) 1999 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection?
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024)