[146939] in cryptography@c2.net mail archive
Re: [Cryptography] Random number generation influenced, HW RNG
daemon@ATHENA.MIT.EDU (John Kelsey)
Mon Sep 9 23:47:49 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130909183208.329df6ae@jabberwock.cb.piermont.com>
From: John Kelsey <crypto.jmk@gmail.com>
Date: Mon, 9 Sep 2013 23:29:52 -0400
To: "Perry E. Metzger" <perry@piermont.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
David Johnston <dj@deadhat.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Sep 9, 2013, at 6:32 PM, "Perry E. Metzger" <perry@piermont.com> wrote:
> First, David, thank you for participating in this discussion.
>
> To orient people, we're talking about whether Intel's on-chip
> hardware RNGs should allow programmers access to the raw HRNG output,
> both for validation purposes to make sure the whole system is working
> correctly, and if they would prefer to do their own whitening and
> stretching of the output.
Giving raw access to the noise source outputs lets you test the source from the outside, and there is alot to be said for it. But I am not sure how much it helps against tampered chips. If I can tamper with the noise source in hardware to make it predictable, it seems like I should also be able to make it simulate the expected behavior. I expect this is more complicated than, say, breaking the noise source and the internal testing mechanisms so that the RNG outputs a predictable output stream, but I am not sure it is all that much more complicated. How expensive is a lightweight stream cipher keyed off the time and the CPU serial number or some such thing to generate pseudorandom bits? How much more to go from that to a simulation of the expectdd behavior, perhaps based on the same circutry used in the unhacked version to test the noise source outputs?
--John
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
