CPRNGs are still an issue.

[Jerry Leichter]

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