This question was already answered by Linus Torvalds for Linux, and is also cited in this Q/A on this stack:

We use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random.

What is the status for Windows 10? Does Windows provide a random source mixing RDRAND with other sources or any sofisticated processing that can countermeasure possible backdoors in RDRAND? Or is there a set of possibilities and one should scrutanize every windows library case by case?

  • The title of the question is not very clear, would it be ok to change it to something like "Is RDRAND used in a safe way by Windows 10?" ? – gbr Oct 16 at 18:02
up vote 3 down vote accepted

In short:

Maybe (see the Conclusions).


Windows's default random generation process is described in considerable detail in its Common Criteria and FIPS 140 validation documents.

For Common Criteria in the Windows "Security Target" documents.
For FIPS in the Microsoft's "Kernel Mode Cryptographic Primitives Library" and "OS Loader" ones.

Do get all three of them, there are details in the Common Criteria documents absent from the FIPS ones, and vice-versa.

These are the most recent versions at the moment of writing, which apply to Windows 10 Fall Creators Update:

I also found this paper from 2015 which analyzes the topic in some detail:
Windows and Linux Random Number Generation Process: A Comparative Analysis.

It treats Windows 8, though (for example, you might notice that it mentions the infamous Dual_EC_DRBG, but that was removed in Windows 10).


Since StackOverflow usually doesn't like links, I replicate here most of the details:

| Boot-time seed

First, a 512-bits boot-time entropy seed is generated:

Entropy is gathered from the following sources, when they are available on the computer:

  1. The contents of the registry value HKLM\System\RNG\Seed, which is written by the Kernel Mode Cryptographic Primitives Library (cng.sys) during its normal operation.
  2. The contents of the registry value HKLM\System\RNG\ExternalEntropy, which can be populated by system administrators. This value is overwritten after reading, to ensure that it is not reused.
  3. If a Trusted Platform Module (TPM) is available, the output of a TPM_GetRandom call to the TPM.
  4. The current system time.
  5. The contents of the OEM0 ACPI table in the machine firmware.
  6. If the CPU supports instructions for the RDSEED ( used when available) or RDRAND (used if RDSEED is not available), the output from RDSEED or RDRAND.
  7. The output of the UEFI random number generator.
  8. The CPU timings.

These inputs are then combined using SHA-512, and the entropy source is conditioned using a non-Approved RNG. From this NDRNG, a block of output bytes is passed to the Windows kernel at boot time

source: FIPS OS Loader


I'm not sure what they mean with "conditioned using a non-Approved RNG".

| Entropy pool

At runtime, at all times, there is then a "Windows entropy pool", which

is populated using the following values:

  • An initial entropy value from a seed file provided to the Windows OS Loader at boot time (512 bits of entropy). (the boot-time seed)
  • A calculated value based on the high-resolution CPU cycle counter which fires after every 1024 interrupts (a continuous source providing 16384 bits of entropy).
  • Random values gathered periodically from the Trusted Platform Module (TPM), (320 bits of entropy on boot, 384 bits thereafter on demand based on an OS timer).
  • Random values gathered periodically by calling the RDRAND CPU instruction, (256 bits of

source: Common Criteria

The Windows DRBG infrastructure located in cng.sys continues to gather entropy from these sources during normal operation, and the DRBG cascade is periodically reseeded with new entropy

source: FIPS Kernel Mode


I was unable to find out how these sources are combined, if they even are.

Maybe they use the same system as the boot-time sources, maybe they are just laid out one after another and taken up in turns :o .

The 2015 paper seems to assume that they're combined in the same way as the boot-time seed, but I couldn't find any sources to substantiate that and I think it's likely that the authors jumbled up the two by mistake.

| BCryptGenRandom

The recommended function for obtaining random data, BCryptGenRandom, then works by using this pool as a seed for a NIST SP 800-90A AES-256 counter mode based DRBG.


It might be a good system, and so RDRAND might be being used in a good way, but until someone clarifies if and how the entropy pool sources are combined, I don't think we can really tell.
It would be very surprising if the pool sources were not mixed-up, but then again... maybe not so much.

In any case, I must emphasize that I'm not really an expert in this field, I might well have missed something and it might even be that it wouldn't matter if the sources weren't mixed.
I meant to only reports the documents that I found, but as I noticed these things I thought I would mention them as well.

Wait for the opinion of some qualified cryptographer before drawing a conclusion (and most of all, of course, try to find out how this pool really works).


  • Of course keep in mind that this is just the recommended way to get random data, any application is free to use what it wants.

  • Note also that as these certifications might (I'm not certain) apply only when Windows is running in FIPS mode, this information might be guaranteed to be valid only when that mode is enabled.
    One sure difference is that only in FIPS mode there are some self-tests performed on the DRBG on start-up and during a reseed, as mandated by SP 800-90A (but there are probably few circumstances in which they would be useful).

  • Of course this is always a closed-source system, updated all the time, so we can't be a hundred percent sure of what it really does (unless we don't reverse-engineer our own and block further updates).

P.S.: Long links look really bad with the new theme

  • 1
    While you have described a good way to get a cryptogrically random number, a lot of programs just call a random() function and leave it at that. Depending on the language the implementation could be extremely predictable. For example Delphi (OO Pascal) has a random that's seeded with the time of day. There is no forced source of random in Windows. I have to say @gbr you really out together a through answer. I'm surprised you don't have more up votes. – Daisetsu Oct 12 at 23:46
  • 1
    @gbr I have some knowledge in cryptography and I confirm you that several sources of random numbers shall be mixed. Thanks for your deep and complete answer – lalebarde Oct 14 at 17:14
  • 1
    @Daisetsu No operating system has a "forced source of random", how would you enforce it? For any software, only its developer knows where there ought to be random data, and he's always free to use if he chooses so... – gbr Oct 16 at 18:11

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.