4 ms·

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

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

alrs 12y ago
apt-get install haveged
- pstrateman 12y ago
  I'm not sure why you're being down voted. haveged is an absolute essential for all servers http://www.issihosts.com/haveged/ http://www.issihosts.com/haveged/
  - Saavedro 12y ago
    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.
    - pstrateman 12y ago
      /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
      - jfindley 12y ago
        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.
zvrba 12y ago
> 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.)
kS6n6GN8If 12y ago
There has been a number of studies (http://www.2uo.de/myths-about-urandom 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.
- TheJH_ 12y ago
  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.
BuildTheRobots 12y ago
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/ http://www.vanheusden.com/te/

alrs 12y ago

apt-get install haveged

pstrateman 12y ago
I'm not sure why you're being down voted. haveged is an absolute essential for all servers http://www.issihosts.com/haveged/ http://www.issihosts.com/haveged/
- Saavedro 12y ago
  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.
  - pstrateman 12y ago
    /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
    - jfindley 12y ago
      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.

zvrba 12y ago

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

kS6n6GN8If 12y ago

There has been a number of studies (http://www.2uo.de/myths-about-urandom 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.

TheJH_ 12y ago
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.

BuildTheRobots 12y ago

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/ http://www.vanheusden.com/te/