Comment by ghshephard | Hacker News Reader

Comment by ghshephard | Hacker News Reader

Parent Full thread

GPG is way, way, way to complex for all but the 0.01% of people who are GPG experts. It's too complex for me - and I've read (and enjoyed) Applied Cryptography.

But, not having used it for a few years, I went to take a look again - list some keys, maybe SMS some friends to exchange fingerprints and sign their keys, etc... - I'm trying to recall what the relationship between PUB, SUB, UID, Key Fingerprints are. And how do I indicate that I trust a key and upload it back up to pgp.mit.edu?

And I consider myself a member of the 0.1% who at least understand the principals behind PGP/Public Keys/Private Keys/Web of Trust, etc...

So - if I'm having trouble understanding this without a couple hours of study, their is Zero chance that the other 99% of the population will ever be able to wrap their heads around the intricacies of PGP. Something else is going to have to replace it.

[EDIT - as an aside, I've spent the last hour trying to do a "gen-key" on my ubuntu host, and been prevented by lack of entropy - and yes, I've tried running tcpdump, tried egrepping every file on the system for a string, etc... Ended up on https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/706011 and the answer seems to be, "Find a machine that does have entropy, or install a hardware random number generator in your computer."

Please add this to the reasons why normal people never use GPG

Edit-2: It took about 25 minutes, but apparently between find / -type f | xargs grep wontfindme and sudo tcpdump -nnn not port 22, I managed to collect enough entropy to keep gpg moving forward. ]

There has been a number of studies (http://www.2uo.de/myths-about-urandom ; I don't agree with everything but interesting reading anyway) showing that entropy from Linux random is not better than from urandom (once urandom has been properly seeded). For this reason, I patched my rndlinux.c GnuPG source code file to always use urandom. Makes key generation instantaneous. When a software is stupid, I don't want to install additional stupid software or comply with stupid instructions; I simply patch it.

I think that on linux, you ideally don't want /dev/urandom, you want a recent kernel and getrandom(buf, len, 0). From the manpage:

If the GRND_RANDOM bit is not set, then the /dev/urandom pool will be used. Unlike using read(2) to fetch data from /dev/urandom, if the urandom pool has not been sufficiently initialized, getrandom(2) will block (or return -1 with the errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).

Then again, that's probably not important if you interactively launch gpg on a desktop system that wasn't just installed a minute ago or so.

Entropy is a massive problem, especially on headless servers.

Timer EntropyD [1] can be extremely handy (as can the audio-entropy gathering)

[1] http://www.vanheusden.com/te/

> and been prevented by lack of entropy

This sounds like an implementation fail / lazy implementor. GPG shouldn't need more than 32 bytes of entropy (for keying AES-128 and then encrypting a 128-bit block of data repeatedly until you collect enough randomness.)

apt-get install haveged

I'm not sure why you're being down voted.

haveged is an absolute essential for all servers

http://www.issihosts.com/haveged/

It's snake oil -- entropy isn't "depleted" in any meaningful way; once your kernel PRNG has accumulated enough entropy that you'd be comfortable using it to generate a crypto key it is not going to cease being suitable for that just because you continue asking it for random numbers.

/dev/random is an entropy estimating entropy pool

that means it will block when it estimates that you have "used up" all of the available entropy

you can check how many bits of entropy your kernel thinks are available easily

cat /proc/sys/kernel/random/entropy_avail

edit: i should have mentioned that there is some reason to argue against this behaviour but that doesn't change the usefulness of haveged for existing systems

Yes, but that's a reason not to use /dev/random, not a reason to install snake-oil products.

The random(4) manpage is unfortunately exceptionally misleading, and has sadly led to a small but non-zero numbers of products that try to use /dev/random rather than /dev/urandom.

Sadly, gpg --gen-key doesn't even give you this option - but that's (as noted above) another flaw in GPG.

Reply on news.ycombinator.com