Terry Lambert wrote:
This is sweet! Seems it would give us the full benefits of Mark's
randomdev, and fit nicely with our normal configuration framework and
gives good flexibility.
It also describes just what we have currently, except it misses the
advantages of putting
In real life, machines don't always get rebooted in a completely
controlled fashion (panic, power failure, etc.). Anything that
makes a reboot longer or less reliable is a definite non-starter.
I can guarantee you, if the current /dev/random code isn't fixed before
it makes STABLE, folks
On Wed, Oct 25, 2000 at 09:28:31PM -0700, Doug Barton wrote:
How exactly are you rebooting? If you're using the 'reboot' command,
That is my standard rebooting method. ``reboot'' really has to be
tolerated and something useful happen (ie, the next booting up doesn't
hang (or delay for
On Wed, Oct 25, 2000 at 05:01:44PM -0700, Mark Murray wrote:
I need logs.
What logs you expect? It is just standard -current rc.* files.
What is "did not work"?
The same fortune quote again.
What is "it worked"?
Different fortune quote.
What was the line you commented out?
His
On Wed, Oct 25, 2000 at 10:35:55AM +, Terry Lambert wrote:
I see the opposite. I see that without writing to the /dev/random
device I get a cons is an object that cares fortune 99+% of the time
on my first login. With it, I see more decently random fortunes (but
I haven't done a
On Wed, Oct 25, 2000 at 02:50:29PM +0400, Andrej Cernov wrote:
It is because /dev/random totally ignore _time_ and not reseed from it,
but no other randomness source available at boot time.
We should probably be using the time since boot as ONE thing we seed
with, but it only provides maybe
On Thu, Oct 26, 2000 at 12:48:19PM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
On Wed, Oct 25, 2000 at 05:01:44PM -0700, Mark Murray wrote:
I need logs.
What logs you expect? It is just standard -current rc.* files.
Here they are, in anycase, set -x as you requested (entropy-related lines
only):
+ [ -w
On Thu, Oct 26, 2000 at 02:21:22AM -0700, Kris Kennaway wrote:
On Wed, Oct 25, 2000 at 02:50:29PM +0400, Andrej Cernov wrote:
It is because /dev/random totally ignore _time_ and not reseed from it,
but no other randomness source available at boot time.
We should probably be using the
Doug Barton wrote:
Wesley Morgan wrote:
I'm not knocking anyone or any code, especially considering this IS
-current... BUT... I don't need to read the code to know that I am seeing
the same fortunes on first login after reboot more often than I can
attribute to random chance. Maybe
On Wed, Oct 25, 2000 at 07:50:28PM -0400, Wesley Morgan wrote:
Now, the problem I am seeing is that not only do I get the same fortunes
between reboots, but it is _always_ the same one:
"Be ALERT (the world needs more lerts"
BTW, my always-the-same fortune is different:
"Adore, v.: To
The issue is one of seeding the device strongly. If all you care about
is getting a different fortune when you boot then seeding with
e.g. the system boot time would be enough, but obviously it doesnt
make /dev/random cryptographically secure.
I think there's a more general point being made
Jordan writes a nice piece of mail...
If this was happening in -stable I'd be in total agreement.
However, we're talking -current, and is not -current the
integration area for new technologies, whether they be
rough or round edged?
This reminds me of the old development arguement:
Don't do
:In real life, machines don't always get rebooted in a completely
:controlled fashion (panic, power failure, etc.). Anything that
:makes a reboot longer or less reliable is a definite non-starter.
:
:I can guarantee you, if the current /dev/random code isn't fixed before
:it makes STABLE, folks
What logs you expect? It is just standard -current rc.* files.
Here they are, in anycase, set -x as you requested (entropy-related lines
only):
+ [ -w /dev/random ]
+ [ -f /var/db/entropy -a -r /var/db/entropy -a -s /var/db/entropy ]
+ echo Using /var/db/entropy as an entropy file
+
What logs you expect? It is just standard -current rc.* files.
Here they are, in anycase, set -x as you requested (entropy-related lines
only):
+ [ -w /dev/random ]
+ [ -f /var/db/entropy -a -r /var/db/entropy -a -s /var/db/entropy ]
+ echo Using /var/db/entropy as an entropy file
+
On 26-Oct-00 Rod Taylor wrote:
Doug Barton wrote:
Wesley Morgan wrote:
I'm not knocking anyone or any code, especially considering this IS
-current... BUT... I don't need to read the code to know that I am seeing
the same fortunes on first login after reboot more often than I can
On Thu, Oct 26, 2000 at 09:56:00AM -0700, Matt Dillon wrote:
simple: don't try to save the random seed from the shutdown script. I
would argue that the very *LAST* thing you want to do when shutting a
machine down is start writing out files. And, frankly, depending on
I agree.
It is because /dev/random totally ignore _time_ and not reseed from it,
but no other randomness source available at boot time.
We should probably be using the time since boot as ONE thing we seed
with, but it only provides maybe 3-4 bits of randomness - meaning if
thats all you seed
The actual time would probably be more useful than the time since
boot.
Heck - I can use both. Its cheap enough.
I still have a problem with what I see as a fundamental weakness
in storing "randomness" across reboots.
Schneier recommends this in his Yarrow paper.
Logically, given a
On Thu, 26 Oct 2000, John Baldwin wrote:
How about when I hit the reset button? That case SHOULD be taken care
of too! Would it not be possible to sample /dev/random to store the
entropy every hour or so that the system runs? Atleast that way you
would be guarenteed to have something.
On Thu, Oct 26, 2000 at 09:25:05AM -0400, John W. De Boskey wrote:
If this was happening in -stable I'd be in total agreement.
However, we're talking -current, and is not -current the
integration area for new technologies, whether they be
rough or round edged?
Yes, -CURRENT is for new
I stated this same objection until I actually attended Mark's
presentation at the 'con. The yarrow algorithm uses an encrypted hash for
the entropy on the way in, and encrypts the output on the way out. This
would make it extremely difficult to guess the state at reboot, even if we
:I like that, but I'd like to see more than one file. This avoids the race
:where fsck may blat an incompletely written file after a (in)convenient
:crash.
:
:We are really headed towards saving state in the first swap partition
:(if there is one).
:M
:--
:Mark Murray
:Join the anti-SPAM
Doug Barton wrote:
: Pending Mark's approval, I'd like to suggest we add a cron job to
: dump X k of data from /dev/random to a file (/boot/.periodic_entropy
: maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at
: boot, and only do the "long, annoying" failover process if
This would be trivial, you can use the swap allocation code (example:
see the VN device, dev/vn/vn.c) to reserve, read, and write the swap.
Thanks! :-)
However, I don't see much of a point in doing this. Not everyone
configures swap, so you can't count on it, and a system
: This would be trivial, you can use the swap allocation code (example:
: see the VN device, dev/vn/vn.c) to reserve, read, and write the swap.
:
:Thanks! :-)
:
: However, I don't see much of a point in doing this. Not everyone
: configures swap, so you can't count on it, and a
On Thu, 26 Oct 2000, Ed Hall wrote:
How about skipping the "long, annoying failover process" altogether and
simply logging to the console that the entropy reseeding process was
incomplete? Forcing an indeterminate delay to gather entropy is more
than a little paternalistic.
The
In message [EMAIL PROTECTED], Doug
Barton writes:
On Thu, 26 Oct 2000, Ed Hall wrote:
How about skipping the "long, annoying failover process" altogether and
simply logging to the console that the entropy reseeding process was
incomplete? Forcing an indeterminate delay to gather entropy is
On Thu, 26 Oct 2000, Poul-Henning Kamp wrote:
I don't really care that much how good my random bits are right after
boot, but I do care about my machine coming up quickly.
I don't know about that, look at your boot logs:
Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1992-2000
On Thu, Oct 26, 2000 at 02:25:58PM -0700, Matt Dillon wrote:
/etc/rc already assumes that /var is writable. I recommend that you make
that assumption by default... have the default entropy file be something
like "/var/db/entropy_seed" and allow the administrator to override it
In message [EMAIL PROTECTED]
om, Wesley Morgan writes:
On Thu, 26 Oct 2000, Poul-Henning Kamp wrote:
I don't really care that much how good my random bits are right after
boot, but I do care about my machine coming up quickly.
I don't know about that, look at your boot logs:
Oct 26 17:32:19
hmmm... I just got a message from chris, he said he will be adding
AES/Rijndael to the kernel ASAP...
According to the Rijndael spec, it seems to also function as an
excellant pseudo-random number generator...
You can find this info at:
http://www.esat.kuleuven.ac.be/~rijmen/rijndael
Section
Hi
Very wonderful ideas! It will take me a bit of time to implement this
cleanly as I am not close enough to my Prime Development Platform, but
I will do something as soon as possible. Consider it to be not less
than two weeks, unless someone submits patches first.
:-)
M
:There is the
David O'Brien wrote:
On Thu, Oct 26, 2000 at 02:25:58PM -0700, Matt Dillon wrote:
/etc/rc already assumes that /var is writable. I recommend that you make
that assumption by default... have the default entropy file be something
like "/var/db/entropy_seed" and allow the
I see the opposite. I see that without writing to the /dev/random
device I get a cons is an object that cares fortune 99+% of the time
on my first login. With it, I see more decently random fortunes (but
I haven't done a statistical analysis of them to see how random things
are).
Is it
On Wed, Oct 25, 2000 at 10:35:55AM +, Terry Lambert wrote:
I see the opposite. I see that without writing to the /dev/random
device I get a cons is an object that cares fortune 99+% of the time
on my first login. With it, I see more decently random fortunes (but
I haven't done a
1) Reseed code is broken, in come case (as I describe) all reseeding data
is ignored, only its size is counted until it was as big as 16384. Mark
not fix it yet at this moment nor confirm he is able to reproduce this
bug.
I'm trying to reproduce this formally. I'm looking for reasons, not
On Wed, Oct 25, 2000 at 10:37:31AM -0700, Mark Murray wrote:
Unless _time_ will be used, /dev/random is plain unusable for production
usage.
Andrey, read the code; nanotime is all over the harvested entropy.
I saw it in the code, but it not means it working. If the time is really
taken,
I'm not knocking anyone or any code, especially considering this IS
-current... BUT... I don't need to read the code to know that I am seeing
the same fortunes on first login after reboot more often than I can
attribute to random chance. Maybe nanotime is being harvested, but it
seems that there
I'm not knocking anyone or any code, especially considering this IS
-current... BUT... I don't need to read the code to know that I am seeing
the same fortunes on first login after reboot more often than I can
attribute to random chance. Maybe nanotime is being harvested, but it
seems that
Also, what rev of /etc/rc do you have installed?
-john
- Mark Murray's Original Message -
I'm not knocking anyone or any code, especially considering this IS
-current... BUT... I don't need to read the code to know that I am seeing
the same fortunes on first login after reboot
Ok, I rebooted once and the entropy caching did not work. Changed
entropy_file to point to /var/db/entropy, rebooted. Did not
work. Commented out the entropy_file setting and rebooted... And it
worked. Rebooted 5 times, worked every time. Laptop is working
now. cvsup'd my desktop, ran mergemaster
Ok, I rebooted once and the entropy caching did not work. Changed
entropy_file to point to /var/db/entropy, rebooted. Did not
work. Commented out the entropy_file setting and rebooted... And it
worked. Rebooted 5 times, worked every time. Laptop is working
now. cvsup'd my desktop, ran
Wesley Morgan wrote:
I'm not knocking anyone or any code, especially considering this IS
-current... BUT... I don't need to read the code to know that I am seeing
the same fortunes on first login after reboot more often than I can
attribute to random chance. Maybe nanotime is being
In message [EMAIL PROTECTED] =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=
writes:
: In very recent -current, my entropy file writted and readed sucessfully,
: but I got the same fortune quote again and again right after reboot!
:
: It means that anything writted to /dev/random not reseed it but _reset_ it
On Fri, Oct 20, 2000 at 07:58:09AM +0200, Udo Schweigert wrote:
On Fri, Oct 20, 2000 at 08:48:46 +0400, Andrej Cernov wrote:
In very recent -current, my entropy file writted and readed sucessfully,
but I got the same fortune quote again and again right after reboot!
It means that
On Fri, Oct 20, 2000 at 08:48:46AM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
In very recent -current, my entropy file writted and readed sucessfully,
but I got the same fortune quote again and again right after reboot!
It means that anything writted to /dev/random not reseed it but _reset_ it
to the same
On Fri, 20 Oct 2000, Udo Schweigert wrote:
On Fri, Oct 20, 2000 at 08:48:46 +0400, Andrej Cernov wrote:
In very recent -current, my entropy file writted and readed sucessfully,
but I got the same fortune quote again and again right after reboot!
It means that anything writted to
On Fri, Oct 20, 2000 at 08:48:46AM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
In very recent -current, my entropy file writted and readed sucessfully,
but I got the same fortune quote again and again right after reboot!
It means that anything writted to /dev/random not reseed it but _reset_ it
to the same
On Fri, Oct 20, 2000 at 08:27:53PM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
On Fri, Oct 20, 2000 at 08:48:46AM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
In very recent -current, my entropy file writted and readed sucessfully,
but I got the same fortune quote again and again right after reboot!
It means that
It seems I find the problem area. 4096 bytes written in rc.shutdown are
not enough for reseeding. When I change them to 16384 bytes, it works!
I'll commit working rc.shutdown variant.
This is bogus.
_Any_ randomness written to /dev/random is good enough to perturb the
sequence.
Please do
On Fri, Oct 20, 2000 at 08:48:46 +0400, Andrej Cernov wrote:
In very recent -current, my entropy file writted and readed sucessfully,
but I got the same fortune quote again and again right after reboot!
It means that anything writted to /dev/random not reseed it but _reset_ it
to the same
52 matches
Mail list logo
