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

Andy Isaacson adi at
Fri Sep 6 22:24:00 PDT 2013

On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote:
> On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson <adi at> 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].

That's the claimed design, yes.  I see no particular reason to believe
that the hardware in my server implements the design.  I can't even test
that the AES whitening does what it is documented to do, because Intel
refused to provide access to the prewhitened input.

Providing accessible "test points" (software interfaces to the innards
of the implementation, with documentation of expected behavior between
the components) would be the absolute minimum to provide believable
assurance of the absence of a backdoor.  Better would be documents from
Intel of how the chip is designed at the mask level, and a third party
mill-and-microphotograph of a retail chip showing that the shipped
implementation matches the design.

Intel will never go for that, of course, since their chip masks are
their jealously guarded IP.  Since they can't provide evidence of a lack
of a backdoor, any reasonably cautious user should avoid depending on
Intel's implementation.


More information about the liberationtech mailing list