From 098bcc5a61ee774d0c7a65f1f4840b329ec882a8 Mon Sep 17 00:00:00 2001 From: vitzli Date: Tue, 10 Mar 2015 21:54:58 +0600 Subject: [PATCH 1/3] add crypto-notes.md; closes #911 --- dev/crypto-notes.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 dev/crypto-notes.md diff --git a/dev/crypto-notes.md b/dev/crypto-notes.md new file mode 100644 index 000000000..f7afd15ac --- /dev/null +++ b/dev/crypto-notes.md @@ -0,0 +1,40 @@ +## Important notes + +### Key-pair generation + +When compared to gpg without hardware-based (P)RNG, IPFS generates key-pair +alarmingly fast: it takes ipfs about 1 minute to generate 4096-bit +key-pair, but for gpg it takes about 10 minutes. In the same time +entropy_avail show severe drop in available entropy for gpg, but for +ipfs entropy drops about 100 bits. + +[This issue (#911)](https://github.com/jbenet/go-ipfs/issues/911) seems to be caused +by `crypto/rand` implementation in the Go programming language: + +1. [in UNIX-like](http://golang.org/src/crypto/rand/rand_unix.go) 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. + +2. [in Linux](http://golang.org/src/crypto/rand/rand_linux.go#L22) 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. + +3. [in Windows]() it uses Windows CryptGenRandom API. + +According to [wikipedia](https://en.wikipedia.org/?title=/dev/random) using +/dev/urandom instead of /dev/random seems to be safe. From 67600a73ea9b2645314677eed750f8830c8d2e54 Mon Sep 17 00:00:00 2001 From: vitzli Date: Tue, 10 Mar 2015 21:59:44 +0600 Subject: [PATCH 2/3] edit formatting --- dev/crypto-notes.md | 37 ++++++++++++++++--------------------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/dev/crypto-notes.md b/dev/crypto-notes.md index f7afd15ac..ff7b46bc2 100644 --- a/dev/crypto-notes.md +++ b/dev/crypto-notes.md @@ -11,30 +11,25 @@ ipfs entropy drops about 100 bits. [This issue (#911)](https://github.com/jbenet/go-ipfs/issues/911) seems to be caused by `crypto/rand` implementation in the Go programming language: -1. [in UNIX-like](http://golang.org/src/crypto/rand/rand_unix.go) operating -system it uses /dev/urandom device: -``` -// Easy implementation: read from /dev/urandom. -// This is sufficient on Linux, OS X, and FreeBSD. -``` +1. [in UNIX-like](http://golang.org/src/crypto/rand/rand_unix.go) 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. + 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. -2. [in Linux](http://golang.org/src/crypto/rand/rand_linux.go#L22) 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. -``` +2. [in Linux](http://golang.org/src/crypto/rand/rand_linux.go#L22) 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. + The first clause would be used for several production-class operationg systems. 3. [in Windows]() it uses Windows CryptGenRandom API. -According to [wikipedia](https://en.wikipedia.org/?title=/dev/random) using -/dev/urandom instead of /dev/random seems to be safe. +According to [wikipedia](https://en.wikipedia.org/?title=/dev/random) using /dev/urandom instead of /dev/random seems to be safe. From c5689fe367b134b3888cf326eaae98935d90fe90 Mon Sep 17 00:00:00 2001 From: vitzli Date: Thu, 12 Mar 2015 16:53:08 +0600 Subject: [PATCH 3/3] move commentary to issue #911; replace with note --- dev/crypto-notes.md | 33 ++------------------------------- 1 file changed, 2 insertions(+), 31 deletions(-) diff --git a/dev/crypto-notes.md b/dev/crypto-notes.md index ff7b46bc2..9e1683ee4 100644 --- a/dev/crypto-notes.md +++ b/dev/crypto-notes.md @@ -2,34 +2,5 @@ ### Key-pair generation -When compared to gpg without hardware-based (P)RNG, IPFS generates key-pair -alarmingly fast: it takes ipfs about 1 minute to generate 4096-bit -key-pair, but for gpg it takes about 10 minutes. In the same time -entropy_avail show severe drop in available entropy for gpg, but for -ipfs entropy drops about 100 bits. - -[This issue (#911)](https://github.com/jbenet/go-ipfs/issues/911) seems to be caused -by `crypto/rand` implementation in the Go programming language: - -1. [in UNIX-like](http://golang.org/src/crypto/rand/rand_unix.go) 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. - -2. [in Linux](http://golang.org/src/crypto/rand/rand_linux.go#L22) 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. - -3. [in Windows]() it uses Windows CryptGenRandom API. - -According to [wikipedia](https://en.wikipedia.org/?title=/dev/random) using /dev/urandom instead of /dev/random seems to be safe. +It is critical that we check cryptographic operations to ensure the right amount of entropy is being sourced. +See: [Issue #911](https://github.com/jbenet/go-ipfs/issues/911) \ No newline at end of file