Messages in this thread |  | | From | (David Wagner) | Subject | Re: [PATCH] (0/4) Entropy accounting fixes | Date | 9 Sep 2002 23:22:27 GMT |
| |
Oliver Xymoron wrote: >On Mon, Sep 09, 2002 at 04:58:50PM +0000, David Wagner wrote: >> Whether you like it or not, you're already trusting Intel, if you're >> using an Intel chip. If Intel were malicious and out to get you, they >> could have put a backdoor in the chip. And a RNG is *much* easier to >> reverse-engineer and audit than an entire CPU, so it would probably be >> riskier for Intel to hide a backdoor in the RNG than in, say, the CPU. > >Not sure I buy that. Consider that with a CPU, you control the inputs, >you've got a complete spec of the core functionality, you've got a >huge testbed of code to test that functionality, and you've got a >whole industry of people reverse engineering your work.
There's no guarantee that the CPU behaves deterministically. Maybe on April 1, 2005 (or after executing a magic sequence of 1000 instructions) it starts ignoring all privilege and permission bits. Good luck finding that through mere testing.
>More to the point, the backdoor we're worried about is one that >compromises our encryption keys to passive observers. Doing that by >making the RNG guessable is relatively easy. On the other hand >determining whether a given snippet of code is doing RSA, etc. is >equivalent to solving the halting problem, so it's seems to me pretty >damn hard to usefully put this sort of back door into a CPU without >sacrificing general-purpose functionality.
Ok, I agree: The RNG is the most natural, and one of the more devastating places, to put a backdoor. (There are other ways of putting a backdoor in a CPU other than scanning to identify RSA code, though.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |