[cryptography] Intel RNG

Marsh Ray marsh at extendedsubset.com
Fri Jun 22 13:06:47 EDT 2012

On 06/21/2012 09:05 PM, ianG wrote:
> On 22/06/12 06:53 AM, Michael Nelson wrote:
>> "At the output of the DRBG, through RdRand, you have no visibility
>> of these processes. We seek to limit the side channels through
>> which an attacker could determine the internal state of the DRNG."
> Good answer!

This be the right choice, but I can't figure out how it's different from 

>> I suppose that if the rng was shared between multiple processes,
>> and if a malicious process could read the internal state, then it
>> could predict what another process was going to be given in the
>> near future.
>> That said, I think that it's a natural factoring to let the user
>> see the bits directly from the hardware source, before any
>> massaging. Perhaps this could be a mode.

Perhaps another way to phrase it is providing a different source of 
(raw, unconditioned) entropy for folks who already have a software pool 
which requires entropy estimates on the incoming data.

> It's a natural human question to ask. "I want to see what's under the
> hood." But it seems there is also a very good response - if you can
> see under the hood, so can your side-channel-equipped attacker.

It seems to me that the bits one gets to see via RdRand aren't a side 
channel, by defintion. But if the attacker gets to see a disjoint set of 
samples from the same oscillator then we only need to worry about 
dependencies lurking between the sample sets.

The oscillator is a fairly simple circuit, so it should be 
straightforward to show it has a memory capacity of only bit or two. 
Allowing the oscillator to run for a few cycles between sample sets 
going to different consumers should eliminate the possibility of short 
term dependencies.

Longer term dependencies would be slowly changing things like 
temperature and supply voltage. But these are possibly available via 
other channels?

I don't recall how fast those capacitor voltages were changing.

> So what you get is what you get. Love it or leave it. [...]  So we
> have a situation where we can rely on the chip to do what is
> advertised, but we can't rely on the manufacturer to give us exactly
> the chip that they advertised.

The same is true of the instructions handling our private key material 
though, right? They could all be backdoored to leak info through some 
secret side channel. What's special about the RdRand instruction?

Is it that random number generation is considered 'in scope' for 
cryptography whereas ALU backdoors are not?

Is it that it seems more practical to engineer a weak key attack from 
weak entropy source?

That weak key generation produces exposure that persists across space 
and time via the ciphertext?

- Marsh

More information about the cryptography mailing list