[cryptography] Intel RNG
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
Longer term dependencies would be slowly changing things like
temperature and supply voltage. But these are possibly available via
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?
More information about the cryptography