
Generating a private key I can trust - tcoppi
http://blog.martin-graesslin.com/blog/2013/09/generating-a-private-key-i-can-trust/
======
tptacek
This is extremely silly. Construct a scenario in which a compromised hardware
random number generator enables NSA to somehow recover the bits from a GPG key
you generate at some unknown point in the past. Try to be as specific as
possible.

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.

~~~
jacquesm
It's hard to be a tinfoil hatter when everybody else is now just as paranoid
as you were 6 months ago. So tinfoil hatters have to up the ante or go
mainstream :)

~~~
einhverfr
Given that I keep hearing security professionals say they weren't paranoid
enough, I suspect the truth is everyone else now is _more paranoid_ than you
were six months ago, which must be really disconcerting.

------
mileswu
> 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.

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).

~~~
acqq
Smartcard _is_ the whole computer, minus power supply and the clock. You are
right that it's smaller than one x86 and the rest of your notebook or desktop
though. Still you'd have to investigate all the hardware and software on your
desktop that you use with the smartcard too -- how would you know that the
desktop isn't just pretending to use your smartcard? And if you trust the
desktop, why do you waste the time with the smartcard, as long as you make the
whole setup only for you?

------
aidenn0
How about rolling an octahedron? You can generate 3 bits per roll, it takes
about 3 seconds to roll and record the result, for a total of 1 bit per
second. How much entropy is needed to generate a 4096 bit key?

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.

~~~
olympus
>someone could have a telephoto lens and take pictures of your dice rolls<

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.

~~~
derefr
They can use an infrared lens to look at indentations created on your
fingertips as you read the braille. ;)

------
gioele
Beware of the key size limitations of OpenPGP smartcards: most of them can
only handle 2048-bit RSA keys, a size that is now considered not safe for new
RSA keys.

~~~
taway2012
They handle 3072-bit keys now.
[http://shop.kernelconcepts.de/product_info.php?cPath=1_26&pr...](http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42)

~~~
agwa
This is correct. I have a 1.5-year-old OpenPGP card and can attest that all 3
of my keys are 3072-bit.

------
res0nat0r
I think most of these types of posts are not seeing the forest for the trees.
If you for some reason have become a direct target the NSA has been tasked to
investigate then you've already lost. They have much more manpower, money, and
clever ways to get their hands on your data than you have to keep it from
them. Most probably don't even involve some techno conspiracy supercomputer
type RSA cracking fantasy, but simple social engineering.

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.

------
deweerdt
> So whom do I actually trust? This list is short: the Linux kernel (Linus
> tree) and FSF/GNU.

Why would you leave out the BSDs?

~~~
DanBC
I'd love to see a version of this post or the "Securing a Linux server"
([https://news.ycombinator.com/item?id=6384603](https://news.ycombinator.com/item?id=6384603))
post but for OpenBSD or FreeBSD.

I'm surprised more people haven't been mentioning the BSDs after the NSA /
GCHQ revelations and in the drive for more security.

~~~
tls
block in all

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](http://home.nuug.no/~peter/pf/en/long-firewall.html)

------
privasectech
Interesting that you can only buy an OpenPGP smart card from a supplier with a
broken SSL implementation.
[https://shop.kernelconcepts.de/login.php](https://shop.kernelconcepts.de/login.php)

~~~
agwa
They're not broken; they're simply using cacert.org instead of a mainstream
CA. From a business standpoint, that's a terrible idea for selling to the
general public, but from a security perspective it's fine.

Incidentally, they sign their order confirmation emails with PGP. :-)

------
Sanddancer
I was hoping that this would have been something interesting, like a
discussion on using avalanche noise (
[http://holdenc.altervista.org/avalanche/](http://holdenc.altervista.org/avalanche/)
) in a portable way, or other bits of proper hardware hacking. Not trusting
any hardware RNG is silly, especially if you can learn from first principles
how they work, and build one yourself.

------
wtn
Most S/MIME certificate authorities require the generation of private keys
using the "keygen" tag. Most browsers that support this tag require the
generated key length to be 1024 or 2048 bits, whereas forcing either 2048 or
4096 bit keys would be more sensible.

[https://bugzilla.mozilla.org/show_bug.cgi?id=495836](https://bugzilla.mozilla.org/show_bug.cgi?id=495836)

------
derefr
How hard would it be to print a smart card with currently-shipping consumer 3D
printers? If not-that-hard, then would collaborating to create a verifiable
Open Smartcard Board + Firmware be a useful idea? It'd neatly short-circuit
having to trust the entire consumer hardware+software stack.

~~~
InTheSwiss
The card itself is just a piece of plastic, it is the microchip that is the
important part and I am not aware of any 3D printing system that could print
something that complex just yet.

~~~
derefr
How many gates does a chip need if it's basically a single-purpose crypto
ASIC? Presuming you can expand the traces out to cover the entire back of the
card (no die, just raw PCB), what process size would you need?

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 ;)

------
bdamm
I thought this was a great idea, a GnuPGP ready card! This means there's
firmware on the card that is known to be compatible with GnuPGP protocols, and
pscsd as well. Very nice.

So I went to buy, and the seller _has a market place with a self-signed
certificate_. They won't get my dime.

------
derefr
> Obviously there is still the risk of a tampered compiler but I consider this
> risk as rather academic.

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.

~~~
lifeisstillgood
to be honest not that much. most people have never heard of Linux let alone
Debian compiler toolchains. and almost everyone who has heard of it, already
is reacting about as hard as they can.

------
zokier
Any recommendations for USB HSM/token? Trustable, foss-friendly, good
software/standards support, buyable in singles? Smartcards are kinda nice, but
the lack of integrated reader HW makes them mostly just bulky USB tokens
(card+reader).

~~~
csears
Yubico makes a couple products that might fit your requirements. The YubiHSM
[1] ($500) is a USB HSM designed to be connected to server. Yubikey Neo [2]
($50) is does end-user authentication (OTP, CCID, SE, JavaCard) over NFC or
USB. They can both be ordered in quantities of one and have open source SDKs
[3].

[1]:
[http://www.yubico.com/products/yubihsm/](http://www.yubico.com/products/yubihsm/)
[2]: [http://www.yubico.com/products/yubikey-hardware/yubikey-
neo/](http://www.yubico.com/products/yubikey-hardware/yubikey-neo/) [3]:
[http://www.yubico.com/develop/open-source-
software/](http://www.yubico.com/develop/open-source-software/)

~~~
zokier
Yubi Neo looks nifty, NFC should make it real convenient to use (drop keys on
desk to authenticate, what would be easier!)

------
privasectech
I'm curious why there was no consideration for OpenBSD?

------
JonFish85
So really, what you want, is a convenient & easy but totally secure method.
Because if you want security, a one-time pad is pretty much your best option.
But at the same time, since you pretty obviously are willing to go great
lengths for security, let's not beat around the bush. Granted this has some of
the same problems (need randomness), and can probably be more work than it's
worth...

------
olympus
I applaud the author's idea, but let me share some of my experiences (both
good and bad) since the DoD uses smart cards every day for a myriad of things
including: document signing, document encryption, computer logins, website
logins, biometric information storage, medical information storage, and
probably a few more that I am forgetting.

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.

------
enupten
I guess this is why RMS dislikes binary blobs. Something like the Lisp
machine, where you can access/modify OS source while it's running, would be
dream come true in today's world.

~~~
oscargrouch
your post give me one idea:

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](http://www.usenix.org/event/lsf07/tech/rodeh.pdf)

~~~
oscargrouch
other design note to make this feasible, its to design it in a way, where each
cpu core, could have its own kernel copy.. so you can try to boot up, the
other version in another core, while you are using the old version in an
active/context core?

