From: "M Macnair" <mmacnair@gmail.com>
To: "Theodore Tso" <tytso@mit.edu>, "M Macnair" <mmacnair@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Seeding /dev/random not working
Date: Tue, 29 May 2007 14:38:45 +0100 [thread overview]
Message-ID: <de6d2b4f0705290638w3e862274jd49b18135790cea5@mail.gmail.com> (raw)
In-Reply-To: <20070529131501.GA9899@thunk.org>
On 5/29/07, Theodore Tso <tytso@mit.edu> wrote:
> On Tue, May 29, 2007 at 12:53:10PM +0100, M Macnair wrote:
> Ok, so this is telling me a couple of things. First of all, if you're
> only getting three outputs, it means that you don't have any
> peripherals feeding entropy into the system from the boot sequence.
> Without any hard drives, keyboards or mice, and a NIC whose device
> driver hasn't been configured to feed entropy, you're definitely
> hosed.
Yes. However this isn't the issue I'm concerned with at the moment.
> Secondly, and more importantly, your boot scripts aren't set up
> correctly.
Sorry, I only posted the startup bit - the same does indeed happen on
shutdown, however I wasn't interested in it for the purposes of the
tests.
The key point I was trying to put across was that I can't get the
seeding process to work. No matter what I wrote to /dev/urandom on
startup, the output from reading /dev/urandom immediately afterwards
was the same (ignoring the occasional variation that I put down to
timing). As I understand it (from man 4 random and the boot script
examples), writing to /dev/[u]random should increase the amount of
entropy, thereby altering the output from the PRNG.
> Another thing which I noticed is that when Matt Mackall took over
> maintainership of /dev/random, he apparently took out one of the
> safeguards I had, which was that before, when entropy was extracted
> from the pool the time stamp when it was extracted was mixed back into
> the pool. The theory was that an external attacker might not know
> when a program might be calling /dev/random, so mixing in the time of
> that entropy was extracted wouldn't hurt, and might help. I'll submit
> a patch to add that support back in, which will help you a little.
When did Matt take over? From my experiments it would appear as
though the time is having an effect on the output, though as I say I'm
not totally sure.
Regards,
Michael Macnair
next prev parent reply other threads:[~2007-05-29 13:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 11:53 M Macnair
2007-05-29 13:15 ` Theodore Tso
2007-05-29 13:38 ` M Macnair [this message]
2007-05-29 14:14 ` Pavel Machek
2007-05-29 15:17 ` M Macnair
2007-05-29 15:31 ` Jesper Juhl
2007-05-29 16:30 ` Theodore Tso
2007-05-29 20:06 ` Folkert van Heusden
2007-05-29 17:46 ` Matt Mackall
2007-05-29 18:00 ` Matt Mackall
2007-05-29 19:23 ` Eric Dumazet
2007-05-29 19:35 ` Matt Mackall
2007-05-29 16:58 ` Andi Kleen
2007-05-29 16:44 ` M Macnair
2007-05-29 20:23 ` Matt Mackall
2007-05-29 22:08 ` Andi Kleen
2007-05-29 21:44 ` Matt Mackall
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=de6d2b4f0705290638w3e862274jd49b18135790cea5@mail.gmail.com \
--to=mmacnair@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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®