linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Kent Borg <kentborg@borg.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Venkatesh Pallipadi <venki@google.com>,
	Jarod Wilson <jarod@redhat.com>,
	linux-crypto@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	John Stultz <johnstul@us.ibm.com>,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	"David S. Miller" <davem@davemloft.net>,
	Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: [PATCH 4/5] tsc: wire up entropy generation function
Date: Tue, 14 Jun 2011 16:04:18 -0500	[thread overview]
Message-ID: <1308085458.15617.175.camel@calx> (raw)
In-Reply-To: <4DF7BEB5.1070006@borg.org>

On Tue, 2011-06-14 at 16:04 -0400, Kent Borg wrote:
> Matt Mackall wrote:
>  > [network adapters are] a great source of potential entropy, a bad
>  > source of guaranteed entropy. The current RNG tries to do
>  > accounting on the latter. Accounting on the former is extremely
>  > suspect.
> 
> So we need a patch that:
> 
>  - Deletes the IRQF_SAMPLE_RANDOM mention in feature-removal-schedule.txt,
> 
>  - Restores instances of IRQF_SAMPLE_RANDOM in drivers, and
> 
>  - Changes the credit_entropy_bits() to credit less entropy*.
> 
>    * The code seems to only handle integer values of entropy.  Maybe 
> when crediting, choose between 1 and 0 credits. 

No, that's not what I'm saying here. I'm saying we need to rethink
entropy accounting entirely.

An alternate plan is:

- add an add_network_randomness hook in the network stack that feeds
samples with 0 entropy credits (strengthen /dev/urandom)

- add similar sources elsewhere in the kernel

- remove the entropy accounting framework so that /dev/random is the
same as /dev/urandom


I currently don't think either of these is quite right for lots of
interesting systems and the answer is somewhere in the middle. 


Let me describle one extremely common pathological case: Wifi routers.
Many of these have effectively no storage and don't preserve pool data
across boots or a battery-backed RTC so they come up in a 'known' pool
state. Many of them also don't have a high-resolution time source or
cycle counter available. So guessing the timestamp on a network packet
is just about trivial. State extension attacks here are probably quite
easy (though I don't know that anyone's tried it).

So I think what we want to instead do is simply count samples until
we've got enough unleaked internal state that state extension becomes
hopeless. If we assume an attacker can guess each sample with 99%
accuracy (.08 bits per sample), pool state extension becomes intractable
(> 2^64 guesses) at a batch size on the order of 1000 samples. If we
have inputs from a variety of sources (network, keyboard, mouse, etc),
this number is probably quite a bit smaller.

This is a lot like the existing catastrophic reseed logic, except that
the effective multiplier is much larger and probably implies another
pool in the chain.

-- 
Mathematics is the supreme nostalgia of our time.

  reply	other threads:[~2011-06-14 21:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13 22:06 [PATCH 0/5] Feed entropy pool via high-resolution clocksources Jarod Wilson
2011-06-13 22:06 ` [PATCH 1/5] random: add new clocksource entropy interface Jarod Wilson
2011-06-13 22:06 ` [PATCH 2/5] clocksource: add support for entropy-generation function Jarod Wilson
2011-06-17 20:52   ` Thomas Gleixner
2011-06-17 21:19     ` Jarod Wilson
2011-06-13 22:06 ` [PATCH 3/5] hpet: wire up entropy generation function Jarod Wilson
2011-06-13 22:06 ` [PATCH 4/5] tsc: " Jarod Wilson
2011-06-13 22:27   ` Venkatesh Pallipadi
2011-06-13 22:35     ` Jarod Wilson
2011-06-13 22:36     ` H. Peter Anvin
2011-06-13 23:10       ` Matt Mackall
2011-06-14 18:11         ` H. Peter Anvin
2011-06-14  0:39       ` Kent Borg
2011-06-14  1:47         ` H. Peter Anvin
2011-06-14 12:39           ` Kent Borg
2011-06-14 14:33             ` Matt Mackall
2011-06-14 17:48               ` Kent Borg
2011-06-14 18:00                 ` Matt Mackall
2011-06-14 20:04                   ` Kent Borg
2011-06-14 21:04                     ` Matt Mackall [this message]
2011-06-14 14:02           ` Jarod Wilson
2011-06-13 23:55     ` Kent Borg
2011-06-17 20:58     ` Thomas Gleixner
2011-06-13 22:06 ` [PATCH 5/5] misc: add clocksource-based entropy generation driver Jarod Wilson
2011-06-17 21:01   ` Thomas Gleixner
2011-06-13 22:38 ` [PATCH 0/5] Feed entropy pool via high-resolution clocksources john stultz
2011-06-14 14:25   ` Jarod Wilson
2011-06-13 23:15 ` Matt Mackall
2011-06-14 15:18   ` Jarod Wilson
2011-06-14 15:22     ` Jarod Wilson
2011-06-14 17:13     ` Matt Mackall
2011-06-14 20:17       ` Jarod Wilson
2011-06-14 21:45         ` Matt Mackall
2011-06-14 22:51           ` Jarod Wilson
2011-06-14 23:12             ` Matt Mackall
2011-06-15 14:49               ` Jarod Wilson
2011-06-15 20:06                 ` Matt Mackall
2011-06-17 18:51                   ` Jarod Wilson
2011-06-17 19:29                     ` Neil Horman
2011-06-17 20:46                       ` Matt Mackall
2011-06-17 19:48               ` hpas
2011-06-17 20:28                 ` Matt Mackall
2011-06-18 22:40                   ` H. Peter Anvin
2011-06-19 13:38                     ` Neil Horman
2011-06-19 15:07                       ` Herbert Xu
2011-06-20  0:01                         ` H. Peter Anvin

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=1308085458.15617.175.camel@calx \
    --to=mpm@selenic.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.hengli.com.au \
    --cc=hpa@zytor.com \
    --cc=jarod@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=kentborg@borg.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venki@google.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;
as well as URLs for NNTP newsgroup(s).