Recently there have been two very good, and opposing, articles written on the state of Pretty Good Privacy (PGP) and whether or not it is worth using in 2016/2017 and beyond. You can find the original article, I’m throwing in the towel on PGP, and I work in security, at Ars Technica here but I’ve reproduced it below in case the link stops working at some point. You can also find the follow up piece, Why I’m not giving up on PGP, also at Ars Technica here and again I’ve reproduced it below just in case.
If you are worried about your hard drive one day crashing and you losing access to your OpenPGP key (and thus the contents of your encrypted e-mails) then you should have been using a backup! That said an extra archival method of storing your key completely offline would be to use a program called paperkey to export the contents of your OpenPGP key to an easily printed file that you can then re-type into your PC if necessary.
More than a year ago I moved from my expiring OpenPGP key (0x1CD3E3D8) to my current key (0xFEEEFA8F) and for that process, in addition to signing my new key with my old key, I created a Key Transition notice signed by both keys as a way to inform those who trusted my old key that my new key was in fact still me. However it only recently occurred to me that I never actually posted any instructions on how I did that and deciphering gpg command line can be a bit of a pain.
While I am by no means a security expert the following are the current best practices for configuring your gpg.conf file as best as I can determine. Key usage options default-key <your primary key> Use as the default key to sign with. If this option is not used, the default key is the first key found in the secret keyring. hidden-encrypt-to <your primary key> Same as –hidden-recipient but this one is intended for use in the options file and may be used with your own user-id as a hidden “encrypt-to-self”.
As advances in cryptography and technology move forward there is a chance that your once secure system may suddenly be relying on outdated (and perhaps now broken) algorithms or implementations. Some good examples of this in recent memory are the breaking of the MD5 hash algorithm and the constant problems plaguing the RC4 encryption cipher. When it comes to PGP it is well known that short keys, keys generated without good entropy to pull from or keys using outdated implementations and algorithms can be far less secure than you would hope they would be.
I recently came across a very good (albeit sort of old) post over at Chris Wellons’ null program blog about increasing the default protections on your stored PGP key. The short hand version is that gpg attempts to protect your PGP key from theft by encrypting it on disk so that if anyone gets access to your secret key file they still don’t immediately have access to your PGP key.
After reading this I’m still not 100% sure there can ever be a completely “safe” way to do this with Twitter. That said some ways are certainly better than others… Personally I think the best of the approaches listed is to include the full key fingerprint and then to also periodically tweet the details. At least that way if an attacker does go and maliciously modify your bio there is still a chance for someone to see the good tweet as well.
I’ve been meaning to write a quick post on PGP/OpenPGP related settings that you can use to increase your overall security even more. Simple things like changing your preferred cipher and digest algorithms. In fact I even started writing just such a post about a year and a half ago but never got around to finishing it. Luckily I was recently linked to the following website that deals with essentially everything I was going to write about anyway.
I have been meaning to write up a short post about this for a while, but thanks to the start of a new school term I have been a bit busy. If you have seen the security news in the last month or so you will know that RSA-768, a 768bit or 232 decimal digit asymmetric key, has been broken (factored). This has important security repercussions for all of us because it is these public key algorithms like RSA, or ElGamal, that guard our online transactions, and e-mail conversations.
Well GPG to be more accurate 😉 As my existing key was set to expire at the end of this year I have issued myself a brand new one! After much though I finally decided that creating a new key from scratch was the best idea, rather than simply adding a new subkey, because I wanted to move away from DSA/ElGamal toward RSA primarily because of the weakening of SHA1. If this all sounds like gibberish to you then don’t worry, the details aren’t nearly as important as the security provided by my new key.