[cryptography] RDRAND and Is it possible to protect against malicious hw accelerators?

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sun Jun 19 00:56:34 EDT 2011

Marsh Ray <marsh at extendedsubset.com> writes:
>Just to pick on Peter Gutmann:
>> How would you encode, for example, 'RdRand eax'?
>> I'd like to get the encoded form to implement it as '__asm _emit 0x0F __asm
>> _emit 0xC7 __asm _emit <something>' (in the case of MSVC).
>Note that he's not asking about how to check the carry flag too. 

I know how to check the carry flag from inline asm, I just don't know what the 
rdrand encoding is.  Here's the code I sent to the OP, I hadn't posted it yet 
because I need to get someone with access to the appropriate hardware to 
verify it:

#if defined( _MSC_VER )
  #define rdrand_eax    __asm _emit 0x0F __asm _emit 0xC7 __asm _emit 0xF0
#endif /* VC++ */
#if defined __BORLANDC__
  #define rdrand_eax    } __emit__( 0x0F, 0xC7, 0xF0 ); __asm {
#endif /* BC++ */

    __asm {
        xor eax, eax        /* Tell VC++ that EAX will be trashed */
        jc trngOK           /* TRNG result OK */
        xor eax, eax        /* Clear result register */

(there's rather more to it than that, e.g. the cpuid checks, and it's 
different for 32- and 64-bit mode, that code isn't included above).
>I'm sure he of all people wouldn't forget this, but not so for your typical 

I would hope that the only exposure to this for most developers is the 
CryptGenerateKey() API of their crypto library.  Since rdrand use also 
requires checking for CPU types and steppings and not just the carry flag, I'd 
expect anyone using it to know what they're doing, and J.Random programmer 
wouldn't be using it at that level anyway.

>Still, we can predict how this story will turn out because we have several 
>examples of what happens in practice when RNGs decide that they have "run 
>out" of numbers: the client code continues running with whatever garbage it 
>gets because it's not a situation that the software developer ever encountered 
>in his debugger, or one which a QA team ever noticed in the lab.

Depends on whether they use this as their sole entropy source... at the moment 
that's pretty much excluded because you can't guarantee its presence, but even 
without that I would hope that no implementation worth its salt ever does 
this, it's something I talked about in my decade-old paper on seeded-PRNG 
design, and from other PRNGs I looked at they all had multiple sources of 
seeding (many not nearly as many as I'd have liked, but at least they had more 
than one).

>So the Intel "DRNG" has observable shared internal state and is shared among 
>multiple cores.

The rule for security there is that if an attacker can get physical access to 
the same CPU as you, you're toast via any number of side-channel attacks 
anyway.  So the solution is "don't do that, then".  I don't really see this 
issue as a problem.

>This is a recipe for fail.

Naah, nothing that drastic, it's just a recipe for "use a crypto library 
written by someone competent rather than trying to roll your own".


More information about the cryptography mailing list