linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Matt Mackall <mpm@selenic.com>
Cc: Kyle Moffett <mrmacman_g4@mac.com>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers
Date: Fri, 5 May 2006 15:11:27 -0400	[thread overview]
Message-ID: <20060505191127.GA16076@thunk.org> (raw)
In-Reply-To: <20060505172424.GV15445@waste.org>

On Fri, May 05, 2006 at 12:24:26PM -0500, Matt Mackall wrote:
> I haven't seen such an analysis, scholarly or otherwise and my bias
> here is to lean towards the paranoid.
> 
> Assuming a machine with no TSC and an otherwise quiescent ethernet
> (hackers burning the midnight oil), I think most of the
> hard-to-analyze bits above get pretty transparent.

As always, whether or not the packet arrival times could be guessable
and/or controlled by an attacker really depends on your threat model.
For someone who has an ethernet monitor attached directly to the
segment right next to your computer, it's very likely that they would
be successful in guessing the inputs into the entropy pool.  However,
an attacker with physical access to your machine could probably do all
sorts of other things, such as install a keyboard sniffer, etc.  

For a remote attacker, life gets much more difficult.  Each switch,
router, and bridge effectively has a queue into which packets must
flow through, and that is _not_ known to a remote attacker.  This is
especially true today, when most people don't even use repeaters, but
rather switches/bridges, which effectly make each ethernet connection
to each host its own separate collision domain (indeed that term
doesn't even apply for modern high-speed ethernets).

I've always thought the right answer is that whether or not network
packet arrival times should be used as entropy input should be
configurable, since depending on the environment, it might or might
not be safe, and for some hosts (particularly diskless servers), the
network might be the only source of entropy available to them.

						- Ted


  reply	other threads:[~2006-05-05 19:12 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 16:42 [PATCH 1/14] random: Remove SA_SAMPLE_RANDOM from floppy driver Matt Mackall
2006-05-05 16:42 ` [PATCH 6/14] random: Remove redundant SA_SAMPLE_RANDOM from touchscreen drivers Matt Mackall
2006-05-05 16:42 ` [PATCH 4/14] random: Change cpqarray to use add_disk_randomness Matt Mackall
2006-05-05 16:42 ` [PATCH 2/14] random: Remove redundant SA_SAMPLE_RANDOM from NinjaSCSI Matt Mackall
2006-05-05 16:42 ` [PATCH 3/14] random: Make CCISS use add_disk_randomness Matt Mackall
2006-05-05 16:42 ` [PATCH 5/14] random: Remove bogus SA_SAMPLE_RANDOM from at91 compact flash driver Matt Mackall
2006-05-05 16:42 ` [PATCH 8/14] random: Remove SA_SAMPLE_RANDOM from USB gadget drivers Matt Mackall
2006-05-06 11:07   ` Denis Vlasenko
2006-05-06 18:16     ` David Brownell
2006-05-06 18:31       ` Matt Mackall
2006-05-05 16:42 ` [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers Matt Mackall
2006-05-05 17:13   ` Kyle Moffett
2006-05-05 17:24     ` Matt Mackall
2006-05-05 19:11       ` Theodore Tso [this message]
2006-05-05 20:30         ` Stephen Hemminger
2006-05-05 20:34         ` Matt Mackall
2006-05-06 11:55           ` Theodore Tso
2006-05-06 16:48             ` Matt Mackall
2006-05-06 17:29               ` Bernd Eckenfels
2006-05-06 18:05               ` Theodore Tso
2006-05-06 20:33                 ` Matt Mackall
2006-05-07  0:17                   ` David S. Miller
2006-05-07  1:22                   ` Theodore Tso
2006-05-07  5:07                     ` Matt Mackall
2006-05-08 21:58                     ` Sami Farin
2006-05-24 22:47                 ` Marcin Dalecki
2006-05-25  0:08                   ` Theodore Tso
2006-05-31 19:29                     ` Bill Davidsen
2006-05-07  0:08               ` David S. Miller
2006-05-07  4:59                 ` Matt Mackall
2006-05-07  5:46                   ` David S. Miller
2006-05-07 16:31                     ` Matt Mackall
2006-05-07 13:13                   ` Thiago Galesi
2006-05-07 16:00                     ` Matt Mackall
2006-05-07 17:00                       ` Thiago Galesi
2006-05-08  0:13                       ` Theodore Tso
2006-05-08  2:55                         ` Matt Mackall
2006-05-08  6:26                   ` Pavel Machek
2006-05-08  7:07                     ` David S. Miller
2006-05-08 14:05                       ` Matt Mackall
2006-05-08 17:21                         ` Pavel Machek
2006-05-08 17:27                           ` Matt Mackall
2006-05-09 11:23                             ` Pavel Machek
2006-05-11 10:05                           ` Ph. Marek
2006-05-24 22:35         ` Marcin Dalecki
2006-05-05 21:10   ` David S. Miller
2006-05-05 23:03     ` Matt Mackall
2006-05-05 23:19       ` David S. Miller
2006-05-06 14:08     ` Folkert van Heusden
2006-05-06 15:19       ` Lee Revell
2006-05-07 10:35         ` Folkert van Heusden
2006-05-07 16:33           ` Matt Mackall
2006-05-05 16:42 ` [PATCH 9/14] random: Remove SA_SAMPLE_RANDOM from i2c drivers Matt Mackall
2006-05-05 16:42 ` [PATCH 10/14] random: Remove bogus SA_SAMPLE_RANDOM from mpc52xx serial driver Matt Mackall
2006-05-05 16:42 ` [PATCH 11/14] random: Remove UML usage of SA_SAMPLE_RANDOM Matt Mackall
2006-05-05 16:42 ` [PATCH 13/14] random: Remove SA_SAMPLE_RANDOM from IRQ fastpath Matt Mackall
2006-05-05 16:42 ` [PATCH 12/14] random: Remove not very useful SA_SAMPLE_RANDOM from lubbock Matt Mackall
2006-05-05 16:42 ` [PATCH 14/14] random: Remove add_interrupt_randomness Matt Mackall
2006-05-08  7:38 [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers linux
2006-05-12  6:09 ` linux

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=20060505191127.GA16076@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=mrmacman_g4@mac.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).