SSD drives

[Elazar Leibovich]

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 <pub at goldshmidt.org> 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.
>
> --
> Oleg Goldshmidt | pub at goldshmidt.org
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20130103/20f1054f/attachment.html>