Linux Crypto: GnuPG Usage

With our private and public key generated and stored, we can start using a few of GnuPG’s features to sign, verify, encrypt, and decrypt files and messages for distribution over untrusted channels like the internet.

Signing a message or text file

We’ll start by signing a simple text file, using the --clearsign option. This includes the signature in the message, which we can then distribute to people to read. Here’s the contents of message.txt:

This is a public message from Tom Ryder.

We’ll sign that with our new private key like so:

$ gpg --clearsign message.txt

We’re prompted for our passphrase for the private key:

You need a passphrase to unlock the secret key for
user: "Tom Ryder (Test Key Only) <>"
4096-bit RSA key, ID 040FE79B, created 2013-03-23

Having provided that, the file message.txt.asc is created, with PGP sections and a plaintext ASCII signature:

Hash: SHA256

This is a public message from Tom Ryder.
Version: GnuPG v1.4.10 (GNU/Linux)


Note that the message itself is plainly readable; this message isn’t encrypted, it’s just verified as having been written by a particular person, and not altered since it was written.

Now anyone who has our public key on their keyring (as we ourselves do) can verify that it was actually us who wrote this message:

$ gpg --verify message.txt.asc
gpg: Signature made Sat 23 Mar 2013 14:32:17 NZDT using RSA key ID 040FE79B
gpg: Good signature from "Tom Ryder (Test Key Only) <>"

If anybody tampers with the message, even something like removing a period from the end of a sentence, the verification will fail, suggesting the message was tampered with:

$ gpg --verify message.txt.asc
gpg: Signature made Sat 23 Mar 2013 14:32:17 NZDT using RSA key ID 040FE79B
gpg: BAD signature from "Tom Ryder (Test Key Only) <>"

Signing and verifying binary files

For all other files, we likely need to make the signature file separate with a detached signature:

$ gpg --armor --detach-sign archive.tar.gz

This produces a file archive.tar.gz.asc in the same directory, containing the signature. We use --armor to make the signature in ASCII, which makes for a longer file but easier distribution online.

In this case, both the file and the signature are required for verification; put the signature file first when you check this:

$ gpg --verify archive.tar.gz.asc archive.tar.gz

You can use this method to verify software downloads from trusted sources, such as the Apache HTTPD development team. First, we would download and import all their public keys at the URL they nominate:

$ wget
$ gpg --import KEYS

We could then download an Apache HTTPD release, along with its key, from an arbitrary mirror:

$ wget
$ wget

We can then use the key and signature to verify that it’s an uncompromised copy of the original file signed by the developers:

$ gpg --verify httpd-2.4.4.tar.gz.asc httpd-2.4.4.tar.gz
gpg: Signature made Tue 19 Feb 2013 09:28:39 NZDT using RSA key ID 791485A8
gpg: Good signature from "Jim Jagielski (Release Signing Key) <>"
gpg:                 aka "Jim Jagielski <>"
gpg:                 aka "Jim Jagielski <>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A93D 62EC C3C8 EA12 DB22  0EC9 34EA 76E6 7914 85A8

Note that the gpg output cautions that this is still not perfect assurance that the release actually came from Jim Jagielski, because we’ve never met him and can’t absolutely, definitely say that this is his public key. Looking him up on public keyservers, we can however see a lot of other Apache developers have signed his key, which looks promising, but do we know who they are?

Despite the lack of absolute certainty, when downloading from mirrors this is a lot better (and harder to exploit) than simply downloading without validating or checksumming at all, given that the signature and the KEYS file were downloaded from Apache’s own site.

You will need to decide for yourself how sure you need to be whether a person’s public key really corresponds to them. This might extend to the point of arranging to meet them with government-issued identification!

Encrypting a file

We can encrypt a file so that only nominated people can decrypt and read it. In this case, we encrypt it not with our own private key, but with the recipient’s public key. This means that they will be able to decrypt it using their own private key.

Here’s the contents of secret-message.txt:

This is a secret message from Tom Ryder.

Now we need at least one recipient. Let’s say this message was intended for my friend John Public. He’s given me his public key in a file called john-public.asc on a USB drive in person; he even brought along his birth certificate and driver’s license (which is weird, because I’ve known him since I was four).

To start with, I’ll import his key into my keychain:

$ gpg --import john-public.asc
gpg: key 695195A5: public key "John Public (Main key) <>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Now I can encrypt the message for only John to read. I like to use the 8-digit hex code for the key for --recipient, to make sure I’ve got the right person. You can see it in the output above, or in the output of gpg --list-keys.

$ gpg --armor --recipient 695195A5 --encrypt secret-message.txt

The encrypted message is written to secret-message.txt.asc:

Version: GnuPG v1.4.10 (GNU/Linux)


Note that even I can’t read it, because I didn’t list myself as a recipient, and I don’t have access to John’s private key:

tom@tombox:~$ gpg --decrypt secret-message.txt.asc
gpg: encrypted with 2048-bit RSA key, ID 964AEA6E, created 2013-03-10
    "John Public (Main key) <>"
gpg: decryption failed: secret key not available

However, on John’s computer, using his private key, he can decrypt and read it:

john@johnbox:~$ gpg --decrypt secret-message.txt.asc
gpg: encrypted with 2048-bit RSA key, ID 964AEA6E, created 2013-03-10
    "John Public (Main key) <>"
This is a private, secret message from Tom Ryder.

If I wanted to make sure I could read the message too, I’d add my own public key to identify myself as a recipient when I encrypt it. Then either of us will be able to read it with our private keys (independently of the other):

$ gpg --recipient 695195A5 --recipient 040FE79B \
    --armor --encrypt secret-message.txt

Just to be thorough, we can sign the message as well to prove it came from us:

$ gpg --recipient 695195A5 --recipient 040FE79B \
    --armor --sign --encrypt secret-message.txt

Then when John runs the --decrypt, gpg will automatically verify the signature for us too, provided he has my public key in his keyring:

$ gpg --decrypt secret-message.txt.asc
gpg: encrypted with 2048-bit RSA key, ID 964AEA6E, created 2013-03-10
    "John Public (Main key) <>"
gpg: encrypted with 4096-bit RSA key, ID AA159E5B, created 2013-03-23
    "Tom Ryder (Test Key Only) <>"
This is a private, secret message from Tom Ryder.
gpg: Signature made Sat 23 Mar 2013 17:23:20 NZDT using RSA key ID 040FE79B
gpg: Good signature from "Tom Ryder (Test Key Only) <>"

These are all the basic functions of GnuPG that will be useful to most people. We haven’t considered here submitting keys to public servers, or participating in the web of trust; you should only look into this once you’re happy with how your key setup is working, and are ready to publish your key for public use.

<< Linux Crypto: GnuPG KeysLinux Crypto: SSH keys >>
This entry is part 3 of 10 in the series Linux Crypto.

15 thoughts on “Linux Crypto: GnuPG Usage

  1. you may not want to call this Linux crypto. It works on FreeBSD (and solaris and other OSes as well). Linux /dev/*random sucks though so its dangerous to use on a Linux box.

    • Yeah; the introduction states this is all known to work in other open source UNIX-likes. I’ve presented it this way as I’m personally most familiar with Linux. I feel it’s likely BSD users will already be familiar with any relevant differences anyway.

      I don’t really want to call it “Unix Crypto”, as it would imply I’ve tested it on other Unices where for all I know GnuPG doesn’t even work.

      I wonder if you’d elaborate on why Linux’s random devices are considered dangerous? I’m interested, and I’m sure others would be too.

  2. Nice article for people new to GPG, but there’s a small typo in the section concerning signing and verifying binary files: $ gpg –armor –detach-sig archive.tar.gz should be: $ gpg –armor –detach-sign archive.tar.gz

  3. Thank you! I just came across your blog the other day (Steve Losh referenced your Vim Koans), and I love what I’m seeing so far!

    GPG & PGP are topics I’ve been struggling to understand and your crypto series is golden.

    Keep it coming! =)

    I don’t know if you are planning to address this or not, but one thing that’s really holding me back from the GPG world is that I’m far more “tech” oriented than most of the people I interact with on a regular basis. It just doesn’t seem to make sense to be the only one in my circle of friends that actually signs or encrypts anything. Just thought it might be a topic worth addressing if you’ve got the time — practical applications for these tools where people you send messages to don’t have any keys of their own (if there are any).

    • I’m pleased you’re enjoying the series. I’ll be putting the next article up shortly.

      As far as uses for GPG is concerned, I’m going to address password management, using what amounts to a command-line GPG frontend. Given the rise of GPU cracking, using strong unique passwords and passphrases gets more and more important, and a password management tool is the easiest way to address this.

      Another potential use is encrypting sensitive files for your own eyes only, particularly files that you need to back up on servers that you may not completely trust.

      Aside from that, it’s quite true that the use of PGP encryption for communication and authentication depends heavily on others using it as well. Hopefully as new tools and frontends come about, with a little effort on consciousness raising for the importance of security, we may find these kinds of tools becoming far more mainstream. At least, I hope so.

  4. Newb question but, as you mentioned MITM attacks in the ssh article… Wouldn’t the command wget (as well as checking on a public keyserver) be vulnerable to these kind of attacks?

    • I do go on to say that it’s not perfect assurance, but yes, that should definitely be using https (which I didn’t realise was available for that URL), so I’ll fix that now. Cheers!

      The KEYS file itself has a leading note suggesting that validating the keys out-of-band is desirable if possible.

    • Hi Will; I chose as a placeholder for any Apache mirror. The point is that the binary file can come from any of the mirrors, but you verify it with the signature from the site, to check that none of the mirrors have corrupted the file.

  5. Will you cover using your keys/signature in emails in programmes like ‘Claws-Mail’, for instance, please? I’ve followed your articles/posting with each one that came out, and tried out all the commands that you used, but I still don’t know which is my private and which is my public key! Thanks for listening.


    • Hi Sharon; I had not intended to cover this. I haven’t used Claws Mail personally, though I will be covering the use of Mutt — much of the blog is command-line focussed.

      PGP mail is really important though and with the latest revelations from the NSA this has been bothering me a lot, so I may try it and write about it later on.

      Thanks for reading, I hope you’ve found some of this at least partway useful!

  6. Pingback: Encrypting Logwatch Emails « Michael Henley

Leave a Reply

Your email address will not be published. Required fields are marked *

You can use Markdown if you want.