CPRNGs are still an issue.
Jerry Leichter
leichter at lrw.com
Wed Dec 17 13:02:58 EST 2008
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 majordomo at metzdowd.com
More information about the cryptography
mailing list