tmacuk

Hello all. In case any of you are wondering, the title is in fact a reference to the classic pseudo-hacking game ‘Uplink’, one of my favourite games. Nevertheless it holds true for this situation, when it comes to cryptography, the problem of trust is a weakness. However, before we deal with the problem of trust, let us first address a simpler matter.

Obtaining Other People’s Keys

If you wish to send an encrypted message to someone using GnuPG, or wish to validate a signature of theirs on a message, you will need your own copy of their public key. GnuPG stores the public keys you have collected (including those corresponding to your private keys) in a ‘keyring’. This keyring is really just a single file containing each public key.

To ‘export’ an individual public key (essentially just splitting part of the keyring out into a separate file) we can use the --export command of GnuPG. For example, to export your key you might use:

gpg --armor --output MyKey.asc --export $GPGKEY

(N.B. Unless you have like me configured the BASH variable $GPGKEY to point to your KeyID, you will need to replace this with the KeyID of the key you wish to export)

This will create the file MyKey.asc containing a complete copy of your public key (but of course not your private key). This file can be stored, sent in an e-mail, whatever (and remember, it only contains public information, so need not be secret). This can be used as one method of distributing your key, typically by uploading this file to your webserver and making it available there for people to download. Anybody with a copy of your key can execute:

gpg --import MyKey.asc

Running this command will export your public key into their keyring, and they will then be able to use it to send encrypted messages to you, and/or verify your signature on messages. However, this method of distribution is not usually very convenient, and there is a better option.

Keyservers

Keyservers are, exactly as the name suggests, public servers on the internet, to which people can publish their private keys, and from which people may retrieve any public key. We briefly met keyservers when we generated our keypair, when I showed you quickly how to upload your key to a keyserver. But as a quick recap:

gpg --keyserver pgp.mit.edu --send-keys $GPGKEY

This sends a copy of your public key to the keyserver specified. Almost all keyservers sync with each other, so within a few minutes to hours your key should be available on most public keyservers. This means that anyone should be able to retrieve your key from many keyservers.

Keyservers can make it very easy for people to retrieve your key. Firstly, if they receive a message sent by you they can easily get your public key to verify it. By default GnuPG will not decode the signature, and inform the user of the KeyID they require to validate the signature. The user can then run:

gpg --keyserver pgp.mit.edu --recv-keys {KEYID}

This will retrieve the key specified by that key id, and the user can then verify your signature. It is also possible to configure GnuPG to do this automatically for you, although it is usually not recommended (for reasons you will meet further down).

A user can also search for keys in a keyserver by name, e-mail address, or key id. You can do this using the command:

gpg --keyserver pgp.mit.edu --search-keys {SEARCH}

However, this must be treated with great caution, due to the problem of trust.

Trust’s Weakness

The main problem with the security of GnuPG is not the security of the ciphers, which is strong enough that they should remain relatively unbreakable (providing you use custom options such as those I have discussed) until there are major advances in technology and/or mathematics (although it should be noted, these could feasibly occur at any time – security can never be perfect).

The problem is this. I have of course my own GnuPG key, which I created. When I created it, I entered my name and e-mail addresses correctly, and I know my own identity. So I know that my particular private key (and the corresponding public key) verifies that something has been signed or can only be read by me, Matthew Gadd. However, how can anyone else be sure?

The thing is, that although no-one can forge a message with a signature by my KeyID, they can very easily create their own key, and put my name instead of theirs, and then create messages that are supposedly from ‘Matthew Gadd’. They will have a different KeyID, but face with the two KeyIDs claiming to be me, how can anyone know which is correct?

To illustrate this problem further, here is a key search I performed on one of my e-mail addresses. Note that there are 5 different keys returned, which could all be me (or none of them).

gpg --keyserver pgp.mit.edu --search-keys hello@darkotter.com

gpg: searching for "hello@darkotter.com" from hkp server pgp.mit.edu
(1)	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	  4096 bit RSA key C6E53A2D, created: 2010-01-31
(2)	Matthew Gadd
	Matthew Gadd
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 94D59FB5, created: 2009-05-11 (revoked)
(3)	Matthew Gadd
	Matthew Gadd
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 3779C483, created: 2008-12-15 (revoked)
(4)	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 17E0BBB9, created: 2008-07-11 (revoked)
(5)	Dark Otter (Dark Otter)
	Matthew Gadd (Dark Otter)
	  1024 bit DSA key 2D0BBF83, created: 2008-07-01 (revoked)

(N.B. Some e-mail addresses have been removed – each of the duplicate names originally had a different e-mail address, printed after it)

So, supposing someone wanted to send me an e-mail securely. Which key should they download and use? Can they really trust any of them? This is the problem of trust.

However, like most problems, GNU and PGP developers have come up with a way to attempt to solve this. Like any security system, it cannot guarantee perfect trust, but it can get somewhere much closer to it than nothing. The basis of this system is key signing.

Suppose I am working with a person, let’s call them Bob. We both have GnuPG, and our own keys, and we want to be able to send secure messages to each other. So, I write down a copy of my key fingerprint (the longer form of my KeyID), and take my passport (or other identification), and he does the same. We both meet up, and check each others passports to ensure our identities are real. We then each take the copy of the other persons key fingerprint.

I now know exactly which GnuPG is guaranteed to be Bob (because the key fingerprint is absolutely unique to a key, note that KeyIDs are sometimes the same), and so I can trust this key. So, when I get home, I download this key from the keyserver, for example:

gpg --keyserver pgp.mit.edu --recv-key 0xDB0A62087277450569F32DDE7F5FC5A5A0503C60

Because I can absolutely trust this key to be bob, I now sign the key:

gpg --sign-key 0xDB0A62087277450569F32DDE7F5FC5A5A0503C60

pub  4096R/A0503C60  created: 2010-02-02  expires: never       usage: SC
                     trust: unknown       validity: unknown
sub  4096R/9875F234  created: 2010-02-02  expires: never       usage: E
[ unknown] (1). Test User (Do Not Use)

pub  4096R/A0503C60  created: 2010-02-02  expires: never       usage: SC
                     trust: unknown       validity: unknown
 Primary key fingerprint: DB0A 6208 7277 4505 69F3  2DDE 7F5F C5A5 A050 3C60

     Test User (Do Not Use)

Are you sure that you want to sign this key with your
key "Matthew Gadd (Dark Otter) " (C6E53A2D)

Really sign? (y/N) y

This indicates to me, and anyone else, that I trust this key to be Bob’s real key. I then give the signature back to bob, either by exporting his public key from my keyring and then sending him the exported key (which will contain my signature), or by uploading the new version to a keyserver for him to retrieve (this is considered less polite than the former option however). Bob can re-import his key from either source, and GnuPG will import the signature I made, but preserve any modifications he has made separately.

If I sign Bob’s key, and he signs mine, we now can communicate securely with trust. But what if I want to communicate suddenly with Alice? I have never met Alice, so I neither know her public key, nor can trust any of the keys available for her e-mail address. However, the second part of the solution deals with this.

GnuPG (and PGP) both keep a trust database, which builds up a web of trust. After having signed any new keys (or after having downloaded updated public keys from a keyserver) I run:

gpg --update-trustdb

This tells GnuPG to process your trust database and signatures, semi-interactively. If there are any keys which you have signed and not yet set ‘owner-trust’ it will prompt you to set it. Owner-trust is distinct from trust/validity. Whereas trust/validity indicate how well I can trust Bob’s key to be his, owner-trust indicates, as the name suggests, how much I trust Bob. I can choose to trust him fully, marginally, or not at all to sign other peoples keys. If I trust him fully or marginally (partially) then I can start to build my web of trust.

For the example, if I decide I know Bob well and he is careful, I decide to trust his key fully. Then, when I want to send an e-mail to Alice, fortunately Bob has verified and signed Alice’s key. Because I have decided to trust Bob’s signatures (including the one on Alice’s key), I know which key is Alice’s real key, and I can send her a message easily without having met her.

This particular example does seem pretty tortuous, but given that you can have your key signed by an unlimited number of people, and they can also sign the keys of many people, it is possible to build up a large enough ‘web of trust’ to be useful. It would require many key-signings between you and other people, but gradually one can be built up. If you have your keys signed by people who are already part of other webs of trust, your area of trust can grow rapidly.

The difference between full and marginal trust depends to a certain extent on user customisation. You can customise the options for how many signatures and of what level a key needs to be considered valid by GnuPG. By default, if a key has either been signed by one user you fully trust, or 3 people you trust marginally, GnuPG will consider it valid. But these options can be changed to make GnuPG more or less paranoid, even requiring multiple fully trusted signatures to consider a key valid.

Community Responsibility

However there is one responsibility that comes with all this.

You must NEVER sign a key unless you are really sure it is genuine

Allow me to explain a little. You can set owner-trust values to whatever you like, as these are only used by you, and are not exported to other people. However, when you sign a key, this signature is visible to the world.

The problem would occur like this. Suppose I have signed Bob’s key, and decided I trust him fully. However, what if he now betrays my trust in him by signing a key without carefully verifying it. Eve wants to read Margery’s messages, and so she creates a fake key for Margery. She takes this key to Bob, and claims she’s forgotten her passport. Bob, rather than being careful decides to sign her key anyway. Here Bob is violating the responsibilities of the community, because he has not checked that the key belongs to Margery. Because I fully trust Bob, the key supposedly for Margery will be valid according to my GnuPG, and if I try to send her a message, Eve will be able to intercept and read it.

This is why you must only ever sign a key if you’ve checked it carefully. You can set owner-trust to anything you like, and you can actually set owner-trust without signing a key if you want to treat a key as valid (and as part of your web of trust) but without making a public signature. As much as this is insecure for you, GnuPG is flexible and will let you use whatever level of security you elect to. However, it is important you never sign a key unless you have carefully checked it, because this is the one action in GnuPG that can compromise security for people other than yourself.

Next Time

That conludes today’s post, and with that post I have now completed the first part of this guest series, dealing with GnuPG. I have now (I hope) covered the basics of GnuPG, if any of you have any questions feel free to contact me. There are things I intentionalyl have not covered, such as revoking GnuPG keys, and I may cover some of these topics if any of you wish me to later.

I’m going to be away for a few days, so my next post may (or may not) be a bit delayed. When it does come I intend to write it on methods for estimating password strength. So stay tuned for that. Until it does come however, I’m sure TmacUK himself will keep you entertained with his many posts and bugs, and have fun using GnuPG.

My GnuPG Key

As mentioned above, I’m perfectly willing to take questions by e-mail, and I may even check the comments on this site occasionally. However, as we’ve just been using gnuPG, why not use it to send me a message? As of course you have not met me, you cannot trust (and absolutely musn’t sign) my key. However, you can still send messages with an untrusted key (although GnuPG will warn you about doing this).

If any of you wish to acquire my key, there are two easy ways. The first is to get it from a keyserver:

gpg --keyserver pgp.mit.edu --recv-keys 0x6D5922FB54465F55CB17662D43741CE0C6E53A2D

Or, if you prefer a more direct approach, you can obtain it from my blog (as described there):

wget -q -O- 'http://montemazuma.wordpress.com/about/' | gpg --import

This is actually quite a neat hack, because the page at http://montemazuma.wordpress.com/about/ is both a valid HTML page (with its own content apart fom the key), and a valid copy of my GPG public key.

Either way, once you have obtained my GnuPG key, you can use it to encrypt a message to me at hello@darkotter.com. Enjoy, DO out.

Bonjour tout le monde, et bienvenue a la troisiemme ‘post in this series’. I can’t really speak French. This week it’s time to engage in some actual encryption, although only to ourselves at this point.

Encrypting a Message Symmetrically

GnuPG can also be used to do standard symmetric encryption. This is simply standard encryption with no use of public keys, you type a passphrase in when you encrypt the file, and anyone who knows (or can guess) that passphrase can use it to decrypt the message. To do this in GnuPG simply execute (in a terminal):

gpg -c {FILENAME}

It is worth noting that it is possible to encrypt a message using GnuPG so that it can be decrypted with multiple private keys, and or a symmetric passphrase. To do this, simply add the -c option in with the other options for the other commands to indicate that you want the message to include symmetric encryption.

Encrypting a Message Asymmetrically

Much like the -c switch, to specify that you want a message encrypted asymmetrically (public key encryption) you simply have to add a short switch, in this case -e. The trick with encrypting a message asymmetrically though is specifying the recipient. This can be done in two ways. Firstly, if you do not otherwise supply any recipients, GnuPG will prompt you for them when you run the command. The second option is to specify each recipient on the command line, using the -r switch.

So, to encrypt a message and be prompted for recipients execute (in a terminal):

gpg -s -e {FILENAME}

N.B. I’ve added in the -s switch here because you really should use it – see the signing section below.

If you would rather specify each recipient on the command line you can, for example:

gpg -s -e -r hello@darkotter.com -r test@example.com

Note that, provided you added all the configuration to your gpg.conf file as discussed in the last post, whenever you use the -e switch you will be added as an extra recipient in addition to those you specify for the message, so you will be able to read any messages you send (handy for e-mail so you can still read them in your sent items folder), and if you should wish to encrypt something to yourself you need not specify yourself as a recipient (simply hit enter when GnuPG prompts you without entering any recipients).

Signing a Message

The other major operation that you can perform with GnuPG is signing a message. This uses your private key to sign a cryptographic digest (much like a fingerprint of the message) so that anyone who has a copy of your public key can verify that you made the message in question, and it has not been modified since you made it. The switch to indicate the message should be signed is -s, and it can of course be mixed with the other operations witches discussed (and usually is, it is considered usual to always sign any message that you are encrypting asymmetrically using -e, so much so that these options are usually supplied together as -se). You can also use it on its own:

gpg -s {FILENAME}

This might be useful if for example you wanted to make a public message, but show that you made it, much like your real signature on a public document. However, there is a problems with doing this, namely, people can only easily read the file this creates using GnuPG. Although they do not even need your public key to read the message (although it’s publicly available anyway of course, so they can easily acquire it to also be able to validate your signature), they do need GnuPG to process it as the file created is in the OpenPGP binary file format, and not everybody has GnuPG installed.

There is however a way round this, namely clear-signing. Unlike the other operations discussed so far, clear-signing can only be performed on it’s own as a single operation. It also modifies the file you give it directly, so be sure to try it out on something not too valuable first. Clear-signing adds a GnuPG/PGP signature to a file which can be verified using GPG or other PGP software, but it does it in such a way that the original content of the file is human readable. For example:

gpg -o- --clearsign msg.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

hello world, this is Matthew Gadd speaking.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCgAGBQJLbvTmAAoJEEN0HODG5Tot/YUQALOOsR6GrAXFBDn+X5Zi+zv/
+gcihRcKr8gqmUOCvvTd6vmLKWijM+XRIqRnGWST7H97UkC11eh4VmiHjfaGRWED
DzSvIPqvd3L7rzSvwqb/6Ir/dm6ylG2EbRjp+enZMbIhNiphXiC/B5OfsdoSLjNz
FEh5hckE/p/ad1rdaY70GyJn4gHn3YCYrGldBBK/qWh28QAlngzR7XfH27k3HJBY
lzAX8xowG38YzMaXQf3N2ptm/GE6Ewcug9MIz7Ccep4JtuKvaZXNKiXnzONl1jOK
rjSAUBOM2tkk8Gl4tDOJIddh5gTXCU0oCk9/WI2DV2YHG5qU+U6nn5OIlonBUJ6a
1+DsK2n5US7a9+rB2+xlV/fm+yPS4YDFvtd0tpmydHn0ciSS/Nrv7bjvZcr3Mh8R
bE8dM1GXVVlGivQCssVuexacgGq0r6FNbaU903+bnOM1h6aAr0MRFtsXQtYLeKpN
LcbTv3JaEML9Lo91JeimzjOi9QlbUeGjgeHbgiesUy9oay/zkufcy5s/VlI4d/2T
pHFwuAb9pNONet+iVF/cAxhJ0LR97CLQM1T4o3FkWgs+fdUUsyfgAL3r9SZd3g8T
iwtc0WV8YsHiSAr6WoagyGNxhJ8anOOj4SVWbOtbx8UHXNlc+AaobBOLOqz6GilZ
tVyWa7BU8UOE0XWTGsaL
=74RL
-----END PGP SIGNATURE-----

This ensures that the message can be verified, and the message is still readable. This is commonly used in e-mails to mailing lists, so those with GnuPG can verify the sender of the messages, but other people on the mailing list who may not have it can still easily read the message.

However, this signature has still modified the file which poses a problem. For instance, what if you wanted to distribute an announcement as a pdf file, and wanted to sign it but have it readable by everyone. Clear-signing it would corrupt the pdf file, and signing it normally would mean that only those with GnuPG or other PGP software could read the (un-corrupted) announcement. However, there is a third option:

gpg -b {FILENAME}

The -b option is the short option for the detached-sign operation. This creates an additional file (by default named the same as the input file, but with .sig as a suffix) which contains the signature. This means that you have to distribute two files if you want the signature to be available. However, the original file is unmodified (so anyone can still read it easily, and binary files will remain uncorrupted, source files can still be compiled etc.), and anyone with PGP software can run it on the additional file containing the signature. GnuPG will then search for the file that has been signed (according to the filename stored in the signature, and it will prompt you for the files location if it cannot find it) and then check the signature against the data in the file. This form of signing is commonly used to verify the integrity of tarballs available for download - the signature file is also made available for download, and users who wish to verify the download can obtain this in addition to the tarball in order to verify it.

Mixing Operations

The first three operations we have discussed (symmetric and asymmetric encryptions, and signing) can all be mixed for the same message simply by adding the options together. For instance:

gpg -c -s -e {FILENAME}

Will produce a message that can be decrypted with the passphrase you specify, or it can be decrypted by any of the recipients you supply using their private keys, and once decrypted by either message it can be verified that you were the author of the message.

Clear signing and detached signing cannot be mixed with any other operations however - this is simply due to the nature of what they do and trying to use a method of signing designed to keep a message easy to read in addition to encryption would of course not make sense.

The PGP format

All of these operations (including clear signing and detached signing) create files which are in the OpenPGP format. Excepting clear-signing they all create files in the binary format by default (for detached signing, the signature file is binary although the source file may not be). However, there is also an ASCII variant of the OpenPGP format (which basically consists of the binary data encoded in base64 and wrapped in headers to indicate that it is an OpenPGP message).

In order to create a file in the ASCII format, simply add the -a switch in addition to other options, for example:

gpg -a -s -e {FILENAME}</code

Whereas normally GPG creates files with the .gpg or .pgp extension, when the ASCII format is used the generated files will have the .asc extension. The main advantage of the ASCII format is of course that it can be safely transmitted over mediums which only support the transfer of ASCII data (for example e-mail - your e-mail client encodes binary data in base64 for you when you send attachments to work around this). However the disadvantage of it is that any message will be longer in the ASCII format as the base64 encoding increases the length of data it encodes.

In general I choose which format to use based on the following rules. If it's for an e-mail, always ASCII (although like most Linux e-mail software, my e-mail client handles the encryption and this choice for me anyway). If it's not for e-mail and it's a large-ish file (more than about one megabyte) then use the binary format. Otherwise, always use the ASCII format (just in case).

Ease of Use

It's worth noting, that while using GPG from the command line is very versatile, for many people it's not the easiest option. Fortunately there are many frontends for GnuPG and PGP that integrate it into various pieces of software.

Most Linux e-mail clients (including Evolution which I use) support GPG natively - once you've set up your key, you simply tell the e-mail client which key to use for your e-mail account, and then you can choose to encrypt a message, and it will handle constructing the encrypted e-mail for you (PGP has it's own PGP/MIME extension to e-mail formats which can be used, similar to S/MIME for X.509 security), and will supply GPG the recipients of the message from the e-mail recipients you entered. Clear-signing is also supported by most, and is often enabled as the default for all messages by some people.

I note (mainly because of its popularity) that Thunderbird does not support GPG itself, although this may be because excellent support for GPG can be added to Thunderbird by installing the EnigMail extension. IIRC, EnigMail also supports helping a user to generate a private key without using the command line (although I recommend using the command line as described so we can set our own security options).

As for encrypting or signing files, there are many graphical frontends available for GPG to do this. My favourite, which is available for the GNOME desktop, is Seahorse (which you may recall me instructing you to install earlier). Seahorse provides a nice GUI for managing your keys, as well as a passphrase caching agent. For file encryption it integrates with Nautilus (GNOME's default file manager) so that you can right click on any file and select to encrypt or sign it (or decrypt if it's already encrypted). Seahorse provides graphical prompts for recipients and other details so that the command line need not be used at all for most encryption tasks. Seahorse also provides a plugin to GEdit (GNOME's default text editor) which allows you to encrypt, sign, or decrypt ASCII format PGP messages simply by selecting them in GEdit and clicking the appropriate button.

Next Time

That concludes today's post, I hope you found it interesting, and possibly even useful. In the next post I plan to cover how to obtain other people's public keys (as well as how to tell whether you can trust them) so that you can use these techniques to send messages to other people.

DO out.