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".
Put all this together and the performance visible even at the OS
driver level will certainly show all kinds of variation. However,
just because there's variation doesn't mean there's entropy to be
had! You'd need to have a sufficiently detailed model of the inner
workings of the SSD to be confident that the variations aren't
predictable. However, you're not likely to get that: Getting good
performance out of SSD's is a black art. The techniques are highly
proprietary right now, because they are what make an SSD competitive.
Further, of course, anything you did learn would likely apply to one
manufacturing run of one model - just about anything could change at
any time.
So ... use with extreme caution. Estimate conservatively. Mix any
apparent entropy you get with other sources.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
