CPRNGs are still an issue.
Steven M. Bellovin
smb at cs.columbia.edu
Wed Dec 17 15:18:36 EST 2008
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
More information about the cryptography