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
> > advantage
> > 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 the entropy file on th
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 th
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 proble
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
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 2
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
>
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
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 en
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
:> 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
> 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 syste
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
: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 movement
> 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
>
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 tec
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 som
> 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 s
> > 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 s
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
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 ofte
> > 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 f
> > 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 f
: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 r
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
> 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 ma
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 v
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 cha
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 usin
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):
+ [
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 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 don
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 situa
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
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 running
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 harv
> 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 me
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
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 reboo
> 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 th
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
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
tak
> 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: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 don
> 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
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_ i
On Fri, Oct 20, 2000 at 10:06:37AM -0700, Mark Murray wrote:
> > 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
> 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: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 th
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
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 t
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
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 tha
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 sa
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 default state.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubs
55 matches
Mail list logo
