pages tagged cryptographyyakkinghttp://yakking.branchable.com/tags/cryptography/yakkingikiwiki2014-12-11T09:20:08ZGnuPG (gpg): a brief introductionhttp://yakking.branchable.com/posts/gpg-intro/Lars Wirzenius2014-12-11T09:20:08Z2014-12-10T18:14:30Z
<p>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.</p>
<p>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.</p>
<h1>Public key cryptography</h1>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h1>Web of trust</h1>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>The web of trust is used by the OpenPGP encryption system, of which
<a href="">GnuPG</a> (or <code>gpg</code>) 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.</p>
<h1>Which software to use?</h1>
<p>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.</p>
<p>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.</p>
<p>Use the <code>gpg</code> your Linux distribution has installed. It almost
certainly has one installed by default.</p>
<h1>Using GnuPG</h1>
<p>Rather than writing a new, short manual for GnuPG, we'll refer to the
existing documentation:</p>
<ul>
<li><p>The
<a href="http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html">Mini-HOWTO</a>
is a good way to get started.</p></li>
<li><p>The <a href="https://www.gnupg.org/documentation/index.html">website</a> has
a whole bunch more documentation, most of which you don't need to
read.</p></li>
</ul>
<h1>Verifying digital signatures</h1>
<p>For free software distribution, PGP digital signatures are used
primarily in three ways:</p>
<ul>
<li><p>Signed commits or release tags in version control systems that
support those (git does). To verify these, you use the version
control tool.</p></li>
<li><p>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.</p></li>
<li><p>Release tarballs with detached signatures. These you need to verify
manually. The command is <code>gpg --verify foo.tar.xz.sig</code> (see
documentation for details).</p></li>
</ul>
<p>Notice how GnuPG is usually used in the background already. You're a
GnuPG user without knowing it.</p>
<h1>Making digital signatures</h1>
<p>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.</p>
<pre><code>gpg --detach-sign foo.tar.xz
</code></pre>
<p>Then you publish both <code>foo.tar.xz</code> and <code>foo.tar.xz.sig</code>, and everyone
will be happy.</p>
<h1>On paranoia</h1>
<p>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.</p>
<p>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.</p>