From: "David Schwartz" <davids@webmaster.com>
To: "Karel Kulhavy" <clock@atrey.karlin.mff.cuni.cz>,
<linux-kernel@vger.kernel.org>
Subject: RE: /dev/random: really secure?
Date: Sun, 17 Dec 2000 16:18:31 -0800 [thread overview]
Message-ID: <NCBBLIEPOCNJOAEKBEAKKEFEMIAA.davids@webmaster.com> (raw)
In-Reply-To: <20001217225057.A8897@atrey.karlin.mff.cuni.cz>
> I noticed peculiarities in the behaviour of the delta-delta-3 system for
> entropy estimation in the random.c code./ When I hold right alt
> or control, I
> get about 8 bits of entropy per repeat fro the /dev/random which is
> overestimated. I think the real entropy is 0 bits because it is absolutely
> deterministic when the interrupt comes. Am I right or is there any hidden
> magic source of entropy in this case?
There are hidden sources of entropy. One is clock skew between the keyboard
processor's clock, the keyboard controller's clock, and the CPU clock
generator's PLL. Another is data motion between the CPU cache and main
memory as various interupt service routines are executed interspersed with
other system activity.
> Right shift, left alt, ctrl and shift make 4 bits per repeat. Is greater
> randomness being expected from the keys that return 8 bits?
The code does its best to estimate how much actual entropy it is gathering.
> When I have a server where n blobk read, keyboard and mouse events occur
> (everything is cached within huge amount of semiconductor RAM),
> the /dev/random
> depends solely on the network packets. These can be manipulated and their
> leading edge precisely sniffed. I think here exists a severe risk of
> compromise. Am I right?
Nope. There is no way to sniff their leading edge accurate to a billionth
of a second. If you have a 1Ghz Pentium 3, that's the accuracy you'd need.
And you'd need to know that relative to the CPU clock, which comes from an
uncompensated quartz crystal oscillator fed into a noisy multiplier. Top
that off with variations in the oscillator frequency due to microscopic zone
temperature variations.
There is no known method to predict these numbers.
DS
-
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 0:49 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 [this message]
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
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=NCBBLIEPOCNJOAEKBEAKKEFEMIAA.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=clock@atrey.karlin.mff.cuni.cz \
--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®