On Thu, Jan 03, 2013 at 11:57:01AM +0200, Oleg Goldshmidt wrote: > On Thu, Jan 3, 2013 at 10:53 AM, Baruch Siach <bar...@tkos.co.il> wrote: > > Hi Oleg, > > > > On Sun, Dec 30, 2012 at 10:40:31AM +0200, Oleg Goldshmidt wrote: > >> On Sun, Dec 30, 2012 at 8:46 AM, shimi <linux...@shimi.net> wrote: > >> > I really don't think so. SSDs (IMHO) makes computer much faster due to > >> > the > >> > VERY low seek time - the time it takes you to get a block. Compare > >> > 10-20ms > >> > with ~0.1ms. A regular hard drive simply wastes a lost of time seeking > >> > the > >> > data, instead of... reading it :) > >> > >> Absolutely correct. However, there is a tiny fraction of the seek time > >> that is not always a waste, and I think it is worth mentioning. There > >> is, I believe, a consideration that is usually overlooked when SSDs > >> are considered for server use, including a "desktop" that is used as a > >> server, which is why I am mentioning it here. In a server, magnetic > >> disk rotation - or, rather the air turbulence generated between the > >> rotating disk and its enclosure - is the only source of entropy that > >> makes random numbers random (seek times have a tiny random component > >> due to the turbulence, and it is captured). This does not apply to > >> SSDs, and as a result your security may be compromised (attacks > >> exploiting not very random RNGs are well known). > > > > Recent Intel CPUs introduced the RDRAND instruction that is essentially a > > Random Number Generator. Recent kernels (v3.2 and later) added support for > > this instruction. See http://git.kernel.org/linus/628c6246d4. See also the > > related commit (from v3.6) at http://git.kernel.org/linus/c2557a303 (and > > note > > the funny commit log). > > > > These patches were backported to all supported stable kernel trees (back to > > v2.6.32). > > Note that the commit log (and Ted Ts'o really knows what he is talking > about) makes an important point, and I'll add one of my own. > > 1) Always use /dev/random even if a HW RNG is available. /dev/random > is where the disk-generated entropy ends up. If /dev/random is not > there you are in trouble. > > 2) I would not only be worried about an NSA backdoor in Intel CPUs, > but also about the degree of randomness of their generator. If it is > flawed (and it is notoriously difficult to do a really good PRNG - I > assume it is a PRNG, otherwise Ted would not be worried about NSA > backdoor) you will have no fix path. A PRNG needs a truly random seed > at least, which is where /dev/random comes in.
Quoting section 3.2.1 of http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ : "The ES runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz". (it's linked to from the commit log). Naturally, you can't trust that without an electronic microscope, as Ted Ts's said. /dev/random blocks. With normal server hardware and a default setup, it will not provide you with more than a few tens of random bits per second. If you can live with that, use it. /dev/urandom is a PRNG, fast - a few MiB per second, does not block. RDRAND is also a PRNG, reseeded at most once every 1022 calls, way faster than /dev/urandom (they state 500MiB per second), and you do not have its source code... Use what fits you best. -- Didi _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
