linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Theodore Tso <tytso@mit.edu>, Matt Mackall <mpm@selenic.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] random: use xor for mixing
Date: Wed, 19 Dec 2007 16:09:29 -0500	[thread overview]
Message-ID: <47698889.2080107@tmr.com> (raw)
In-Reply-To: <20071209020828.GX17037@thunk.org>

Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 06:40:17PM -0600, Matt Mackall wrote:
>> I'm working on strengthening forward security for cases where the
>> internals are exposed to an attacker. There are any number of
>> situations where this can and does happen, and ensuring we don't
>> expose ourselves to backtracking is a worthwhile theoretical concern.
> 
> See my other comments; I don't think we are currently vulnerable to
> backtracking.
> 
> I tend to view backtracking as largely a theoretical concern, as most
> of the time, if the attacker has read access to kernel memory in order
> to compromise the internal state of /dev/random, the attacker very
> likely has *write* access to kernel memory, at which point you have
> much bigger problems to worry about, at least going forward.  
> 
> I suppose if you had *just* generated an 80-bit AES session key, right
> before the internal state was compromised, this might be interesting,
> but if the attacker can compromise arbitrary kernel memory, then
> attacker might as well just grab keying information from the userspace
> process --- such as perhaps the long-term private key of the user, or
> the data to be encrypted.
> 
> So my personal take on it is that protecting against backtracking
> attacks is mainly useful in silencing academics who like to come up
> with, well, largely academic and theoretical scenario.  If it doesn't
> take much effort, sure, let's try to protect against it (and I think
> we're OK already).
> 
> But a much better use of our time would be spent creating userspace
> support so we can more efficiently pull entropy from TPM modules, or
> the noise from a sound/microphone input, etc., or other hardware
> sources of entropy.  That would provide a much more practical
> improvement to the /dev/random subsystem than worry about what I feel
> are largely academic concerns.

That doesn't actually sound too hard, and the sounds of passing traffic 
are not likely to be replicable in any case. Lots of sensor data might 
be used as well, fan rpm, etc. That sounds so obvious I can't believe 
there isn't a reason it's not being done.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

  parent reply	other threads:[~2007-12-19 20:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2.753618428@selenic.com>
     [not found] ` <3.753618428@selenic.com>
2007-12-09  0:01   ` [PATCH 2/6] random: use xor for mixing Theodore Tso
2007-12-09  0:40     ` Matt Mackall
2007-12-09  2:08       ` Theodore Tso
2007-12-09 13:33         ` Alan Cox
2007-12-19 21:09         ` Bill Davidsen [this message]
     [not found] ` <4.753618428@selenic.com>
2007-12-09  0:35   ` [PATCH 3/6] random: do extraction before mixing Theodore Tso
2007-12-09  7:12     ` Matt Mackall
     [not found] ` <5.753618428@selenic.com>
2007-12-09  1:45   ` [PATCH 4/6] random: make backtracking attacks harder Theodore Tso
2007-12-09  5:43     ` Matt Mackall
2007-12-09 13:33       ` Theodore Tso
2007-12-09 17:05         ` Matt Mackall
2007-12-10 13:37           ` Theodore Tso
     [not found] ` <6.753618428@selenic.com>
2007-12-09  1:48   ` [PATCH 5/6] random: step more rapidly through the pool when adding and extracting Theodore Tso
2007-12-09  4:00     ` Andrew Morton
2007-12-09  4:22       ` Matt Mackall
2007-12-09 12:55         ` Theodore Tso
2007-12-09 17:08           ` Matt Mackall
     [not found] ` <7.753618428@selenic.com>
2007-12-09  1:51   ` [PATCH 6/6] random: improve variable naming, clear extract buffer Theodore Tso
2007-12-09  5:08     ` Matt Mackall

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=47698889.2080107@tmr.com \
    --to=davidsen@tmr.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --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;
as well as URLs for NNTP newsgroup(s).