Generating a private key I can trust
blog.martin-graesslin.com
blog.martin-graesslin.com
I think the concerns about backdoored hardware RNGs are really overblown, but if we're going to stipulate they're to be taken seriously, they relevant on online attacks against systems that make repeated requests for entropy.
Along a similar vein, every attack you've heard of on AES or even RC4 requires many repeated calls to the cipher, often with other parameters fixed.
Just generate the damn GPG key and be done with it.
But the problems include:
1. So suppose you build into a computer an effort to recognize some public key generation routines and intercept the key from memory. This could be done, but updating the firmware code (since it is hidden from the user of the computer) is pretty hard so it only works on versions current at the time of manufacture. If you have had the computer for a few years, such recognition would seem iffy. Additionally this gets more complex when supporting more implementations....
2. Ok, so the computer malhardware has got the key, so what can it do with it? If you send the key over the internet, someone at some point may detect it. Likely the best scenario would be to store it and wait for some attempted handshake on, say, a firewire port, and then send it out then. Or one could wait for an SSH connection to an NSA-used cert for something like Google, but certs expire so that attack won't be worth it.
Tinfoil mode is interesting but part of the benefits are thinking through the possible exposure of something like a compromised piece of hardware.
Again, suppose the RNG is compromised. usually this means one can guess future values based on past values. An attack without past values is worthless, so it is unlikely to be helpful with regard to public key encryption as you point out.
If your system is already compromised, then backdoored hardware RNGs are the least of your worries, and "just generate the gpg key" might not be good enough. Consider the case where an attacker replaces your gpg binaries with ones that cc private keys to an external location.
In all honesty, I'd really love to see a formal threat tree with the NSA as the adversary and "an individual's private keys" as the target from someone as well-versed in security as you.
Well if you can't trust any hardware, how can the author trust any off-the-shelf computer and CPU to generate the private key even if he is using Linux+GPG? For all he could know the CPU could contain a backdoor that performs the necessary arithmetic and operations incorrectly (in the process making the key weaker).
He is also trusting his CPU to do the session encryption correctly (even with his external smartcard). Perhaps the CPU could leak information about the session key to another processes, allowing people to decrypt your communications?
Now I trust my CPU and hardware, especially because we have little alternatives. Perhaps it would be better to use an external smartcard to generate the private key too, because the physical hardware is orders of magnitude less complicated than a CPU/computer, so you could verify the hardware contains no backdoors by examining the physical circuits using a microscope (I presume this would still be very hard to do but millions of times simpler than that for a modern CPU).
Of course this is likely less secure than using /dev/random, as you will be typing in the bits, someone could log the bits you type in, someone could have a telephoto lens and take pictures of your dice rolls.
It's always possible to be paranoid to the point that whatever you do isn't secure.
Roll a braille octahedron in your bathroom with the door locked and the lights out. Type the bits on an offline computer so the keylogger can't report back to its owner.
4096 bits?
However it looks like Martin is trying to be successful in exactly that scenario so I suppose that's a good tip indeed for this case.
Keep using what you are using and it will protect you from the 99.999999% of the world who has no idea who you are, doesn't care, and can't be bothered to spend any amount of time backdooring your system because you aren't interesting enough.
Why would you leave out the BSDs?
I'm surprised more people haven't been mentioning the BSDs after the NSA / GCHQ revelations and in the drive for more security.
pass out all
last rule wins, and obviously if it is remote allow ssh port etc.
You can read more here: http://home.nuug.no/~peter/pf/en/long-firewall.html
also not only focusing on security, but linux is all well now.. and are widelly adopted by the big players..
i think its time for us techies to focus our energies in this great OS that needs our help, code, support, whatever..
Incidentally, they sign their order confirmation emails with PGP. :-)
I guess, if that doesn't work, we could always just work on an Open Smartcard Microcontroller For FPGA-based Cards. Then the one thing you need to trust is that FPGAs don't have a special backdoor mode for when they somehow detect that the chip they're running is doing crypto ;)
So I went to buy, and the seller has a market place with a self-signed certificate. They won't get my dime.
Some part of me wants news to come out that there has for years been an NSA code-injection backdoor in, say, Debian's binary "lineage" of GCC. Imagine the reaction.
You'd be better off going with an x86 chip and avoiding the obvious hardware backdoor channel of a bad RNG(though for key generation it's unlikely NSA would ever see enough bits from the RNG to crack it). Because it's a generic computer, you can't just break the chip by backdooring everything(e.g. make xor a nop). You'd need to screw with instruction only if it is part of a cryptographic operations and that would be very very tricky and use up a hell of a lot of the transistor budget.
[1]: http://www.yubico.com/products/yubihsm/ [2]: http://www.yubico.com/products/yubikey-hardware/yubikey-neo/ [3]: http://www.yubico.com/develop/open-source-software/
http://www.cdw.com/shop/products/Gemplus-GemPC-USB-Shell-Tok...
That's what I did. I believe this meets all your requirements. I can attest that FOSS support is excellent and I also think the OpenPGP card is trustworthy.
1. You should choose a long PIN. In the DoD there is a feature on the smartcard that locks the card after three consecutive incorrect PIN entries (no time limit). Obviously this is a good security measure. When DoD personnel have locked out their smartcard they go to the computer help desk where there is a trusted agent like a (properly trained) young enlisted troop who has a high privilege key that can unlock your smartcard. You do not have a worldwide network of locations where you can get your card unlocked, so you cannot implement the "three tries and you're dead" feature. Therefore, make your PIN as long as practically possible to prevent someone who stole your card from being able to brute-force the PIN and get your keys.
2. You might want to make a duplicate card and store it in a safe location. You WILL eventually lose the card you are carrying around with you, and when you do, it essentially means the loss of all your encrypted data. While the second set of keys lying around is a vulnerability, it might be an acceptable one to hedge against the loss of your data. Having a duplicate card might also allow you to implement the feature where the smartcard locks after a number of unsuccessful PIN entries.
3. Do NOT use USB drives as an alternative token because you don't want to shell out for a smartcard. USB drives introduce known vulnerabilities and they are prohibited DoD-wide on ALL of their networks (including all our classified nets). If the lowly USB drive has the power to make the DoD shake in its boots, you shouldn't be using one when you need security.
4. Smartcards are cool in an enterprise setup for signing documents and stuff, but make sure you aren't triple locking your door and then leaving your window open. If you decrypt an email and view the cleartext with a text editor, make sure you are not beaming that back to your attacker because they compromised your machine in another way.
5. Related to #4 above, the most secure systems are standalone systems that NEVER connect to a network. Instead of shelling out for some smartcards and readers, buy a Raspberry Pi, and generate your keys on it- and your private key will never leave this machine. Use write-once media to get your public key on a networked computer (this should be the ONLY time you transfer data off of your standalone system). Whenever you need to decrypt something, use more write-once media to get the encrypted data onto your standalone RasPi, and decrypt it and view it. If you want to be super paranoid, maintain an 18" air gap between your standalone RasPi and any networked computer. This is the proper way to wear your tinfoil hat. Plus, the RasPi is cheaper than a smartcard setup, and invulnerable to keyloggers and pretty much any other attack because data exfiltration is impossible when you never connect it to the network and you never send data off of it.
what about using am Rodeh Btree[1], to create concurrent snapshots of the running kernel, in this btree, so we could switch them in runtime.. you compile a new version (CRC does not match) them it will create a new branch/snapshot on memory and will start from there..
kernels of course should be designed in a transactional way manage states, etc.. rsrs..
anyway just a wild idea, dont know if its even useful doe..
[1] - B-trees, Shadowing, and Clones -http://www.usenix.org/event/lsf07/tech/rodeh.pdf