From: Gordon Oliver <gordo@pincoya.com>
To: David Wagner <daw@mozart.cs.berkeley.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] Allow net devices to contribute to /dev/random
Date: Wed, 26 Sep 2001 15:55:22 -0700 [thread overview]
Message-ID: <20010926155522.C4828@furble> (raw)
In-Reply-To: <1001461026.9352.156.camel@phantasy> <9or70g$i59$1@abraham.cs.berkeley.edu> <1001465531.10701.61.camel@phantasy> <9orbfo$jca$1@abraham.cs.berkeley.edu>
In-Reply-To: <9orbfo$jca$1@abraham.cs.berkeley.edu>; from daw@mozart.cs.berkeley.edu on Tue, Sep 25, 2001 at 18:36:56 -0700
Hi,
I would actually suggest breaking out a longer discussion of the
risks associated with the patch into Documentation, and _strongly_
suggesting that the person configuring the kernel read it before
enabling the option. Then a statement that this may put the security
of /dev/random at risk would probably be enough.
So let's start with the possible conditions are.
What I can see are the following:
1) network card on visible net:
- BadGuy can monitor the network traffic, extracting
timing information. Given enough knowledge about the
latency of the network card, all network entropy might
be known (making it non-secure). If the network is
the only, or primary, source of entropy this leads
to compromise
2) network card on private net:
- BadGuy must plug into private net to monitor the traffic,
any external monitoring is very likely to fail to get
much useful information.
3) TSC not used to add randomness:
- Prediction of time between interrupts becomes much easier
(jiffies are a big target).
4) Systems that are largely quiescent could lead to easier prediction
of latencies, and thus easier compromise.
In any case the following must be true for this to cause problems:
a) The network must be the primary source of entropy (this
will be common in the case where the patch is useful)
b) BadGuy must monitor from time 0 (boot of system) to get
useful information
c) BadGuy must have information about what network card the system
has, or _very_ good statistical information about delay to
interrupt & timing in general.
d) BadGuy must have information about how long the processing for
the interrupt handler takes, as the randomness addition is done
_after_ all processing. This also causes interesting problems
for prediction if more than one event is handled at once.
e) BadGuy must have access to information of network traffic on
all the networks that are attached to the computer.
Now none of this guarantees security (but then again, very little will
_guarantee_ security.
I may have missed some stuff here... (caveat emptor)
Just as a comment, I actually like the patch, and would certainly be
willing to use it for a computer on a private network...
-gordo
next prev parent reply other threads:[~2001-09-26 22:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-25 23:36 [PATCH][RFC] Allow net devices to contribute to /dev/random Robert Love
2001-09-26 0:20 ` David Wagner
2001-09-26 0:52 ` Robert Love
2001-09-26 1:36 ` David Wagner
2001-09-26 22:55 ` Gordon Oliver [this message]
2001-09-26 23:06 ` Andreas Steinmetz
2001-09-26 15:49 ` dean gaudet
2001-09-26 17:00 ` Oliver Xymoron
2001-10-01 14:43 ` Pavel Machek
2001-10-01 21:33 ` Robert Love
2001-10-01 9:52 ` Florian Weimer
2001-10-01 16:59 ` /dev/random entropy calculations broken? Andreas Dilger
2001-10-01 21:55 ` Alex Bligh - linux-kernel
2001-10-01 22:43 ` antirez
2001-10-02 7:51 ` Andreas Dilger
2001-10-02 8:10 ` Andreas Dilger
2001-10-02 15:37 ` Oliver Xymoron
2001-10-02 21:02 ` Andreas Dilger
2001-10-02 21:29 ` Oliver Xymoron
2001-10-02 22:28 ` Andreas Dilger
2001-10-19 22:59 ` [PATCH] " Andreas Dilger
2001-10-21 5:05 ` Robert Love
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=20010926155522.C4828@furble \
--to=gordo@pincoya.com \
--cc=daw@mozart.cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
/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