public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [PATCH][RFC] CPU Jitter random number generator (resent)
Date: Tue, 21 May 2013 15:01:57 -0400	[thread overview]
Message-ID: <20130521190157.GD22559@thunk.org> (raw)
In-Reply-To: <CACXcFm=PCPs23Kd8B0+B7418fSaz=59Z4DRcj3-Wcd-i=Meang@mail.gmail.com>

I continue to be suspicious about claims that userspace timing
measurements are measuring anything other than OS behaviour.  But that
doesn't mean that they shouldn't exist.  Personally, I believe you
should try to collect as much entropy as you can, from as many places
as you can.  For VM's, it means we should definitely use
paravirtualization to get randomness from the host OS.  If you don't
trust the host OS, then what on earth are you doing trying to generate
a long-term public key pair on the VM in the first place?  For that
matter, why are you willing to expose a high value private keypair on
the VM?

For devices like Linux routers, what we desperately need is hardware
assist; either a on-CPU hardware random number generator, or a
hardware RNG from a TPM module, or having an individualized secret key
generated at manufacturing time and burned onto the device.  If you
don't trust that the Intel hardware RNG honest, then by all means mix
in additional timing information either at kernel device driver level,
or from systems such as HAVEGE.

What I'm against is relying only on solutions such as HAVEGE or
replacing /dev/random with something scheme that only relies on CPU
timing and ignores interrupt timing.

Regards,

					- Ted

  parent reply	other threads:[~2013-05-21 19:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21  6:44 [PATCH][RFC] CPU Jitter random number generator (resent) Stephan Mueller
2013-05-21 16:43 ` Sandy Harris
     [not found] ` <CACXcFmmPjGBYhfbwfMdE2iTv2a9Q6HB1aT8JSnXA-8n2yO0zcA@mail.gmail.com>
2013-05-21 16:56   ` Stephan Mueller
     [not found] ` <CACXcFm=PCPs23Kd8B0+B7418fSaz=59Z4DRcj3-Wcd-i=Meang@mail.gmail.com>
2013-05-21 19:01   ` Theodore Ts'o [this message]
2013-05-21 21:39     ` Sandy Harris
2013-05-22  6:20       ` Stephan Mueller
2013-05-22 17:40         ` Sandy Harris
2013-05-22 18:34           ` Stephan Mueller
2013-05-23  9:59             ` Stephan Mueller
2013-08-05  3:05       ` Stephan Mueller

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=20130521190157.GD22559@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandyinchina@gmail.com \
    /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