Download the Latest Intel® Digital Random Number Generator Software Implementation Guide

For more complete information about compiler optimizations, see our Optimization Notice.


javierandrescaceres's picture

Great resource!

's picture


thanks for a very nice article.

Could you share the details of operation of the whitener (conditioner)? What do you take as the key for AES? As AES based CBC_MAC will produce only 128 bits, are you producing two MACs which are then concatenate to 256 bit value?

Thanks a lot

's picture

I tried to compile the example using GCC 4.6.1. I got the following error:

» gcc -c rdrand.s -o rdrand.o
rdrand.c:71:no such instruction: `rdrand %ax'
rdrand.c:92:no such instruction: `rdrand %eax'
rdrand.c:113:no such instruction: `rdrand %rax'

Is there something I need to enable in GCC or when configure/compile it?

's picture


You have it right. AES-CBC-MAC is run twice for each reseed to get the necessary 256 bits of reseed state required by SP800-90 for a 128 bit AES core based CTR DRBG. The CBC-MAC key is fixed. It's value is not relevant to the security assurances of the algorithm when used as a conditioner.


's picture


Only The most recent versions of GCC and binutils has support for RdRand.
The code was compiled on "gcc version 4.6.0 20110110 (experimental) [trunk revision 168632] (GCC)" that was taken from GNU's repository.

There should now be full releases that support rdrand.

hladkyjiri's picture

Hi David,

I have tried to model the conditioner using crypto++ library ( Let's see if I have it right.

I take first 256 bits from entropy source (HW RNG) and send it to AES-CBC-MAC. It means first 128 input bits goes directly to AES. Output of AES is XORed with next 128 input bits and goes to AES, using the same fixed key. I will get 128 bits on output. I do the same with next 256 input bits using the same fixed key for AES, thus reducing 512 bits to 256 bits.

Now the question is how to model entropy source. Getting good entropy source using the hardware design is difficult, there will be always bias. Looking to Intel basic HW RNG design it's clear that it will be very very fast but I assume that quality of these random numbers will be poor. So I decided to take a very weak RNG to model entropy source - Linear congruential generator (LCG) with period 2^31-1

So my model is:
LCG -> AES-CBC-MAC (reducing 256 bits to 128bits)
while (true) {
rng.GenerateBlock( input, BLOCKSIZE_INPUT);
cbc_mac.CalculateDigest (output, input, BLOCKSIZE_INPUT);
cout.write(reinterpret_cast<const char *>(output),BLOCKSIZE_OUTPUT);

I have fed output to Dieharder Random Number Test Suite
only to find out that it's failing almost all tests.

Now designing a good conditioner is difficult. However, I'm quite disappointed with results I got. Am I missing something?

Next I'm going to test LavaRnd Digital Blendertm Algorithm
to see if it performs better.

You may call my test setup unrealistic but I think it's a valid test to see how conditioner performs. It seems that Intel's conditioner is designed to be very fast but giving up on quality. Higher quality could be probably achieved at the cost of the speed assuming lower entropy per bit (currently the reducing factor is 2).

Next I'm going to look at CSPRNG. I expect that it will make the weak points of conditioner to go away.

BTW, do you have some source code to share which will model new Intel's DRNG? I can also share my C code if you are interested.

Any comments, thoughts? Is my AES-CBC-MAC in sync with the operation of Intel's conditioner?


hladkyjiri's picture


I'm going to implement CTR_DRBG. I just would like to clarify few details:

Block Ciphre used: AES, 128 bit key, right?

How is entropy coming from conditioner used? Does it flow only to seed for CTR_DRBG? Are you using personalization_string, nonce, (init CTR_DRBG), Derivation function, additional_input (reseed)?

What criteria is used to decide if it's time to reseed CTR_DRBG?

Thanks a lot

's picture

As a security professional of 10 years, I'm creating a blog post about Bull Mountain RdRand. I want to have Intel's view about the blog article and some (3) design issues I'm experiencing with the Bull Mountain Software Implementation Guide. Who should I contact?

Gael Hofemeier (Intel)'s picture

Maarten Bodewes: Please send it to me in a private message - you should be able to do so from this interface. I will make sure it gets seen by the right people. We would love to have your blog post on our site as well (contact Kathy Farrel who is our Community Manager.)

Follow me on Twitter: @GHIntelBlogs Facebook:
's picture


I'm currently writing an article about random number generators in modern computers for the IDG TechWorld magazine (in Swedish). I'm planning to cover Bull Mountain in the article. Is there any press kit or similar with images etc available?