Closed vitzli closed 9 years ago
jbenet
commented
9 years ago @vitzli great find! as mentioned in the security notes, our state of crypto is very far from secure right now-- we need to make a long list of things to check (and eventually have an independent audit of the whole thing).
If you'd like to make a document ./dev/crypto-notes.md with an Important Notes section, and mention this there, that would be great
vitzli
commented
9 years ago This issue seems to be caused by crypto/rand implementation in the Go programming language:
in UNIX-like operating system it uses /dev/urandom device:
// Easy implementation: read from /dev/urandom.
// This is sufficient on Linux, OS X, and FreeBSD.For OS X that would use 160-bit Yarrow PRNG based on SHA-1 key, for FreeBSD - 256-bit Yarrow algorithm. For both operating systems /dev/random and /dev/urandom are equal.
in Linux it falls back to urandom in several cases:
// Test whether we should use the system call or /dev/urandom.
// We'll fall back to urandom if:
// - the kernel is too old (before 3.17)
// - the machine has no entropy available (early boot + no hardware
// entropy source?) and we want to avoid blocking later.The first clause would be used for several production-class operationg systems.
It seems that there is a consensus that using /dev/urandom instead of /dev/random is safe:
BUT:www.gossamer-threads.com on large entropy consumption:
Why does gpg use so much entropy from /dev/random? … 1) If you don't do anything special then two keys are generated (mainkey and subkey). … So we see: If high quality entropy is required then gpg reads (128+128+44)/16=18.75 times as much entropy from /dev/random as demanded.
Which /dev/random - there are hundreds of variants of that device all with other glitches. Thus GnuPG has always used /dev/random only as a source of entropy to seed its own RNG:
This random number generator is loosely modelled after the one described in Peter Gutmann's paper: "Software Generation of Practically Strong Random Numbers".@footnote{Also described in chapter 6 of his book "Cryptographic Security Architecture", New York, 2004, ISBN 0-387-95387-6.}
A pool of 600 bytes is used and mixed using the core RIPE-MD160 hash transform function. Several extra features are used to make the robust against a wide variety of attacks and to protect against failures of subsystems. The state of the generator may be saved to a file and initially seed form a file.
Depending on how Libgcrypt was build the generator is able to select the best working entropy gathering module. It makes use of the slow and fast collection methods and requires the pool to initially seeded form the slow gatherer or a seed file. An entropy estimation is used to mix in enough data from the gather modules before returning the actual random output. Process fork detection and protection is implemented.
GPG uses ~/.gnupg/random_seed but it needs to creater it first. For generating keys it also makes sure to put in a lot of new entropy just to be safe. Better be safe than sorry (cf. the recent NetBSD problem). Salam-Shalom, Werner
Maybe it's not a bug, but compared to gpg, IPFS: 1) generates 4096 bit key-pair too fast; 2) does not deplete entropy pool during key generation, it often happens with gpg. OS: Debian Jessie 32-bit, 512 MB RAM inside virtualbox VM; I'm checking available entropy via /proc/sys/kernel/random/entropy_avail, entropy drops a little (about 100 bits) but stays there, while gpg eats all available entropy (drops to 40 bits, process takes about 5 minutes and HDD activity is required to feed the pool). Here is the log, I combined entropy output, time, and ipfs generation into one file, long version at https://gist.github.com/vitzli/f6fa7338cbc2bf4eb553: