Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Random number generation being influenced - rumors

Maxim Kammerer mk at dee.su
Fri Sep 6 14:51:19 PDT 2013


On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson <adi at hexapodia.org> wrote:
> This is not to say that RdRand is completely unusable.  Putting RdRand
> entropy into a software pool implementation like /dev/urandom (or
> preferably, a higher-assurance multipool design like Fortuna) is a cheap
> way to prevent a putative backdoor from compromising your system state.

Nearly nothing from what you wrote is relevant to RDRAND, which is not
a pure HWRNG, but implements CTR_DRBG with AES (unclear whether
128/192/256) from NIST SP 800-90A [1,2]. Interaction with hardware
entropy source (ES) is implemented in microcode, so in case the
relevant microcode is reverse-engineered (or relevant documentation
obtained from Intel), it is possible to verify correctness of most of
RDRAND operation. ES operation could be perhaps analyzed in a lab.

The choice of CTR_DRBG over (probably much faster) Hash_DRBG seems
weird on first sight, but secure hashes are not yet available in Intel
processors [3]. Of course, an interesting conspiracy theory would then
be that NSA influenced Intel to delay secure hash instructions
deployment after breaking AES in order to exploit an AESNI-based
RDRAND.

[1] http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide
[2] http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
[3] http://software.intel.com/en-us/articles/intel-sha-extensions

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte



More information about the liberationtech mailing list