CPRNGs are still an issue.

[Steven M. Bellovin]

On Wed, 17 Dec 2008 13:02:58 -0500
Jerry Leichter <leichter at lrw.com> wrote:

> On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote:
> > I probably should not be commenting, not being a real device guy.   
> > But,
> > variations in temperature and time could be expected to change SSD  
> > timing.
> > Temperature changes will probably change the power supply voltages  
> > and shift
> > some of the thresholds in the devices.  Oscillators will drift
> > with changes
> > in temperature and voltage.  Battery voltages tend to go down over  
> > time and
> > up with temperature.  In addition, in some systems the clock  
> > frequency is
> > purposely swept over something like a 0.1% range in order to
> > smooth out the
> > RF emissions from the device.  (This can give a 20 or 30 dB  
> > reduction in
> > peak emissions at a given frequency.  There is, of course, no
> > change in
> > total emissions.)
> >
> > Combine all of these factors, and one can envision the SSD cycles  
> > taking
> > varying numbers of system clock ticks and consequently the low
> > order bits of
> > a counter driven by a system clock would be "random."  However,
> > one would
> > have to test this kind of entropy source carefully and would have
> > to keep
> > track of any changes in the manufacturing processes for both the
> > SSD and the
> > processor chip.
> >
> > Is there anyone out there who knows about device timing that can
> > say more?
> I'm not a device guy either, but I've had reason to learn a bit more  
> about SSD's than is widely understood.
> 
> SSD's are complicated devices.  Deep down, the characteristics of
> the underlying storage are very, very different from those of a
> disk. Layers of sophisticated hardware/firmware intervene to make a
> solid- state memory look like a disk.  To take a very simple
> example:  The smallest unit you can read from/write to solid state
> memory is several times the size of a disk block.  So to allow
> software to continue to read and write individual "disk blocks", you
> have to do a layer of buffering and blocking/deblocking.  A much more
> obscure one is that the throughput of the memory is maximum when you
> are doing either all reads or all writes; anywhere in between slows
> it down.  So higher- performance SSD's play games with what is
> essentially double buffering:  Do all reads against a segment of
> memory, while sending writes to a separate copy as well as a
> look-aside buffer to satisfy reads to data that was recently
> written.  Switch the roles of the two segments "at some point".
> 
But what is the *physical basis* for the randomness?
http://www.springerlink.com/content/gkbmm9nuy07kerww/ (full text
at http://world.std.com/~dtd/random/forward.pdf) explains why hard drive
timings are considered random; are their comparable phenomena for SSDs?
(Of course -- that's a '94 paper; hard drive technology has changed a
lot.  Would they still get the same results?)


		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com