From: Andreas Dilger <adilger@turbolinux.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Jamie Lokier <lk@tantalophile.demon.co.uk>,
David Schwartz <davids@webmaster.com>,
Karel Kulhavy <clock@atrey.karlin.mff.cuni.cz>,
linux-kernel@vger.kernel.org
Subject: Re: /dev/random: really secure?
Date: Mon, 18 Dec 2000 15:15:54 -0700 (MST) [thread overview]
Message-ID: <200012182215.eBIMFsb14852@webber.adilger.net> (raw)
In-Reply-To: <200012182133.QAA02136@tsx-prime.MIT.EDU> "from Theodore Y. Ts'o at Dec 18, 2000 04:33:13 pm"
Jamie Lokier <lk@tantalophile.demon.co.uk> writes:
> > A potential weakness. The entropy estimator can be manipulated by
> > feeding data which looks random to the estimator, but which is in fact
> > not random at all.
Ted Ts'o replied:
> Yes, absolutely. That's why you have to be careful before you make
> changes to the kernel code to feed additional data to the estimator.
> *Usually* relying on interrupt timing is safe, but not always. For
> example, an adversary can observe, and in some cases control the
> arrivial of network packets which control the network card's interrupt
> timings. Is it enough to be able to predict with cpu-counter
> resolution the inputs to the /dev/random pool? Maybe; it depends on how
> paranoid you are.
I think that for the case of dedicated firewall/IPSec machines, it
_should_ be possible to generate some entropy from network packets,
because this may be the only place where they get any activity (no
keyboard/mouse/disk). Given the fact we are dealing with a router,
there shouldn't be any way one person can control all of the network
traffic to/through/from the router, and if they can you probably have
another security problem entirely.
Maybe a hook into the ipchains/netfilter code to allow selecting only
traffic from certain interfaces, and discarding "repeat" source and/or
destination addresses or packets arriving less than X ticks apart, just
like we discard repeated keystrokes. The larger X is, the harder it is
to estimate the low-order bits on the timers when a packet arrives.
This would allow you to say "eth0 is my internal network and I'm not
trying to hack my own system, so use IP traffic on that interface to add
entropy to the pool, but not packets that are on port 6699/21/23 or reply
packets". It would probably just be a matter of adding a new flag to a
filter rule to say "use packets that match this rule for entropy", and
then it is up to the user to determine what is safe to use. The fact
that it is user configurable makes it even harder for a cracker to know
what affects the entropy pool.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-18 22:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-17 21:50 Karel Kulhavy
2000-12-18 0:18 ` David Schwartz
2000-12-18 8:21 ` Karel Kulhavy
2000-12-18 20:38 ` Jamie Lokier
2000-12-18 21:33 ` Theodore Y. Ts'o
2000-12-18 22:15 ` Andreas Dilger [this message]
2000-12-19 9:27 ` Daniel Stone
2000-12-19 11:49 ` Kurt Garloff
2000-12-19 12:48 ` Peter Samuelson
2000-12-19 16:51 ` Theodore Y. Ts'o
2000-12-19 17:39 ` Pavel Machek
2000-12-18 21:58 ` David Schwartz
2000-12-18 8:49 ` David Feuer
2000-12-18 9:22 ` Martin Mares
2000-12-19 6:49 ` Philipp Rumpf
2000-12-20 3:41 Bernd Eckenfels
2000-12-20 17:58 ` Jamie Lokier
2000-12-20 3:49 Bernd Eckenfels
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=200012182215.eBIMFsb14852@webber.adilger.net \
--to=adilger@turbolinux.com \
--cc=clock@atrey.karlin.mff.cuni.cz \
--cc=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lk@tantalophile.demon.co.uk \
--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
all inboxes | Powered by JetHome®