George
Wed Sep 01 08:23:16 CDT 2004
Don Dumitru [MSFT] wrote:
> Depending on your situation, your solution might or might not be "good
> enough". Some devices can be *extremely* predictable during early boot
> time - especially simple devices, with very few peripherals. For example,
> without external events triggering an ISR during the process, it will often
> take the exact number of CPU instructions to boot the device.
>
> Just using a timer won't necessarily provide good entropy, because often the
> design goal of the hardware timer is to be predictable. What is going to
> prevent it from always taking the same number of CPU instructions to start
> the hardware timers, and then the same number of CPU instructions before you
> get to the point where you read the values out?
>
> --Don
>
>
Here are some additional ideas:
QueryPerformanceCounter (this may be the same as the timer you were
referring to and may not vary between boots depending on your device).
Power source voltage level. If your device is running off of a power
source like a battery from which the voltage can be queried. You also
might be able to obtain information like battery wear, charge level etc.
Uninitialized memory. On some systems RAM will come up to rather random
values on power up. If you can get to it before its cleared, you could
do an MD5 or SHA hash of a large segment of memory and use that as part
of the seed. If your device has any persistent storage, like flash
memory or a hard disk (assuming information on the flash isn't just a
non changing boot image) you could also run a hash on part or all of that.
Ethernet MAC Address
USB, WiFi and Bluetooth or maybe even Ethernet. Its quite a stretch, but
if your device uses WiFi, Bluetooth, or USB you might be able to obtain
some changing information like connected devices, signal strength, Wifi
SSIDs etc.
You might also have a look at this page:
http://www.irisa.fr/caps/projects/hipsor/HAVEGE.html
Regards,
George McCollister