Given last weeks news about the state of cryptography and the influence of the NSA on standards I decided to enter paranoid/tinfoil-hat mode. The result is that I do no longer consider my asymmetric keys as long enough. So I need to regenerate them. This should be an easy task, but I’m in paranoid mode.
The big problem is “can I trust my systems to generate a safe key”? I decided no, I cannot. Not without investing some time. Normally I would trust my distribution, but I had once to regenerate my SSH key because they got random numbers wrong:
by Randall Munroe (Creative Commons Attribution-NonCommercial 2.5 License)
So whom do I actually trust? This list is short: the Linux kernel (Linus tree) and FSF/GNU.
Whom do I not trust? That gets more complicated. First of all I do not trust any hardware. It’s impossible to verify that the hardware doesn’t have a backdoor and randomness looks random even if tampered with.
Of course I do not trust the US and any US-based company or company which has interactions with the US. As we had to learn the NSA is putting backdoors into products of US companies and the companies are not allowed to talk about it. This means I do not trust the Linux kernel of any distribution placed in the US or relations with the US. Obviously I extend this on all distributions of companies based in other spy countries (e.g. Five Eyes). This makes the list rather short.
I also do not trust binaries as there is no way to ensure that the binary reflects the source code of the package[1]. This further reduces the list. I’m basically left with Linux From Scratch or Gentoo – two distributions I do not have any experience with. Or use a binary distribution and create the required packages by myself (Linux kernel, GPG). Obviously there is still the risk of a tampered compiler but I consider this risk as rather academic.
Last but not least I do not trust my systems and myself. If I keep the key on the hard disk the security is basically reduced to the strength of the chosen passphrase. Hard disk encryption can add some security to it, but I prefer to have my system in suspend so the key might be in memory and there is always the risk of cold boot attacks. In summary I do not think that hard disk encryption is a solution for protecting the key. Also there is always the risk of an application attacking the system. Getting passphrase through an X11 keyboard logger is unfortunately trivial.
A solution to this problem is getting the key on an external dedicated device. But this is of course conflicting with my “I do not trust hardware” requirement. If hardware random number generators are involved in creating the keys or doing the encryption this would be problematic.
The requirement would therefore be a hardware device which keeps the key secure but does not generate it and is not involved in the session encryption. Today I ordered an OpenPGP Smartcard. This fulfills most of my requirements. It’s trusted by FSFE (Fellowship card), developed by a company which also develops GnuPG and is Germany based. Still I do not trust hardware, but one can upload an externally created key.
So sometime soon I will blog the public key of my new key pair.
[1] I am aware that bitcoin is experimenting in that direction. But this doesn’t help me with the problem to verify the Linux kernel.