OpenPGP: How I Sign Keys
11 May

OpenPGP: How I Sign Keys

Signing is a very personal thing. You are telling the world you believe a key belongs to the person who is claiming it. The value of a web of trust comes from the fact you are willing to put your reputation behind this assertion.

Everyone will treat signing differently. Some may feel bumping into someone at a conference is sufficient, other may want a full DNA breakdown with supporting evidence from three expert witnesses. I like to think I’m somewhere in the middle and have documented my signing policy. This page is about how I sign a key and what you need to do next.


In order to sign a key you need the master key, and as detailed in my key creation guide I keep my master key separate from my normal key store, so can not do any signing during events. Instead I sign all keys at home then get the signed public key back to you for you.

The Act

Like all repetitive tasks I have created a script for that which you can download from its project page. The script does five things:

  1. First download the key to be signed into my keystore
  2. Sign all key identity’s associated with that key
  3. Export the signed public key
  4. Encrypt it
  5. Finally the script deletes the signed public key from the keystore and re-download the unsigned version from the public key


Now I have an encrypted file containing your key I have just signed, but I do not have a signed copy in my key store. My preferred way of getting a signed key to you is by email. Since I have encrypted the signed file you have to have access to the private key and email address in order to use it and I feel this adds a level of additional verification that you really do have control of the key I just signed, after all there are many reasons you might not – I mean I could have just signed the wrong key.

You have noticed my bash script now leaves without a signed copy for you key, this was a deliberate step. I said above by emailing you I am able to assure myself I have not only signed the right key but you have access to the correct email box. Once you import the key and push it back out to your key server I will retrieve a copy from there.

What do you do now?

If you receive a signed key from me you simple need to run the following command:

PGP will ask for your password and import the new signed key and verify the attachment was signed with my primary key fingerprint: BB2C EB25 BE05 16A7 A9C6 F2FB EEB4 96E6 1FA1 E814. It is now up to your to send your newly signed key back to a server for the rest of the world to see.

OpenPGP: My Keys
03 May

OpenPGP: My Keys

Its May again and the sun has finally made an appearance. With summer comes the regular spring clearing and it seems as good a time as any to update my public encryption keys. My previous keys were cryptographically less secure, 2048-bit compared to 4096-bits. I have also learnt allot more about best practices when managing keys and feel its about time to put everything I’ve learnt into affect.

My Secondary key 0xB784045B remains the same. This key was and has always been stored off line in a TrueCrypt volume using a 4096-bit key so I always have been, and still remain, confident about its security. I am replacing my Primary key using the full key creation and cross signing guide. This new key is also covered by my signing policy.

My OpenPGP Keys

Bellow is listed my current PGP keys including my Primary-key and Secondary-key. The Key id is a short identifying mark for all keys. It is made up of two components separated by a slash. The first identities the strength and algorithm of the key, so 4096R means its a 4096-bit RSA key. The second is the last 8 digits of the key fingerprint. These are the short form of identification. The keys full identification is its fingerprint, 40 hexadecimal digits.

The key also publishes its creation and expiry dates. All my keys will expire – encase of loss or compromise – however it is my intention to continue extending the expiry date for as long as I feel confident of their security.

Primary OpenPGP Key


The key mentioned bellow (and on /about/me) is my main key, for every day use. It can be considered acceptably-safe, as I take grate care in assuring it remains that way. However, since it is my main key it has to be store on other devices such as laptops, mobile phones and tablets. This opens the key to danger from theft.

Following the advice in the Debian Subkeys wiki I have created separate subkey for signing. This mean the key stored on my devices does not contain the master key – this is stored separately on a TrueCrypt volume in an offline laptop which doesn’t leave the house. Key signing is still done using the master key which means I can not do it during any key-signing events, I have to do it once I get home again – See my full key-signing policy for how I manage this.

The most recent version of this keys is available from the key server at or for PGP Key: 0x1FA1E814 (72 downloads) , it is also returned by my DNS server. If you issue the command dig +short TXT the returned key should match that provided here.

If there ever comes a time when I can no-longer assure my self of this keys security/integrity I have revocation certificates stored in a number of safe locations.

pub 4096R/1FA1E814 Created: 2014-05-04
Key fingerprint = BB2C EB25 BE05 16A7 A9C6 F2FB EEB4 96E6 1FA1 E814

SmartCard OpenPGP Key


The most recent version of this keys is available from the key server at or for PGP Key: 0xB7266A16 (62 downloads) .

If there ever comes a time when I can no-longer assure my self of this keys security/integrity I have revocation certificates stored in a number of safe locations.

pub 2048R/B7266A16 Created: 2014-05-04
Key fingerprint = 0E06 2B0D 4E2D BE43 29B9 1C01 9FCD F90A B726 6A16

Secondary/Alternate OpenPGP Key


A second key is also available, which can be considered extremely-safe and is never stored on any computer (the keys are located on a TrueCrypt protected USB drive stored in a safe location) or ever been transmitted over the any internet connections, so please be patient if you requires a reply.

This keys is available from the key server at or for PGP Key: 0xB784045B (63 downloads) .

For verification purposes my other keys is always cross-signed with my secondary key.

Feel free to use the following public key if you are concerned or paranoid about what you wish to send to me, however if you are in doubt you should probably use my primary key instead.

pub 4096R/B784045B Created: 2011-09-19
Key fingerprint = 2642 7F79 DA14 44C4 CBE9 23BB 22C7 2B37 B784 045B

Chairman of The Software Society OpenPGP key


Since April 2012 I have held the position of Chairman of The Software Society Ltd. On the 23th of March this year, 2013, it was decided that the board of directors and office bares (Chairman, Company Secretary and Chief Financial Officer) should all create an use OpenPGP keys for all official business.

It was also decided that each office barers key should last as long as they are in office, the new incumbent creating a new key apon their election.

To this end, during my time in the post my key will be 0x69AA4946 and will be subject to the same signing policy as I has been in use on my personal key.

pub 2048R/69AA4946 Created: 2013-03-24
Key fingerprint = CFAE 70BC 1735 BF50 C993 DACB 6415 6795 69AA 4946

Retired Keys

I have been using PGP on and off since about 2008, in that time many keys have come and gone and I did not set expiry dates on most of them and never thought to generate or use revocation certificates. The nature of OpenPGP and the Web-of-Trust means there is no way retrospectively to remove these keys. The best I can do now is list them here. Do not use any of the keys listed bellow. This is not a complete list, only the ones I can no longer revoke.

0x5DCC0296, 0x541784DD, 0x132DED8D, 0xC5751341, 0xCB52DED2, 0xC941927D, 0xDFA274F2, 0x9F9A8CE0,0x2DF1892D, 0x843D80BA, 0xA7EEB609

OpenPGP: How does PGP work?
03 May

OpenPGP: How does PGP work?

How does it work

The magic, and I call it magic because I freely admit I do not have the mathematical background to explain it better, of this system is that if you encrypt something using the Public-key only the Private-key can decrypt it and vice versa. So there is no way for someone holding the Public-key to decrypt something encrypted using the Public-key, only the Private-key will decrypt it. The same is true in reverse. If something is encrypted using the Private-key only the Public-key can decrypt it again – in practice you won’t have a problem here, because if you hold the Private-key you already hold the Public-key as well.

Now when I write an email and want to sign it PGP looks at the message or file (for simplicity I’ll stick to email as my example) then runs a mathematical hash such as SHA256. A hash is a one way process. If you hash a block of text, using SHA256, you will get a string of what appears to humans as gibberish. The important part is, it is always the same. No matter how many times you run the same block of text through the SHA256 algorithm you will always get the same gibberish. PGP then uses my Private-key to encrypt that hashed result and includes that ether as an attachment to the email or at the bottom of the body.

To verify the integrity of a email the receiving PGP aware application uses the Public-key to decrypt the attached signature and reads the included hash. At this point you have already verified the signature was created using the Private-key because if it had been altered in any way after encryption the Public-key would no longer work. The next step is for the receiving copy of PGP to run the email through the same hash as before, SHA256, and then compare the hash encrypted in the email with the hash it just created. If the two match the email has been verified and you can be sure it has not been altered in transit.

How about encrypted messages

The process for full message encryption is slightly different. The problem with Public-key cryptography is it is incredibly expensive in computational power and CPU time and far large messages it is impractical to encrypt the whole message using a Private-key, so instead we use Symmetric-key encryption. Unlike Public-key encryption Symmetric-key encryption uses the same key to encrypt and decrypt a message.

So now when I send an encrypted message PGP signs the message in the same way detailed above then generates a large random password then uses this to encrypt the message. Now we have an encrypted block of text and a key to decrypt it again and we have to get both to the recipient without the decryption key becoming public, so we call on Public-key cryptography again. Using the recipients Public-key we can no encrypt our generated Symmetric-key and include it in the email header. At the other end the recipient uses their Private-key to decrypt the start of the email then can use the Symmetric-key we provided them to decrypt the message. This actually allows you to send the same email to multiple recipients as well, all we have to do is use the public-key of each person to encrypt a copy of the Symmetric-key.

Why Isn’t It Used More

PGP key management is hard work. Generating key, managing them and adding support to email applications that do not already support them is not for the faint hearted and the process is quite geeky. So while support is there its not easy to use, in simple terms it doesn’t yet pass the granny test.

I hope this will change in future and by signing the majority of my messages and writing these posts I would like to think that I can make it a little easier to get involved. Cryptography and PGP technique in particular is a subject I am interested in. I have given several talks to The Software Society (my local LUG) on the topic and plan to give another over the summer in the hopes of increasing awareness to my little corner of the universe.

If you have any questions or struggle to implement PGP in your own corner please drop me a line and I will do the best I can to help. Even if, like me, you see no reason to encrypt your emails the advantages of being able to sign your emails is huge deal in a world of spam and viruses being distributed by email – often appearing to come from an address you know.

OpenPGP: How do I create a OpenPGP Key?
03 May

OpenPGP: How do I create a OpenPGP Key?

Creating a Secured Key

When you build a PGP key you going to start using that key to verify your identity, so like all other forms of identification you have to protect it. Unfortunately to make PGP usable you cant permanently store you private keys locked in a safe, you actually need a copy of it one your computer, phone, table, laptop, basically any place where you want to send verified emails or decrypt messages you receive.

So what do you do if you phone or laptop are stolen? Even if you have secured your private-key with a strong password it is still at risk from someone with direct access to it.

Protection Using Subkeys

There isn’t allot of information on web about how to secure your key in this situation. I was able to find a few reference sites most notably the Debian Wiki about Subkeys.

When you create a OpenPGP key you are creating one key for signing and another for encryption. Its the signing key that is your master key and the one you need to protect. So after creating a new OpenPGP key you can create a new subkey just for signing.

This way the only things stored on your mobile device are your encryption key and your signing-subkey. If you lose control of your laptop, but still retain control of you master key, you can revoke the sub signing and encryption keys and create replacements.

If an attacker were able to break your password they would get access to anything encrypted before you revoked the key but nothing after that point. They could also only sign emails and files using the subkey you just revoked and any receiving PGP application would see that the key used to sign the message had been revoked and not validate the signature.

So how do we do it?


Creating the Keypair

Use the gpg --gen-key command to create the new keypair

You will be prompted to enter a password, its a good idea to make this a secure one; hard to guess and one you want forget. Keep it safe. If you lose your password you could lose control over your key and will have to start again.

Preferred Hash

PGP uses hashes through the signing and encrypting process, I’ve better explained this on the “How is works” page. To strengthen your key you can set your preferred hashes. This is useful because as time moves on and computers become more powerful weaknesses are being discovered in previously thought secure hashes such as SHA-1.

Use the gpg --edit-key command and when prompted enter the commandsetpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed, then save.

Subkey for Signing

OpenPGP subkeys work the same as normal (master) keys, expect they are mathematical related to the master key and they can be used for signing or encrypting. What makes them special here is they can be revoked and store independently of the master key.

Again use the gpg --edit-key command and type addkey. Select a sign only key, ether 3 or 4 depending on if you want to use DSA or RSA. After the new key is ready type save.

Revocation Certificate

Since we are creating subkeys we do not have to worry about theft of a laptop or phone. In that case you could still use your master key to revoke only that subkey. What I describe bellow is when you lose your master key and must revoke everything.

If you ever lose your private key you will have no way of generating the revocation certificates needed to revoke your new key. So best practice is to generate those certificates now and store them in a safe place encase you need them later.

You can do this from the command line with the command:

However I has also worked on a bash script that can automate the process of creating these certificates. More information on this is available from the project page.

Export The Final Product

Now export your keypair. You can export both the private-key and public-key using these commands:

You should protect these two files. Do not keep them on your laptop of mobile. The private file we exported contains your master key. Losing this could compromise your entire keypair.

Creating your Laptop Key

Now that your master key is ready you can create your laptop key. GPG does not make this easy, but with a little trickery you can make it work. These instructions assume you have created your master key on your laptop, if you have created your key on your desktop machine you can just skip the step two and not delete your secret key.

  1. Start by exporting your subkeys gpg --export-secret-subkeys 1FA1E814 > 1FA1E814.sub.gpg
  2. Next delete the master key from your key ring gpg --delete-secret-key 1FA1E814
  3. Now reimport the subkeys back into your keyring, or if you are not working from your laptop just import the subkeys theregpg --import 1FA1E814.sub.gpg.

Using your new key

You can now use your laptop keypair to sign, decrypt or encrypt emails and files. If you want to sign someone else’s key or revoke a subkey attached to your mast key you need to use the original master key.

Now that your key is ready for public consumption your can start sharing it. You can distribute your key anyway you like, but the simplest solution is to send it to a key server:

There are hundreds of key servers online, but you don’t need to send your key to all of them. In most cases any key server you use will distribute your public key across all the others. This process is fully automatic but it can take a few days for your key to appear on them all.

OpenPGP: Encryption should be easier than this
02 May

OpenPGP: Encryption should be easier than this

Why I Digitally Sign My E-Mail

Most e-mails I send are digitally signed using a process called “Pretty Good Privacy”, commonly referred to as PGP or GnuPG. PGP has been around since 1991 yet still is not commonly supported by the majority of email clients, at least in the Microsoft echo system, or webmail applications like Gmail or Yahoo Mail. When a digitally signed email is displayed in applications that do not support PGP you may see one of two things; either there will be an attached PGP.sig file or the message may start with “BEGIN PGP SIGNATURE” and appended to the bottom of the text will be a block of gibberish text. These components are used by PGP aware applications to cryptographically verify the identity of the sender. If you also have or use PGP I could send you encrypted email so that only you can read it. Over the next few pages I will give some background on PGP and why I use it.

Email Attachments

Since implementing PGP in my in all my email clients I will no longer open attachments or click links in unsigned emails. Like all security mined people this rule will no doubt cause problems for some and will make the internet a less user-friendly place, but with the amount of spam and viruses delivered by email – often coming from addresses you know – there is no better protection available, likewise I will never send an attachment unsigned.


In 1991 PGP was created by Phil Zimmermann as a way to digitally sign or encrypt messages and file. This is achieved using Public-key cryptography. When you create a PGP key you are creating two very large numbers that are mathematically related, but due to the size of these numbers it is not possible to derive one from the other. So you now have two keys, one considered private the other public and as the name suggests who must keep the Private-key secret from everyone but you can share the Public-key with the world.

I was planning to include a section on this page detailing how PGP works but as I started writing it quickly grew beyond the scope I had indented this introductory page to be. If you are interested in the propeller hat explanation of how PGP can encrypt and digitally verify messages you can find it on at the “How does it work” page.

My Keys

My public keys are published all over the net; on key servers, in my DNS records, on this site on my “OpenPGP Keys” page and on some mailing lists. That is the way you want your public keys after all.

OpenPGP: GPG Cheat Sheet
24 Mar

OpenPGP: GPG Cheat Sheet

You can’t have enough cheat sheets on the net. Well you probably can, but I still wanted to add my own to the mix. I use the GnuPG command line for almost everything, bar actually sending email so this is a nice little reminder to myself what I’m doing

Creating a new Key First steps

gpg --gen-key

Browsing your keyring What have you got
  • List all public keys gpg --list-public-keys
  • List all private keys gpg --list-secret-keys
  • List everyone who has signed a key gpg --list-sig (0xKEYID)
  • Get the full fingerprint gpg --fingerprint (0xKEYID)
  • Export your public key to a file gpg --armor --export (0xKEYID)
  • Upload a key to the keyserver. Good for new keys, or after signing someone else’s
    • Using the default Key server gpg --send-keys (0xKEYID)
    • Specifying a Key server gpg --keyserver --send-keys (0xKEYID)
  • Export/Backup you private key `gpg –armor –export-secret-keys (0xKEYID)
Searching for a key
  • Finding someones key
    • Using the default Key server gpg --search-keys
    • Specifying a Key server gpg --keyserver --search-keys
  • Encrypt a file for someone, by their email gpg --encrypt filename.txt --recipient
  • Encrypt a file for multiplie people, by their email addresses – It’s usually a good idea to encyrpt to your own key as well or you will not be able to decrypt the file latergpg --encrypt filename.txt --recipient --recipient
  • Encrypt a file for transmission over text – email, IRC, Jabber etc.gpg --armour --encrypt filename.txt --recipient --recipient
  • Decrypting a file gpg --output filename.txt --decrypt filename.txt.asc
Import keys You need to get them somewhere
  • Importing from a text file gpg --import publickey.asc
  • Restore a backup of a private key gpg --allow-secret-key-import --import privatekey.asc
Keys Maintenance Revoking
  • Creating a revocation certificate. You must has the private key to do this, if you have lost your private key, well thats when problems kick in gpg --output revoke.asc --gen-revoke 0xKEYID
  • To revoke a the key all you need do is import the revoke.asc into your keyring gpg --import revoke.asc
  • To make sure everyone knows your keys been revoked you need to publish the updated public keygpg --keyserver --send-keys (0xKEYID)
Keys Maintenance Key Signing
  • You need to edit the key gpg --edit-key 0xKEYID

From here ‘help’ will give you a list of your options, but to sign a key you can ether type ‘sign’ or ‘tsign’. The man pages give a better indication of what the difference is ‘man gpg’ but ‘sign’ is usually sufficent. After they key is signed type ‘save’ and ‘quit’ then you can ether send the key to a keyserver for download by its owner of export the public key and send it by other means, this usually means encrypted email.

Signing and Verifying files
  • To sign a file with your default key use this gpg --detach-sign --armour filename.txt
  • To verify a signed file but put the output from above filename.txt.asc gpg --verify filename.txt.asc
OpenPGP: Key Signing Policy
19 Feb

OpenPGP: Key Signing Policy

Since April 2012 I have held the position of Chairman of The Software Society Ltd. On the 23th of March this year, 2013, it was decided that the board of directors and office bares (Chairman, Company Secretary and Chief Financial Officer) should all create an use OpenPGP keys for all official business.

It was also decided that each office barers key should last as long as they are in office, the new incombant creating a new key apon their election.To this end, during my time in the post my key will be 0x6415679569aa4946 and will be subject to the same signing policy as I has been in use on my personal key. This is detailed bellow.


This policy is valid for all signatures made by the following GnuPG keys:

The most recent version of these keys are available from the key server at or for download from My GPG Page

This policy was first written on 2011-06-22 but the polices listed here have been followed since the creation of the key four days earlier on the 18th. Content and structure of this document are strongly based on the OpenPGP Key Signing Policy of Marc Mutz (Link no longer available) and Jörgen Cederlöf (Link no longer available) but have been slightly modified from the original sources.


I live in Dundee (Scotland) and am available to sign keys any time. If you want to arrange for a key-signing, your best chance of meeting me is in or near Dundee. Occasionally I’m in St.Andrews, Cupar and Perth. I can be reached thru the/feedback form on this site, Just be sure to include the phrase ‘key-signing’ in the subject line. I am also listed at, a webpage about key signing coordination. Meetings at computer related fairs are possible as well.

Usually I keep track of upcoming events where it would be possible. So if you would like to meet in order to sign keys check my events diary to find out where I will be.

Prerequisites for signing

The signee (the key owner who wishes to obtain a signature to his/her key from me, the signer) must make his/her OpenPGP key available on a publicly accessible keyserver (see above for example keyservers).

The signee must prove his/her identity to me by way of a valid identity card or a valid driving licence. These documents must feature a photographic picture of the signee. No other kind of documents will be accepted. This also implies that the signee’s key must feature his/her real name in order to be checked up on his/her identity card. A key which only contains a pseudonym will not be signed.

For people from outside the European Union I will check both of these two tokens (since I cannot assess their risk of fraud). Exceptions may be made if there is a good reason for me to do so.

The signee should have prepared a strip of paper with a printout of the output gpg --fingerprint 0x12345678 (or an equivalent command if the signee does not use GnuPG) where 0x12345678 is the key ID of the key which is to be signed.

A handwritten piece of paper featuring the fingerprint and all UIDs the signee wants me to sign will also be accepted.

The above must take place under reasonable circumstances (i.e. ourselves not being in a hurry, exchanging key data at a calm place and so on).

The act of signing

After having received sufficient proof of identity I will sign the signee’s piece of paper myself to avoid fraud, and eventually sign the signee’s key.

The signed keyblock will then be mailed to the signee, or uploaded to a keyserver if expressly wished.

Key signing is performed on the understanding that the act of signing is mutual. If the signee fails to sign my key in return I reserve the right to revoke my signature from their key.

Signing requests of transitions to new keys

I have been asked what my position is towards requests from people (whose keys I had already signed) to also sign their new keys.

In principle, I agree to the procedure when I am reasonably sure the request is not bogus/a scam, and the following conditions are met:

Any signing request of transition to a new key

  • must at least be signed by the still valid original key (which I also signed),
  • the new key must also be signed by the still valid original key (which I also signed),
  • the owner of the new key must cross-sign my keys in return with the new key first,
  • the new key will receive the same level of signature as the still valid original key (which I also signed).

However, such a signing request may be declined without giving reasons. If unsure, enquire first.

Levels of signatures

Level 0

A level of 0 is given to keys of Certification Authorities since in most cases the key owner is a whole organization and not a single person. Usually the fingerprints of those keys have to be verified by getting them from the corresponding website of the CA and cannot be checked by exchange with a member of the CA who is in charge. These signatures are the weakest in my web of trust.

Level 1

If I have had contact with someone through signed or encrypted e-mail over a time long enough to rule out at least temporary man-in-the-middle attacks, and I have verified the key with a key downloaded from his/her personal web page, or signed emails/fingerprints on public mailing lists, but I have not met the person or verified the key in any other way, I may sign the key with cert check level one.

Level 2

A level of 2 is given to sign-only keys. It is not clear to determine if the owner of the mail account is the same as the key owner because encryption cannot be used, hence the signatures only receive a lower level of 2.

Level 3

A level of 3 is given to sign-and-encrypt keys: I have met the signee in person, I have verified his identity card (passport, or driving licence) and his key’s fingerprint. I was also able to send my signatures encrypted with the corresponding key of the signee. These signatures are the strongest in my web of trust.

Photographic UIDs are also going to be signed with a level of 3 if I can still remember the signee’s face when I will be back at home.

I will also sign keys at level 3 when I know the signee personally, I do not require ID card or the above formal procedure. A meeting where we exchange fingerprings is enough. Naturally, it would be extremely hard to trick me into signing a false key this way.

Here are some links which you may find useful or interesting: Key signing policies of other people:

Change Log

  • Version, 2014-12-14 – Content migrated to new markdown site
  • Version, 2013-09-21 – Applied this policy to my smartcard key
  • Version, 2013-03-25 – Applied this policy to my second key
  • Version, 2013-03-22 – Removed dead URL from links
  • Version, 2012-01-19 – Content Recovered from Google Cache
  • Version, 2011-11-30 – Initial Release.