You are viewing gagravarr

Nick - Creating a 8192 bit GPG key to replace my 1024 bit one [entries|archive|friends|userinfo]

[ website | ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Creating a 8192 bit GPG key to replace my 1024 bit one [May. 9th, 2009|05:00 pm]
As some of you will have heard, there's been some new research into the security of the SHA-1 hash, which has found a faster way to locate collisions. Couple that with the NIST Guidance that US Government agencies should transition away from SHA-1 to stronger hashes by 2010, and you have a fairly strong reason to migrate away.

My GPG key from 2003 to know has been a 1024 bit DSA key, which uses a 160 bit SHA-1 hash. As per the Debian Guidance, this isn't ideal, and I (along with many) have decided to move to a new, stronger key with a stronger hash.

Bruce Schneier, in Applied Cryptography, has recommended a 8192 bit key if you want it to have a useful lifetime beyond 2015. Since changing GPG keys is a faff (new keys, revocations, telling people, attending PGP key signing parties etc), I decided to go for a nice long key this time. By default, GPG will only create keys up to 4096 bits long, but it's happier to work with larger ones if created. The reason for this, if you google, is that they think that for most people going to 8192 bits will just make things slower, without delivering much more security, so they feel that anyone who wants a longer key should have to think about it, and explicitly enable it themselves.

I decided that given the faff of a new key, the relatively infrequent use my key gets (most just code signing and the odd signed email for voting/contracts etc), going straight to 8192 bits for my key was a sensible choice, even given the slowness vs 4096. So, I followed the GPG list's guidance, grabbed the source code, and upped the limit for myself.

To do this, I downloaded GPG 1.4.9 from my nearest GPG mirror, and unpacked. Line 1516 of g10/keygen.c holds the default and maximum key size for generation. I upped the limit from 4096 to 8192 and compiled.

Next, you need to alter your hash preferences in GPG. This needs to be done before you generate the new key! As per the debian article, edit your ~/.gnupg/gpg.conf file and add in two more lines to set your hash to SHA256. You can do this with:
cat <<~/.gnupg/gpg.conf >>EOF
personal-digest-preferences SHA256
cert-digest-algo SHA256

With my hashing preferences changed, and a custom version of gpg now sat in the g10 directory, I ran ./g10/gpg --gen-key. First I selected a key type of RSA (sign only), as DSA+Elgamal is capped at 1024 bit key + 160 bit hash, and apparently the larger DSA keys are less well supported. Next, I entered a key size of 8192 bits, which my custom version of GPG allows me to.

After picking an expiry time, entering my name and email, and picking a nice secure password, it was time for the key to be generated. As generating a 8192 bit key takes a lot of entropy, don't expect it to happen quickly, and use your machine in the mean time to generate more entropy for it!

With my signing-only 8192 bit key created, it was time to add in my two extra sub-keys so I could use it for everything. GPG had output the new key id, so I edited the key (gpg --edit-key [id]). Running addkey, I first added a RSA (sign only) 8192 bit key, and then I ran addkey again to add a RSA (encrypt only). Both key generation processes take a while, so be patient!

At this point, I had a 8192 bit RSA PGP key, with signing and encrypting subkeys on it. Next I set the preferences to request stronger hashes if possible, by running
setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
(this magic list comes from the debian docs). Finally, I saved my new key, and took a backup of it.

The last couple of steps were:
  1. Sign my new key with my old key, to show it's really my new one
  2. Upload my new key to a keyserver
  3. Generate a transition notice, signed by both my old and new keys. This tells everyone my new key's details, and is a handy + secure document to point people at
  4. To sign the notice, run gpg -a -u [old id] -u [new id] --clearsign transition.txt
  5. Put my new public key into the KEYS file for the open source projects I release code for
  6. Printed out a few little bits of paper with my key id and fingerprint on, for key signing events
  7. Emailed a few key friends to ask them to sign my new key, pointing them at the transition doc, and following up with a quick SMS to confirm it's really me
  8. Wrote this doc up for them to follow :)

There we are, and I have a shiny new 8192 bit PGP key. It doesn't take too long to do (maybe 20 minutes elapsed, 15 minutes work including printing and cutting up fingerprint slips), and my key + signing is hopefully now secure for another 5+ years!

Sorry I haven't got round to signing this yet. I'm not ignoring you; 'm just so rarely sat at my desktop machine (where my PGP key lives) having read through my whole inbox to remind me to do it these days :)
(Replies frozen) (Thread)
(Deleted comment)
From: gagravarr
2009-07-06 09:29 am (UTC)

Re: any problems?

None so far!
(Replies frozen) (Parent) (Thread)
(Deleted comment)
From: gagravarr
2009-07-06 10:29 am (UTC)

Re: any problems?

Very rarely...
(Replies frozen) (Parent) (Thread)
From: (Anonymous)
2010-12-23 01:40 am (UTC)

Re: any problems?

Hi Nick,

I modified the source code of version 1.4.11 and need instructions on how to compile it on Mac running 10.6.5 with xCode installed. If you don't have the info on how to compile on Mac, I would appreciate the instruction for Debian as I will run it in VM to generate GPG keys.

(Replies frozen) (Parent) (Thread)
From: gagravarr
2010-12-23 05:46 am (UTC)

Re: any problems?

I'd suggest you check the standard GPG build instructions for OSX support details

On debian, I'd suggest you just use "apt-get source", apply the patch, then build the new deb in the usual way
(Replies frozen) (Parent) (Thread)
From: (Anonymous)
2012-02-11 03:02 am (UTC)
Why do you create three keys each for one purpose instead of just the one initial 8K RSA key for all purposes?
(Replies frozen) (Thread)
From: gagravarr
2012-02-12 05:56 pm (UTC)
You create a master key, then subkeys for different tasks. These subkeys can be revoked independently if needed. Debian have a really good wiki page - - explaining why you might want to do this, and what the best practice is
(Replies frozen) (Parent) (Thread)