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

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

Comments

But RdRand is broken on my

But RdRand is broken on my Ivy Bridge laptop due to a hardware bug acknowledged by Intel.  Is there some way around the illegal instruction exception caused by the hardware bug?  Even if it is not good manners with respect to the operating system?


Patrick - I submitted your question - please refer to our forum: http://software.intel.com/en-us/forums/showthread.php?t=104200

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof


Hi everyone, if you have questions, please post them to our Developer's Forum: http://software.intel.com/en-us/forums/intel-vpro-software-development/

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof


Hi,
The effort involved in the implementation of RdRand instruction to promote its use in security-related applications, in particular the self-testing functionality, is very impressive!
I'm interested in cryptographic applications of the RdRand instruction. Sometimes I might want an entropy source which is unaffected by deterministic processing which could potentially compromise my cryptographic applications. In particular, I am concerned that the Online Health Tests (OHTs) will affect the output of the RdRand instruction. Suppose the entropy source is in fact working properly. The ES will sometimes fail the OHT even though the entropy source is fine. That means that ES bit streams that fail the OHT will never be seen. Hence certain output sequences which would be generated by a perfectly random entropy source will never appear in an output sequence generated by the RdRand instruction. If I understand the documentation, there's a 65536 bit sliding window which is used for the OHT. 256-bit chunks output from the OHT are then used to create up to 1022 64-bit RdRands. It then seems if I only use one out of every 1022*65536/256 = 261,632 values returned by RdRand, each 64-bit sample selected will be outside the sliding window of all the other 64-bit samples selected.
Is that in fact the case? If I use only one out of every 261,632 calls to RdRand, will I in fact get 64-bit samples from non-overlapping sliding windows used by the OHT?
Even when the RdRand outputs I use are from non-overlapping sliding windows, it would still be helpful to know the exact algorithm used by the OHT to see if that might affect my cryptographic applications. Is documentation available for the algorithm used by the OHT? If not, I would like to request that.

Thank you,
Patrick


Aloha!

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?


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: @GaelHof
Facebook: https://www.facebook.com/GaelHof


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?


Hi,

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
Jirka


Hi David,

I have tried to model the conditioner using crypto++ library (http://www.cryptopp.com/). 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
http://www.phy.duke.edu/~rgb/General/dieharder.php
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
http://www.lavarnd.org/what/digital-blender.html
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?

Thanks
Jiri


Uwe,

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.


Pages