Digital signatures are crucial for free software. They are needed for ensuring that the source code you find floating around on the Internet is the same source code its developers released.

There are, of course, other reasons to use digital signatures, or encryption, but for this article, we'll concentrate on using them against tampering and accidental changes.

Public key cryptography

Digital signatures are implemented using public key cryptography. In this kind of system everyone has two keys that form a pair. One key is private, the other public. Anything encrypted with the public key of a key pair can only be decrypted by the corresponding private key, and vice versa. In traditional cryptography, there is only one key, which must be kept secret.

Having a key pair allows digital signatures to work. The developer encrypts the source code distribution with their private key, and as a result anyone with the public key, which is anyone who cares, can decrypt it. Assuming the developer is actually the only one with the private key, this proves that the source code was released by them.

The key pair works in the opposite direction as well: if you want to send a bug report that only the developer should see, you encrypt it with their public key, and then only they can read it.

Web of trust

How do we know the key belongs to the developer? The two common approaches here is either to trust someone else, or to trust many others.

SSL and TLS ("https") work in the first manner. There are a relatively small number of companies, call certificate authorities, who digitally sign everyone else's keys with their own. Web browsers have the public keys of the certificate authorities, and can thus check that the SSL and TLS key is the one a website is meant to use. This works wonderfully, except that it creates a situation where you have to pay money to be able to communicate. It also assumes that all certificate authorities are trustworthy, and that web browsers only keep trustworthy ones on their list.

The other approach is to let everyone vouch for anyone else, but let everyone choose themselves whom they'll trust as introducers. This is called the web of trust. As an example, let's say I meet Daniel in person, having known him for many years, and we sign each others keys. Later, Daniel signs Richard's key. If I trust Daniel, then I can be confident that Richard's key is really his.

The web of trust is used by the OpenPGP encryption system, of which GnuPG (or gpg) is the common implementation. As a non-hierarchical, de-centralised system, it works much better for free software development than the certificate authority approach of web browsing.

Which software to use?

There is only one commonly used implementation of the OpenPGP encryption system in the free software world: GnuPG. This seems almost incredible, given how common it is for there to be alternative implementations of everything. However, that may be explained by the fact that there are two major branches of GnuPG in use, both supported by its deveopers.

The 1.4 branch is the older one, and is the default in Debian. The 2.0 branch has various new features, but is quite compatible with the older version. For most people, it doesn't matter which one you use.

Use the gpg your Linux distribution has installed. It almost certainly has one installed by default.

Using GnuPG

Rather than writing a new, short manual for GnuPG, we'll refer to the existing documentation:

• The Mini-HOWTO is a good way to get started.

• The website has a whole bunch more documentation, most of which you don't need to read.

Verifying digital signatures

For free software distribution, PGP digital signatures are used primarily in three ways:

• Signed commits or release tags in version control systems that support those (git does). To verify these, you use the version control tool.

• Source and binary packages in distributions that are either signed directly or indirectly via a listing (a la Debian). To verify these, you use the distribution's tools. It probably happens automatically.

• Release tarballs with detached signatures. These you need to verify manually. The command is gpg --verify foo.tar.xz.sig (see documentation for details).

Notice how GnuPG is usually used in the background already. You're a GnuPG user without knowing it.

Making digital signatures

When you want to release your own software, you should make a tarball and provide a "detached signature". This means the signature is in a separate file, not part of the tarball.

gpg --detach-sign foo.tar.xz

Then you publish both foo.tar.xz and foo.tar.xz.sig, and everyone will be happy.

On paranoia

Every time geeks discuss encryption of any form, they become paranoid. It is common for us to start worrying about the way our PGP secret keys are stored. After all, if the secret key is stolen, it can result in all your communications becoming public, and all your software releases to become untrustworthy.

Such worry is good, to a point. It's good to keep your private keys private. Very, very few people, however, need to worry about targeted attacks: if you think CIA and Mossad agents will be colliding in the night in your living room while looking for the hidden USB stick with your private keys, you should probably think again. Unless you're Edward Snowden. You need to do your own risk analysis and decide what your threats are. Be careful, but sensible.