RNG (was: Re: SSD drives)

[Yedidyah Bar-David]

On Thu, Jan 03, 2013 at 11:57:01AM +0200, Oleg Goldshmidt wrote:
> On Thu, Jan 3, 2013 at 10:53 AM, Baruch Siach <baruch at 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-il at 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