I recently (just in time for it to be a nice birthday present for myself) decided to generate myself a new GPG key. I’d been reading that SHA1 was becoming more vulnerable, so I decided to upgrade, taking the chance to tighten various security measures to try and keep my key safe.
The first thing I considered was which algorithms to use for the keys. I decided that I would like to use RSA for both signing and encryption, which makes the procedure slightly more complicated, as due to the fact that Ubuntu have not yet packaged the latest version of GPG, none of the default key type options generate RSA keys for signing and encryption. However, it is possible, it just requires a couple of extra steps, which I learnt from a handy post here. So thank you very much for your help ‘ana’.
Now, on with the generation. So, having decided to use RSA keys only, I then looked at GPG’s method of protecting the key you generate. The private key is stored in an encrypted file, and is encrypted using similar methods to any message. Unfortunately this means that by default, it’s encrypted using CAST5 encryption, which is not really what I want (I want full AES256, dammit!).
However, I found an easy way to fix this, and set my preferences for choices of algorithms globally. These can of course be set in the gpg.conf file, but I learned from another article that if you set these before generating your GPG key, GPG will respect these preferences when it encrypts your key.
So, having customised my options so that my key will be protected with the full AES256, there’s one final piece of the puzzle. S2K, or ‘string-to-key’, the method GnuPG uses to generate the key for the encryption on my keyfile. It’s reasonably secure by default, and uses salting and key strengthening (tasty tasty). However, I decided that (just for encrypting my keyfile) I would turn these settings up to 11. This was reasonably simple to do, I simply used the following command lines instead of the normal ones when generating and editing my key:
gpg --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 131072 --cert-digest-algo SHA512 --gen-key gpg --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 131072 --cert-digest-algo SHA512 --edit-key $KEYID
This does a couple of things, it sets the cipher and digest algorithms used in s2k to the most secure options available, the s2k mode is 3 by default (which sets it to salt and strengthen the password) so that switch is really a no-op just to be sure, the –s2k-count sets the number of iterations of the password strengthening (this is where I’ve really turned it up a notch, by doubling the default number), and finally the cert digest option sets the algorithm to use for the digest when self-signing the keys.
So, having set up my key in this way I’ve tried to ensure it should be as secure as possible. Of course, ensuring my computer is reasonably secure by having a firewall, encrypted root partition, and using a file integrity tripwire should hopefully help too.