What seeds CeGenRandom?
bsqr_TSAT
George McCollister
> Does anyone know what seeds the CeGenRandom() function?
>
>
Do you not have access to CryptGenRandom? CryptGenRandom is FIPS 140-1
approved (at least in Windows 2000). The Windows 2000 version of the
function (which hopefully isn't too different from the CE version) seeds
from 100+ different inputs including: QueryPerformanceCounter, internal
CPU counters, current time, process information like idle process time,
io read transfer count, etc....
I would suspect that CeGenRandom uses a similar (but probably much
smaller) list of inputs. Its probably suitable for nearly everything
except encryption purposes.
Regards,
George McCollister
NovaTech LLC
bsqr_TSAT
We're trying to generate a random # very early in a very deterministic boot
process. Right now, the cryptography services aren't available.
CeGenRandom seems to work (whereas Random doesn't), but I would like to know
exactly what is being used to generate the number.
"George McCollister" <geo...@novatech-llc.com> wrote in message
news:%23OAkuVF...@tk2msftngp13.phx.gbl...
Don Dumitru [MSFT]
through a cryptographic hash algorithm. CryptGenRandom is not going to be
more random than CeGenRandom, because the output of CeGenRandom is what
seeds CryptGenRandom.
In Windows CE 5.0, CeGenRandom is seeded from...
- 64 bits of "noise" from the kernel level, which gets updated on task
switches
- the output from IOCTL_HAL_GET_RANDOM_SEED
- the output from IOCTL_HAL_GET_HWENTROPY
- the output from GetLocalTime
- the current process ID
- the current thread ID
- the current tick count
- the output from GetMessagePos
- the output from GlobalMemoryStatus
- the output from GetStoreInformation
(I don't have easy access to information about the implemention on earlier
versions of Windows CE.)
Early in the boot process, CeGenRandom is not very random, because there
just hasn't been an opportunity for it to collect any entropy. We are
actively investigating what we can do to increase the quality of the random
number generation, early in the boot process.
I am on the team responsible for CeGenRandom and CryptGenRandom, and I
invite you to send me an email directly (remove the "online" from my posted
emal address), to discuss what tact your might take. With suitable entropy,
CenGenRandom is a reasonable-quality generator, but the trick is getting it
to seed well - the IOCTL_HAL_GET_RANDOM_SEED mechanism lets an OEM provide
their own seed, but what are you going to seed it with?
(In addition, if you aren't on Windows CE 5.0, let me know what version you
are on, and I can investigate the older source trees.)
--Don
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"bsqr_TSAT" <TSatagaj at hotmail dot com> wrote in message
news:eJmpEMHj...@TK2MSFTNGP10.phx.gbl...
bsqr_TSAT
That's exactly what I was looking for.
I'm building this for CE4.2.
I didn't code it yet, but I'm pretty sure that I know what I will do.
From OEMInit(), we start the system timer and a couple of other timers.
I think that I can read values from the h/w countdown registers, mangle them
together, and create a good random seed of 4 or 5 bytes.
Thanks again for your info
"Don Dumitru [MSFT]" <do...@online.microsoft.com> wrote in message
news:eyN1W5lj...@tk2msftngp13.phx.gbl...
Don Dumitru [MSFT]
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
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"bsqr_TSAT" <TSatagaj at hotmail dot com> wrote in message
news:elO8j9uj...@TK2MSFTNGP15.phx.gbl...
George McCollister
> 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