From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Kurt Garloff <garloff@suse.de>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>,
Linux kernel list <linux-kernel@vger.kernel.org>
Subject: Re: /dev/random: really secure?
Date: Tue, 19 Dec 2000 11:51:24 -0500 [thread overview]
Message-ID: <200012191651.LAA02207@tsx-prime.MIT.EDU> (raw)
In-Reply-To: Kurt Garloff's message of Tue, 19 Dec 2000 12:49:48 +0100, <20001219124948.P17777@garloff.suse.de>
Date: Tue, 19 Dec 2000 12:49:48 +0100
From: Kurt Garloff <garloff@suse.de>
On Mon, Dec 18, 2000 at 04:33:13PM -0500, Theodore Y. Ts'o wrote:
> Note that writing to /dev/random does *not* update the entropy estimate,
> for this very reason. The assumption is that inputs to the entropy
> estimator have to be trusted, and since /dev/random is typically
> world-writeable, it is not so trusted.
It should not be world-writeable, IMHO. So the only one who can feed entropy
there is root, who should know aht (s)he's doing ...
Here (SuSE Linux 7.x), it is 644:
crw-r--r-- 1 root root 1, 8 Dec 17 22:41 /dev/random
crw-r--r-- 1 root root 1, 9 Dec 17 22:41 /dev/urandom
No, writing to /dev/random does not feed update entropy estimate. It
does mix data into the pool, but the mixing algorithm is designed so
that you can do no harm by mixing any data into the pool --- even nasty
data chosen by an attacker. Hence, allowing someone to write into
/dev/random is perfectly safe; it can cause no damage, and might improve
things. That's why /dev/random should be world-writeable.
There is a separate ioctl which requires root privs to atomically mix
data into the pool and update the entropy estimate. That's the
interface which is supposed to be used by trusted daemons which pull
data from various hardware devices, and feed them into /dev/random.
Note that in this case, the trusted daemon is supposed to estimate the
amount of entropy which it is feeding into the system. That's because
the daemon may be able to use much more sophisticated entropy estimation
systems, including ones which may require large amounts of CPU time (for
example, to do FFT's, trial compression of the data, etc.).
- Ted
-
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-19 17:22 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
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 [this message]
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=200012191651.LAA02207@tsx-prime.MIT.EDU \
--to=tytso@mit.edu \
--cc=garloff@suse.de \
--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
all inboxes | Powered by JetHome®