mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, mpm@selenic.com, tytso@mit.edu
Subject: Re: [PATCH 1/2] random: Add support for architectural random hooks
Date: 30 Jul 2011 20:58:13 -0400	[thread overview]
Message-ID: <20110731005813.11215.qmail@science.horizon.com> (raw)
In-Reply-To: <CA+55aFwdA_6W1GZZG76wVvmDQnEMj3hYBt6Md7GcFE02OkqiVA@mail.gmail.com>

> Guys, if your argument is that you cannot possibly distinguish the
> Intel implementation from "true" randomness, then WHAT THE HELL are
> you complaining about?
>
> We don't even care. "True randomness" and "something we cannot
> possibly even test and distinguish from true randomess" are 100%
> equivalent. Stop with the idiotic "we cannot test it" crap. If it
> really is indistinguishable from true randomness, nobody will ever
> care.

Did you READ what I wrote beyond the first paragraph?

Because the LAST paragraph included a description of a
testable and verifiable hardware RNG.  To repeat:

>> A much more verifiable way would be to provide access to the raw hardware
>> generator, and enough hardware documentation to predict how its output
>> varies with environmental conditions (temperature, supply voltage, clock
>> speed, x-rays, ...) and lot-to-lot.  It would be extremely difficult
>> to produce a deterministic (i.e. back-door-able) generator with the
>> same sensitivities.

(Apologies for the bad grammar of "much more verifiable".)


The problem is not that's it's theoretically impossible to distinguish
them, but that it's PRACTICALLY impossible to distinguish true randomness
from a good counterfeiting effort.  As long as you're limited to
black-box testing.

That's counterfeiting, not incompetence.  The Intel RNG, if implemented
as described in their documentation, is quite well engineered.
(The basic architecture is essentially the same as /dev/urandom.)


I was just saying that it would be very easy to add a deliberate back
door, and the interface they provide fails to include any way to detect
such a thing.

> Seriously. This whole discussion just makes me convinced that security
> people are so far removed from reality that it's not even relevant any
> more.

The real world matters enormously.  Because that's where security
exploits happen, not in some mathematical abstraction that can be
proved secure.

I can build an RNG that nobody else can distinguish from truly random
until I start forging your signature on kernel releases.

Isn't that a bit LATE to be noticing the problem?

  reply	other threads:[~2011-07-31  0:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-30 23:46 George Spelvin
2011-07-31  0:29 ` Linus Torvalds
2011-07-31  0:58   ` George Spelvin [this message]
2011-07-31  1:02 ` Bryan Donlan
2011-07-31  1:35   ` Linus Torvalds
2011-07-31  2:02     ` Bryan Donlan
2011-07-31  2:42       ` Henrique de Moraes Holschuh
2011-07-31  3:17         ` Bryan Donlan
2011-07-31  4:33       ` Linus Torvalds
  -- strict thread matches above, loose matches on Subject: below --
2011-07-29 20:37 [RFD] Direct support for the x86 RDRAND instruction H. Peter Anvin
2011-07-29 20:37 ` [PATCH 1/2] random: Add support for architectural random hooks H. Peter Anvin
2011-07-29 21:16   ` Matt Mackall
2011-07-30  6:20     ` Linus Torvalds
2011-07-30 16:34       ` Arjan van de Ven
2011-07-30 17:45       ` Matt Mackall
2011-07-30 18:20         ` Linus Torvalds
2011-07-30 19:13           ` Matt Mackall
2011-07-30 19:29             ` Linus Torvalds
2011-07-30 22:25               ` Ted Ts'o
2011-07-31  1:13   ` Linus Torvalds
2011-07-31  1:32     ` H. Peter Anvin
2011-07-31  1:43       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110731005813.11215.qmail@science.horizon.com \
    --to=linux@horizon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome