Page 14 of Microsoft's TPM abstraction says that is allows for "stirring"

A call to BCryptGenRandom will fill the caller-provided buffer with random data. The maximum random number size is limited to 4,096 bytes per call. The provider may make several round trips to the TPM to fill the caller’s buffer and the call will block until the request is satisfied.

The provider also supports “stirring” the RNG in the TPM, by providing the flag BCRYPT_RNG_USE_ENTROPY_IN_BUFFER with the call BCryptGenRandom. If this flag is set, the provider will stir the entropy generator in the TPM with the data in the caller’s buffer. If the buffer is larger than 256 bytes, only the first 256 bytes will be used.

(note to reader, "bcrypt" referenced above has no relation to the hashing algorithm, it's a descriptor for a MSFT-technology)


  • How is this in-buffer entrophy used, and why would someone want to improve on entropy?

I remember a previous question on SE that says that combining RNGs from two different sources (system provided + BouncyCastle) was ill advised and will result in a net decrease in security.

How is this "stirring of entropy" any different?


RNGs measure true randomness, but must "whiten" their output using a PRNG. The PRNG has an internal state (initialized during seeding, and mutated after every new batch of data is output) of a fixed size, say 256 bits. The RNG also maintain a counter of how much entropy that state actually represents. Each time you read N bits from the "pool", it comes out of the PRNG, and the entropy counter is decreased. (If none is left, the call blocks until the requested amount is there.) Each time a new batch of true randomness is produced, it is hashed into the PRNG's state, and the entropy counter is increased by the number of bits of entropy that batch of randomness represents. (This is usually a conservative estimate.)

In this context, "stirring" means hashing a new value into the PRNG state without increasing the entropy counter. This is not a security risk, because the RNG is not trusting that this represents actual additional entropy. OTOH, if your RNG is poor and is delivering less entropy than it is supposed to, "stirring" in more entropy from somewhere else will protect it.


I'm fuzzy myself on how Microsoft gathers entropy for encryption, but I can answer the last part of your question. Entropy is essentially "random" data used by encryption algorithms. I say "random" because conventional computers have no way of generating truly random data, so they rely on other methods. For example, the linux kernel relies on things like mouse movement and keyboard timings to generate 4096 bytes of pseudo-random data in /dev/random (let the random vs urandom flame war begin).

The randomness of the data directly affects the strength of the encryption. For example, in one time pads, every letter in a message is shifted by a random amount of spaces, as determined by the pad. If an attacker can predict the "random" data, they can decode the key.

Now, as to why someone would want to improve on in-buffer entropy, it essentially has to do with this concern. Secure encryption relies on randomness. If a user does not think Microsoft's entropy pool is random enough for their purposes, they could say rig up a Geiger-counter to a radioactive isotope and rely on quantum mechanics to provide truly random data.

Is this overkill? yes. But the underlying ability to add entropy is great. For example, a linux server might not have alot of mouseclicks or keyboard events, so a developer would have to build in his own sources of entropy. I assume the concept is similar with Microsoft products.

As to what "stirring" means exactly I'm not sure. It could mean using a hash algorithm to create a bigger pool of data, or it could mean XORing bytes from your entropy with Microsoft's existing sources.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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