Instead of assuming, you should've used Google ;-) To my (limited, I'm far from a crypto expert) understanding, Intel of course also seeds the PRNG with a true random number generator, and it complies NIST standard for randomness.
http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed I think what Ts'o was meaning, is that you fear NSA told Intel to lie and give non-random numbers that looks like random numbers (for which a trivial implementation is to encrypt a counter with a key known only to the NSA and Intel). On Thu, Jan 3, 2013 at 11:57 AM, Oleg Goldshmidt <p...@goldshmidt.org> 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. > > -- > Oleg Goldshmidt | p...@goldshmidt.org > > _______________________________________________ > Linux-il mailing list > Linux-il@cs.huji.ac.il > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il >
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
