[cryptography] Intel RNG

ianG iang at iang.org
Sat Jun 23 08:48:15 EDT 2012

On 23/06/12 03:06 AM, Marsh Ray wrote:
> 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
> security-through-obscurity.

I don't see it as much different although we could discuss the precise 

The thing is, security-thru-obscurity is neither an absolute nor always 
good.  It's a principle; it happens to be a good thing when there is too 
much secrecy.  But it also happens to be a valuable part of security 
models in contexts where secrecy can work for the defender.

And, now it is possible to see a case where even if we didn't need the 
secrecy for administrative reasons, random number generation may want to 
keep the seed input to the DRBG secret.

In that sense, maybe it is secrecy like private keys are secrets?

>>> 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.

Such people also have an ability to mix in multiple sources, and are 
well used to such.  So yes, raw entropy is good, but we are so used to 
skepticism about the pureness of our source that we've given up the 
demand for it.

>> 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?

Yes.  So if they are backdoored, why bother to prove the quality?  In 
situations like this, the reputation of the manufacturer provides a 
reasonable guarantee.

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

Hmmm good question.  I think cryptography, at least the civil form we 
know of, got a bit burnt in the 1990s by following an 'in scope' threat 
model.  RNGs are in scope, and some models I have seen indicate ALUs are 
in scope too (or fudged chips or dodgy network cards, etc).  Side 
channel attacks are now in scope, perhaps due to CRI's original work. 
Perhaps we're just waiting for an ALU attack to come out, a la recent 

> 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?

The history of cryptographic attacks by NSA seems to indicate a love of 
weak RNGs.  If I was them, I'd lay down a lotta moola for a predictable 
chip RNG, and a compliant population.

That's just my thoughts.


More information about the cryptography mailing list