RdRand: History
Please note this is an old version of this entry, which may differ significantly from the current revision.
Subjects: Others
Contributor:

RDRAND (previously known as Bull Mountain) is an instruction for returning random numbers from an Intel on-chip hardware random number generator which has been seeded by an on-chip entropy source. RDRAND is available in Ivy Bridge processors[lower-alpha 1] and is part of the Intel 64 and IA-32 instruction set architectures. AMD added support for the instruction in June 2015. The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, FIPS 140-2, and ANSI X9.82. Intel also requested Cryptography Research Inc. to review the random number generator in 2012, which resulted in the paper Analysis of Intel's Ivy Bridge Digital Random Number Generator. RDSEED is similar to RDRAND and provides higher level access to the entropy hardware. The RDSEED generator and processor instruction rdseed are available with Intel Broadwell CPUs and AMD Zen CPUs.

  • random number generator
  • random numbers
  • cryptography

1. Overview

The CPUID instruction can be used to check whether the central processing unit (CPU) supports the RDRAND instruction on both AMD and Intel CPUs. If supported, bit 30 of the ECX register is set after calling CPUID standard function 01H.[1] AMD processors are checked for the feature using the same test.[2] RDSEED availability can be checked on Intel CPUs in a similar manner. If RDSEED is supported, the bit 18 of the EBX register is set after calling CPUID standard function 07H.[3]

The opcode for RDRAND is 0x0F 0xC7, followed by a ModRM byte that specifies the destination register and optionally combined with a REX prefix in 64 bit mode.[4]

Intel Secure Key is Intel's name for both the RDRAND instruction and the underlying random number generator (RNG) hardware implementation,[5] which was codenamed "Bull Mountain" during development.[6] Intel calls their RNG a "digital random number generator" or DRNG. The generator takes pairs of 256-bit raw entropy samples generated by the hardware entropy source and applies them to an Advanced Encryption Standard (AES) (in CBC-MAC mode) conditioner which reduces them to a single 256-bit conditioned entropy sample. A deterministic random-bit generator called CTR_DRBG defined in NIST SP 800-90A is seeded by the output from the conditioner, providing cryptographically secure random numbers to applications requesting them via the RDRAND instruction.[5][6] The hardware will issue a maximum of 511 128-bit samples before changing the seed value. Using the RDSEED operation provides access to the conditioned 256-bit samples from the AES-CBC-MAC.

The RDSEED instruction was added to Intel Secure Key for seeding another pseudorandom number generator,[7] available in Broadwell CPUs. The entropy source for the RDSEED instruction runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz,[8] slower than the effective 6.4Gbit/s obtainable from RDRAND (both rates are shared between all cores and threads).[9] The RDSEED instruction is intended for seeding a software PRNG of arbitrary width, whereas the RDRAND is intended for applications that merely require high-quality random numbers. If cryptographic security is not required, a software PRNG such as Xorshift is usually faster.[10]

1.1. Performance

On an Intel Core i7-7700K, 4500 MHz (45 x 100 MHz) processor (Kaby Lake-S microarchitecture), a single RDRAND or RDSEED instruction takes 110ns or 463 clock cycles, regardless of the operand size (16/32/64 bits). This number of clock cycles applies to all processors with Skylake or Kaby Lake microarchitecture. On the Silvermont microarchitecture processors, each of the instructions take around 1472 clock cycles, regardless of the operand size; and on Ivy Bridge processors it takes up to 117 clock cycles.[11]

On an AMD Ryzen CPU, each of the instructions takes around 1200 clock cycles for 16-bit or 32-bit operand, and around 2500 clock cycles for a 64-bit operand.

An astrophysical Monte Carlo simulator examined the time to generate 107 64-bit random numbers using RDRAND on a quad-core Intel i7-3740 QM processor. They found that a C implementation of RDRAND ran about 2x slower than the default random number generator in C, and about 20x slower than the Mersenne Twister. Although a Python module of RDRAND has been constructed, it was found to be 20x slower than the default random number generator in Python.[12]

1.2. Compilers

GCC 4.6+ and Clang 3.2+ provide intrinsic functions for RdRand when -mrdrnd is specified in the flags,[13] also setting __RDRND__ to allow conditional compilation. Newer versions additionally provide immintrin.h to wrap these built-ins into functions compatible with version 12.1+ of Intel's C Compiler. These functions write random data to the location pointed to by their parameter, and return 1 on success.[14]

1.3. Sample x86 asm Code to Check upon RDRAND Instruction

; using NASM syntax section .data msg db "0x00000000",10 section .text global _start _start: mov eax,1 cpuid bt ecx,30 mov edi,1 ; exit code: failure jnc .exit ; rdrand sets CF=0 if no random number ; was available. Intel documentation ; recommends 10 retries in a tight loop mov ecx,11 .loop1: sub ecx, 1 jz .exit ; exit code is set already rdrand eax jnc .loop1 ; convert the number to ASCII mov rdi,msg+9 mov ecx,8 .loop2: mov edx,eax and edx,0Fh ; add 7 to nibbles of 0xA and above ; to align with ASCII code for 'A' ; ('A' - '0') - 10 = 7 mov r8d, 7 xor r9d, r9d cmp dl,9 cmova r9,r8 add edx,r9d add [rdi],dl shr eax,4 dec rdi loop .loop2 mov eax,1 ; SYS_WRITE mov edi,eax ; stdout=SYS_WRITE=1 mov esi,msg mov edx,11 ; msg length syscall xor edi,edi ; exit code zero: success .exit: mov eax,60 ; SYS_EXIT syscall

2. Applications

It is an option to generate cryptographically-secure random numbers using RDRAND and RDSEED in OpenSSL, to help secure communications.

The first scientific application of RdRand can be found in an astrophysics. Radio observations of low-mass stars and brown dwarfs have revealed that a number of them emit bursts of radio waves. These radio waves are caused by magnetic reconnection, the same process that causes solar flares on the Sun. RdRand was used to generate large quantities of random numbers for a Monte Carlo simulator, to model physical properties of the brown dwarfs and the effects of the instruments that observe them. They found that about 5% of brown dwarfs are sufficiently magnetic to emit strong radio bursts. They also evaluated the performance of the RdRand instruction in C and Python compared to other random number generators.[12]

3. Reception

In September 2013, in response to a The New York Times article revealing the NSA's effort to weaken encryption,[15] Theodore Ts'o publicly posted concerning the use of RdRand for /dev/random in the Linux kernel:[16]

I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction. To quote from the [New York Times article[15]]: 'By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors....' Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.

Linus Torvalds dismissed concerns about the use of RdRand in the Linux kernel, and pointed out that it is not used as the only source of entropy for /dev/random, but rather used to improve the entropy by combining the values received from RdRand with other sources of randomness.[17][18] However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator could become insecure if a backdoor is introduced into the RdRand instruction that specifically targets the code using it. Hornby's proof-of-concept implementation works on an unmodified Linux kernel prior to version 3.13.[19][20][21]

Developers changed the FreeBSD kernel away from using RdRand and VIA PadLock directly with the comment "For [FreeBSD] 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more"[17][22]

The content is sourced from: https://handwiki.org/wiki/RdRand

References

  1. "Volume 1, Section 7.3.17, 'Random Number Generator Instruction'". Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C. Intel Corporation. June 2013. p. 177. http://download.intel.com/products/processor/manual/325462.pdf. Retrieved 24 June 2013. "All Intel processors that support the RDRAND instruction indicate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1" 
  2. "AMD64 Architecture Programmer’s Manual Volume 3: General-Purpose and System Instructions". AMD. June 2015. p. 278. http://support.amd.com/TechDocs/24594.pdf. Retrieved 15 October 2015. "Support for the RDRAND instruction is optional. On processors that support the instruction, CPUID Fn0000_0001_ECX[RDRAND] = 1" 
  3. "Volume 1, Section 7.3.17, 'Random Number Generator Instruction'". Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C. Intel Corporation. June 2013. p. 177. http://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf. Retrieved 25 October 2015. "All Intel processors that support the RDSEED instruction indicate the availability of the RDSEED instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1" 
  4. "Intel® Digital Random Number Generator (DRNG) Software Implementation Guide | Intel® Developer Zone". Software.intel.com. http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide. Retrieved 2014-01-30. 
  5. "Intel Digital Random Number Generator (DRNG): Software Implementation Guide, Revision 1.1" (PDF). Intel Corporation. 2012-08-07. http://software.intel.com/sites/default/files/m/d/4/1/d/8/441_Intel_R__DRNG_Software_Implementation_Guide_final_Aug7.pdf. Retrieved 2012-11-25. 
  6. Taylor, Greg; Cox, George (September 2011). "Behind Intel's New Random-Number Generator". IEEE Spectrum. http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0. 
  7. John Mechalas (November 2012). "The Difference Between RDRAND and RDSEED". software.intel.com. Intel Corporation. http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed. Retrieved 1 January 2014. 
  8. Mechalas, John. "Intel Digital Random Number Generator (DRNG) Software Implementation Guide, Section 3.2.1 Entropy Source (ES)". Intel. https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide. Retrieved 18 February 2015. 
  9. https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide says 800 megabytes, which is 6.4 gigabits, per second
  10. The simplest 64-bit implementation of Xorshift has 3 XORs and 3 shifts; if these are executed in a tight loop on 4 cores at 2GHz, the throughput is 80 Gb/sec. In practice it will be less due to load/store overheads etc, but is still likely to exceed the 6.4 Gb/sec of RDRAND. On the other hand, the quality of RDRAND's numbers should be higher than that of a software PRNG like Xorshift.
  11. http://www.agner.org/optimize/instruction_tables.pdf
  12. Route, Matthew (August 10, 2017). "Radio-flaring Ultracool Dwarf Population Synthesis". The Astrophysical Journal 845: 66. doi:10.3847/1538-4357/aa7ede.  https://dx.doi.org/10.3847%2F1538-4357%2Faa7ede
  13. https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/X86-Built-in-Functions.html
  14. https://software.intel.com/en-us/node/523864
  15. Perlroth, Nicole; Larson, Jeff; Shane, Scott (September 5, 2013). "N.S.A. Able to Foil Basic Safeguards of Privacy on Web". The New York Times. https://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html. 
  16. Ts'o, Theodore (September 6, 2013). "I am so glad I resisted pressure from Intel engineers to let /dev/random rely...". https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J. 
  17. Richard Chirgwin (2013-12-09). "FreeBSD abandoning hardware randomness". The Register. https://www.theregister.co.uk/2013/12/09/freebsd_abandoning_hardware_randomness/. 
  18. Gavin Clarke (10 September 2013). "Torvalds shoots down call to yank 'backdoored' Intel RdRand in Linux crypto". theregister.co.uk. https://www.theregister.co.uk/2013/09/10/torvalds_on_rrrand_nsa_gchq/. Retrieved 12 March 2014. 
  19. Taylor Hornby (6 December 2013). "RDRAND backdoor proof of concept is working! Stock kernel (3.8.13), only the RDRAND instruction is modified.". https://twitter.com/defusesec/status/408975222163795969. Retrieved 9 April 2015. 
  20. Taylor Hornby [@DefuseSec] (10 September 2013). "I wrote a short dialogue explaining why Linux's use of RDRAND is problematic. http://pastebin.com/A07q3nL3 /cc @kaepora @voodooKobra". https://twitter.com/DefuseSec/status/377609001258598400. 
  21. "Randomness generation". 16 May 2014. http://cr.yp.to/talks/2014.05.16/slides-dan+tanja-20140516-4x3.pdf. Retrieved 9 April 2015. 
  22. "FreeBSD Quarterly Status Report". Freebsd.org. http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security. Retrieved 2014-01-30. 
More
This entry is offline, you can click here to edit this entry!
Video Production Service