Re: entropy reseeding is totally broken
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 the entropy file on the root partition which makes it available immediately, and doesn't have mounting races built in. What currently exists does not allow a read-only /. Which sucks. Please keep a couple things in mind. First, there is no one solution that is going to suit everyone. It's exactly because my /var is not on / that I got interested in patching the current implementation of "save some randomness at boot and read it back in at startup" in the first place. I kept read-only and diskless / cases in mind when I tied my idea into the existing ability to specify the file AND used /var as a failsafe. Second, Mark has always intended and is currently working on ways to make entropy harvesting happen in the boot phase. No one expected, or represented this file-based method as the ultimate solution. Third, Schneier's paper suggests loading a file of written-out entropy at boot as an additional reseeding source, so we need to work out the store a file across boot in any case. It's entirely possible that this won't work for some edge cases, but harvesting entropy in the boot process will help alleviate that. Finding answers to the current problems will be easier if we keep the goals clear. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 servers 24/7 are going to rip it right out. -Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 a long time) waiting for entropy, etc) -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 situation apparently the same as mine. If entropy file is NOT used "it worked" just because amount of data for seeding (junk from /var/run) is bigger than 16384 bytes. I suggest to try my rc.shutdown 16384 workaround too. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 statistical analysis of them to see how random things are). Is it just me, or have there been more problems achieving real statistical randomness since /dev/random went in, than at any other time in BSD history? I booted a 1.5 system a couple of times for grins. It gives you a different fortune each time. 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. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 3-4 bits of randomness - meaning if thats all you seed with then your attacker has to brute-force 3-4 bits of state to break the PRNG state as it was at boot time, hardly a difficult challenge :-) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 /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 + cat /var/db/entropy + entropy_reseeded=yes + rm -f /var/db/entropy /var/db/entropy -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 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 with then your attacker has to brute-force 3-4 bits of state to break the PRNG state as it was at boot time, hardly a difficult challenge :-) This issue not about cryptographically strong randomness but about /dev/random seeding totally not worked, even 3-4 bits of time not used across the boot. Guessing 0 bits for your attacker is much easy then 3-4 bits :-) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 nanotime is being harvested, but it seems that there is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. How exactly are you rebooting? If you're using the 'reboot' command, that explains why entropy reseeding is not working. As has been discussed several times on -current, you only run rc.shutdown if you use another method, like 'shutdown -r now', 'init 6', or even the trust three-finger salute. 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 venerate expectantly." (I don't think it helps much, the bug is definitely in the kernel random module, not in rc files or fortune) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 here - if we're not seeding /dev/random effectively at startup, fortune is the least of our worries since all the other startup services will be unrandom as well. This situation I see with /dev/random is kind of disturbing since I think we're running the danger of falling into the following all-too-common scenario in engineering: 1) Person X falls in love with a new algorithm or technique and implements it in a fairly key service with quite a few rough edges. 2) The users fail to embrace this new technology all that fervently since those same rough edges make it a promising but annoying or downright non-functional implementation. 3) Person X vigorously defends himself and/or the algorithm since he knows it's really a much better thing in the long run and simply needs "tweaking" to make it fully work. 4) The users see this as an attempt to cram broken bits down their throats and just as vigorously fight back against what they see as someone's fancy solution in search of a problem to solve. 5) Constructive dialog breaks down and it all turns into an exchange of increasingly irritated words as each side feels the other isn't hearing what it's trying to say or appreciating the bigger pictures. Let's try not to go there with /dev/random, please. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 that, it hurts me. which has caused alot of good code to never see the light of day. -John - Jordan Hubbard's Original Message - 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 here - if we're not seeding /dev/random effectively at startup, fortune is the least of our worries since all the other startup services will be unrandom as well. This situation I see with /dev/random is kind of disturbing since I think we're running the danger of falling into the following all-too-common scenario in engineering: 1) Person X falls in love with a new algorithm or technique and implements it in a fairly key service with quite a few rough edges. 2) The users fail to embrace this new technology all that fervently since those same rough edges make it a promising but annoying or downright non-functional implementation. 3) Person X vigorously defends himself and/or the algorithm since he knows it's really a much better thing in the long run and simply needs "tweaking" to make it fully work. 4) The users see this as an attempt to cram broken bits down their throats and just as vigorously fight back against what they see as someone's fancy solution in search of a problem to solve. 5) Constructive dialog breaks down and it all turns into an exchange of increasingly irritated words as each side feels the other isn't hearing what it's trying to say or appreciating the bigger pictures. Let's try not to go there with /dev/random, please. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
: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 servers 24/7 are going to rip it right :out. : : -Ed I don't understand why /dev/random has to be reseeded with so many bytes in the first place... 64 or 128 bytes ought to do it, and if they don't then there is something fundamentally wrong with /dev/random that needs to be addressed. The proper way to address is NOT to try to push a larger seed into it. Hell, a *4* byte reseeding should generate sufficient randomness for our purposes (though obviously it is not cryptographically secure enough). I am certainly not willing to wait more then 500ms on boot for /dev/random to seed, and I doubt very many other people would be either. In regards to 'reboot' verses 'shutdown' ... the solution here is 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 people using 'shutdown' is silly since most people run their machines either until they drop, or use 'reboot' rather then 'shutdown'. The solution is to deal with entropy at boot time, and also regenerate the file from /etc/periodic/daily. At boot time you do this: * load the entropy file (128 bytes is plenty!) * fold in the current time (including microseconds) * fold in the "/" directory's mtime * fold in some junk from /var/log and dmesg. * save the entropy file * done. From /etc/periodic/daily you do this: * generate a random number * store it as the entropy file (128 bytes is plenty!) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 + cat /var/db/entropy + entropy_reseeded=yes + rm -f /var/db/entropy /var/db/entropy This is what I needed to see! Next; please see if you can capture a few /var/db/entropy files. You'll need to cp(1) them in /etc/rc - DON'T drop to single-user. Please see if you can get about 5 of them. DON'T mail them to me, put them somewhere where I can ftp of http them. Thanks! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 + cat /var/db/entropy + entropy_reseeded=yes + rm -f /var/db/entropy /var/db/entropy Could you please build the random.ko module with -DDEBUG and let me know at what stage the first reseed event happens? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 attribute to random chance. Maybe nanotime is being harvested, but it seems that there is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. How exactly are you rebooting? If you're using the 'reboot' command, that explains why entropy reseeding is not working. As has been discussed several times on -current, you only run rc.shutdown if you use another method, like 'shutdown -r now', 'init 6', or even the trust three-finger salute. 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. And if a malicious user on your machine grabs the saved entropy file and then reboots your machine using some exploit of some sort? Granted neither of these tasks may be easy, and it could be done in such a way that the first requires root access. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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. Cron job to build entropy is much lesser evil than writting any files at reboot stage. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 with then your attacker has to brute-force 3-4 bits of state to break the PRNG state as it was at boot time, hardly a difficult challenge :-) The actual time would probably be more useful than the time since boot. I still have a problem with what I see as a fundamental weakness in storing "randomness" across reboots. Logically, given a sufficiently large amount of time between a crash and the subsequent reboot, one could predict the random state, and attack immediately after a reboot... just like one could guess the fortune now, following a reboot. The state save in the shutdown -- besides not working unless you hopping on one leg, pat your head, and rub your tummy while singinging "Danny Boy" (or the moral equivalent of not being allowed to crash or use the "halt" or "reboot" commands) -- seems to me to be an inherent security flaw. Matt's points about compromise, number of random bits, as well as the amount of time it's OK to take, are also salient. Bottom line: any algorithm predicated only on saved state and based on predictable progression over a large period of time in which a compromise may be effected, is a problem. Jordan's points are good ones as well. I think that if /dev/random can be shown to be a solid foundation, it could be a keystone in an overall security strategy that can then be used to build large, sturdy, secure, edifices. But _unless_ it's shown to be a solid foundation, using it as a keystone is going to turn everything else into a house of cards, where if you compromise /dev/random, then you have a skeleton key to everything. I'm not too worried about people seeing fortunes before their time... they could always look at the fortunes.dat file anyway. But the implication in randomness used elsewhere in the system is nowhere so obvious when it is broken as when getting the same fortune each time you boot. Perhaps it's time to draft a "big gun"? Someone who knows enough about number theory to know that multiplying two random numbers together results in less randomness, not more? Or perhaps it's time to use a "tried but true" algorithm, like the 48 bit linear congruential algorithm, with a polynomial preterbation based on the current time at the time of reseeding, until the random ducks get (not) in a row? Pseudorandom seeding with a hidden key has got to be better than anything that opens a computation window for as long as your system is down after a crash... after all, we _are_ talking about security through obscurity (of the next number in a pseudorandom sequence), here. Nothing wrong with finding a handy giant, and standing on its shoulders... it's a time honored scientific tradition. I'm not really volunteering here, since I'm just an applied mathematician, and only ever got off on theory as it applied to real problems in physics and computer science and elsewhere. I just know enough to know that it'd be dangerous to trust me to do the job 100% correctly. 8-). But I also see this as getting more important as /dev/random gets more and more central to security and authentication policy and enforcement. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 sufficiently large amount of time between a crash and the subsequent reboot, one could predict the random state, and attack immediately after a reboot... just like one could guess the fortune now, following a reboot. Sure. If you followed the complete thread, you'll see we are trying to deal with this. The state save in the shutdown -- besides not working unless you hopping on one leg, pat your head, and rub your tummy while singinging "Danny Boy" (or the moral equivalent of not being allowed to crash or use the "halt" or "reboot" commands) -- seems to me to be an inherent security flaw. Not really. To exploit it, you need to be either root or have the console. It would be easier to get the state out of /dev/kmem at that stage. We covered this _months_ ago. Matt's points about compromise, number of random bits, as well as the amount of time it's OK to take, are also salient. Bottom line: any algorithm predicated only on saved state and based on predictable progression over a large period of time in which a compromise may be effected, is a problem. The relevance to Yarrow is...? And your solution is.? Perhaps it's time to draft a "big gun"? Someone who knows enough about number theory to know that multiplying two random numbers together results in less randomness, not more? Bruce Schneier good enough? Or perhaps it's time to use a "tried but true" algorithm, like the 48 bit linear congruential algorithm, with a polynomial preterbation based on the current time at the time of reseeding, until the random ducks get (not) in a row? Pseudorandom seeding with a hidden key has got to be better than anything that opens a computation window for as long as your system is down after a crash... after all, we _are_ talking about security through obscurity (of the next number in a pseudorandom sequence), here. Yarrow not good enough for you? Why not? What cryptanalysis of it are you aware of that leads to a compromise? Where is your rebuttal of Schneier's "Attacking PRNG's" paper? Nothing wrong with finding a handy giant, and standing on its shoulders... it's a time honored scientific tradition. And I didn't do this how? I'm not really volunteering here, since I'm just an applied mathematician, and only ever got off on theory as it applied to real problems in physics and computer science and elsewhere. I just know enough to know that it'd be dangerous to trust me to do the job 100% correctly. 8-). But I also see this as getting more important as /dev/random gets more and more central to security and authentication policy and enforcement. Isn't theory wonderful? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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.
And if a malicious user on your machine grabs the saved entropy file
and then reboots your machine using some exploit of some sort? Granted
neither of these tasks may be easy, and it could be done in such a way
that the first requires root access.
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
weren't picking up new entropy sources during the boot process.
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 neither file
exists. The only remaining questions would be how many k of data to dump
how often.
Doug
--
"The dead cannot be seduced."
- Kai, "Lexx"
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 technologies and integration, even with rough edges. However, such integration should not cause major pain for more than 3-4 days. Anything more than 3 days or so, can really impact other's work. devrandom has taken a little longer than this. Over the past 3 weeks (or so), I've I've lost a day to this, and others piped up saying they've lost a lot of time too. This does not make me happy when writing my status reports to my boss, or others who really hoped to spend their Sunday afternoon developing their favorite new feature and instead couldn't. -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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
weren't picking up new entropy sources during the boot process.
There is an angle; an attacker can attack by replaying, but this requires
strong privelige.
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 neither file
exists. The only remaining questions would be how many k of data to dump
how often.
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).
On a related note, I'd like to see mergemaster rebuild /dev if it is not
DEVFS (obviously taking into account user preferences in MAKEDEV.local).
I believe that users are shootin their feet by not tracking /dev properly.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
: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: http://www.cauce.org 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. 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 dump will overwrite swap, so you would have to mess around with that as well and I can tell you it just isn't worth the effort. Maintaining an entropy file in /var/db has no downside at all and is a whole lot easier to manage. This /dev/random stuff is a little wild -- I think the premis is sound, but you really need to look towards implementing more straightforward solutions rather then hacking up unrelated parts of the system. Forget doing special magic in the kernel. Forget using swap. Forget having ridiculously huge entropy files. Simplify it and everyone will be a whole lot happier. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 neither file
: exists. The only remaining questions would be how many k of data to dump
: how often.
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.
I've little doubt of /dev/random's theoretical soundness. But a
theoretical boost in security won't justify an actual reduction in
availability to many folks.
-Ed
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 dump will overwrite swap, so you would have to mess around with that as well and I can tell you it just isn't worth the effort. Maintaining an entropy file in /var/db has no downside at all and is a whole lot easier to manage. There is the problem that for each setup, there are many admins who will have a non-writable filesapce for at least one of (/ /var /boot /etc). Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best place to put stashed entropy. This /dev/random stuff is a little wild -- I think the premis is sound, but you really need to look towards implementing more straightforward solutions rather then hacking up unrelated parts of the system. Forget doing special magic in the kernel. Forget using swap. Forget having ridiculously huge entropy files. Simplify it and everyone will be a whole lot happier. :-) I'd like your suggestion a lot more if you supplied some more concrete hints. I like KISS, and current evolution is looking a little wierd. I'd enjoy seeing a true/beautiful/simple solution - patches welcome. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
: 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 dump will : overwrite swap, so you would have to mess around with that as well : and I can tell you it just isn't worth the effort. Maintaining an entropy : file in /var/db has no downside at all and is a whole lot easier : to manage. : :There is the problem that for each setup, there are many admins who :will have a non-writable filesapce for at least one of (/ /var /boot /etc). : :Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best :place to put stashed entropy. /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 with an RC variable. You could allow the administrator to select a different entropy file and you could have another RC variable which allows the administrator to set a command which, when executed, returns an arbitrary sequence of bytes on its stdout to initialize entropy with. defaults (in /etc/defaults/rc.conf) (this is an example) entropy_file="/var/db/entropy_seed" entropy_program="/sbin/gather_entropy -time -hostname -rootstatfs" entropy_file_mode="RW" Example override: entropy_file="NO" entropy_program="/usr/local/bin/my_special_entropy_program" Another example override: # seed with read-only entropy file and then gather additional # entropy from other sources, like the time. # entropy_file_mode="RO" entropy_program="/sbin/gather_entropy -network -time -keyboard_if_insufficient" etc... This would give us maximum flexibility, yet provide suitable defaults for most sysinstall-based configurations. For example, this gives you the ability to write an /sbin utility to do the more complex (or more secure) entropy gathering as part of the boot process and then allow the administrator to specify it with appropriate options to suit his tastes, rather then having to build it into the kernel. Your /sbin program could deal with things like using swap instead of an entropy file and so forth. I think if you did things this way it would remove virtually all the pain developers are feeling from the current state of affairs. : lot happier. : ::-) I'd like your suggestion a lot more if you supplied some more concrete :hints. I like KISS, and current evolution is looking a little wierd. I'd :enjoy seeing a true/beautiful/simple solution - patches welcome. :-) : :M See above. -Matt :-- :Mark Murray :Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 problem is, it's going to block somewhere. If we don't "block" while creating the entropy, the first thing that needs random bits is going to block for real because /dev/random isn't going to have anything to feed it. We must come up with an entropy reseeding mechanism that has a reasonably high degree of success for a reasonably high number of cases. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 more than a little paternalistic. The problem is, it's going to block somewhere. If we don't "block" while creating the entropy, the first thing that needs random bits is going to block for real because /dev/random isn't going to have anything to feed it. We must come up with an entropy reseeding mechanism that has a reasonably high degree of success for a reasonably high number of cases. I think the strategy here is to feed it as much as we can from the kernel during device-probe/attach as possible. 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. Add a /etc/rc.conf knob which says wait_until_entropy_collected=YES which people who care a lot about randomness can set. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 The FreeBSD Project. Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 26 17:32:23 catalyst sshd[193]: Generating 768 bit RSA key. Oct 26 17:32:23 catalyst sshd[193]: RSA key generation complete. Those times aren't correct I'm sure, but if I can't get enough entropy for a 768 bit key _very soon_ after boot, we could have a problem. Somehow, I think everyone should care about that. Add a /etc/rc.conf knob which says wait_until_entropy_collected=YES Why not be secure by default and have i_dont_care_about_entropy=NO -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 with an RC variable. You could allow the administrator to select a different entropy file and you could have another RC variable which allows the administrator to set a command which, when executed, returns an arbitrary sequence of bytes on its stdout to initialize entropy with. 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. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 catalyst /boot/kernel/kernel: Copyright (c) 1992-2000 The FreeBSD Project. Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 26 17:32:23 catalyst sshd[193]: Generating 768 bit RSA key. Oct 26 17:32:23 catalyst sshd[193]: RSA key generation complete. Those times aren't correct I'm sure, but if I can't get enough entropy for a 768 bit key _very soon_ after boot, we could have a problem. Somehow, I think everyone should care about that. You know, I think this thing is being blown out of proportion. WAY out of proportion. Yes, there are systems which the administrator will want to set to ultra_paranoid=YESDAMNIT! but for all the machines I have behind firewalls I would like to have act_like_a_normal_unix_and_boot_in_finite_time=YESPLEASE -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 13.4 of the Rijndael Block Cipher AES Proposal [version 2], describes this functionality. Based on the benchmark times of this process, I don't think it would be a serious performance hit to do this. If it's going to be in the kernel anyway... Just a constructive suggestion. In reply: 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 servers 24/7 are going to rip it right out. -Ed jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- [EMAIL PROTECTED] KC5VDJ - HF to 23cm KC5VDJ@NW0I.#NEKS.KS.USA.NOAM HF/VHF: IC-706MkII VHF/UHF/SHF: IC-T81AKPC3+ PK-232MBXGrid: EM28px -- ET has one helluva sense of humor, always anal-probing right-wing schizos! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 problem that for each setup, there are many admins who :will have a non-writable filesapce for at least one of (/ /var /boot /etc). : :Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best :place to put stashed entropy. /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 with an RC variable. You could allow the administrator to select a different entropy file and you could have another RC variable which allows the administrator to set a command which, when executed, returns an arbitrary sequence of bytes on its stdout to initialize entropy with. defaults (in /etc/defaults/rc.conf) (this is an example) entropy_file="/var/db/entropy_seed" entropy_program="/sbin/gather_entropy -time -hostname -rootstatfs" entropy_file_mode="RW" Example override: entropy_file="NO" entropy_program="/usr/local/bin/my_special_entropy_program" Another example override: # seed with read-only entropy file and then gather additional # entropy from other sources, like the time. # entropy_file_mode="RO" entropy_program="/sbin/gather_entropy -network -time -keyboard_if_insufficient" etc... This would give us maximum flexibility, yet provide suitable defaults for most sysinstall-based configurations. For example, this gives you the ability to write an /sbin utility to do the more complex (or more secure) entropy gathering as part of the boot process and then allow the administrator to specify it with appropriate options to suit his tastes, rather then having to build it into the kernel. Your /sbin program could deal with things like using swap instead of an entropy file and so forth. I think if you did things this way it would remove virtually all the pain developers are feeling from the current state of affairs. : lot happier. : ::-) I'd like your suggestion a lot more if you supplied some more concrete :hints. I like KISS, and current evolution is looking a little wierd. I'd :enjoy seeing a true/beautiful/simple solution - patches welcome. :-) : :M See above. -Matt :-- :Mark Murray :Join the anti-SPAM movement: http://www.cauce.org -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 administrator to override it with an RC variable. You could allow the administrator to select a different entropy file and you could have another RC variable which allows the administrator to set a command which, when executed, returns an arbitrary sequence of bytes on its stdout to initialize entropy with. 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 the root partition which makes it available immediately, and doesn't have mounting races built in. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 just me, or have there been more problems achieving real statistical randomness since /dev/random went in, than at any other time in BSD history? I booted a 1.5 system a couple of times for grins. It gives you a different fortune each time. Note that 1.5 "lacked" /dev/random. Perhaps it's time to rename it as /dev/deliberate? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 statistical analysis of them to see how random things are). Is it just me, or have there been more problems achieving real statistical randomness since /dev/random went in, than at any other time in BSD history? I booted a 1.5 system a couple of times for grins. It gives you a different fortune each time. Note that 1.5 "lacked" /dev/random. It is because /dev/random totally ignore _time_ and not reseed from it, but no other randomness source available at boot time. At the boot /dev/random tries to reseed from other sources (excepting time), but: 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. 2) Reseeding state may not preserve across the boot due to various reasons like panic, etc. Since _time_ is ignored, all other data /etc/rc tries to collect now can be non-random _easily_! Unless _time_ will be used, /dev/random is plain unusable for production usage. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 any more hacks. 2) Reseeding state may not preserve across the boot due to various reasons like panic, etc. Since _time_ is ignored, all other data /etc/rc tries to collect now can be non-random _easily_! Unless _time_ will be used, /dev/random is plain unusable for production usage. Andrey, read the code; nanotime is all over the harvested entropy. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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, neither mine or Warner case is ever possible. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. On Wed, 25 Oct 2000, Mark Murray wrote: 2) Reseeding state may not preserve across the boot due to various reasons like panic, etc. Since _time_ is ignored, all other data /etc/rc tries to collect now can be non-random _easily_! Unless _time_ will be used, /dev/random is plain unusable for production usage. Andrey, read the code; nanotime is all over the harvested entropy. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. I am not seeing this, and I am unable to reproduce it. i terefore need better info than "it is so" to do anything about it. Please get a complete log of the boot process (put a set -x in /etc/rc while you are about it) and get that over to me. M On Wed, 25 Oct 2000, Mark Murray wrote: 2) Reseeding state may not preserve across the boot due to various reason s like panic, etc. Since _time_ is ignored, all other data /etc/rc tries to collect now can be non-random _easily_! Unless _time_ will be used, /dev/random is plain unusable for production usage. Andrey, read the code; nanotime is all over the harvested entropy. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 more often than I can attribute to random chance. Maybe nanotime is being harvested, but it seems that there is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. I am not seeing this, and I am unable to reproduce it. i terefore need better info than "it is so" to do anything about it. Please get a complete log of the boot process (put a set -x in /etc/rc while you are about it) and get that over to me. M To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 and it worked for 3 reboots... 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" has shown up first nearly every time for the past week. Waiting a few minutes to log in has no effect... Still the same one. Now I'm no expert on randomness and the like, but surely this can't be very random. I'll be eating my words tonight, but I swear it wasn't working for me :) (and yes i had the latest rc files). On Wed, 25 Oct 2000, Mark Murray wrote: I am not seeing this, and I am unable to reproduce it. i terefore need better info than "it is so" to do anything about it. Please get a complete log of the boot process (put a set -x in /etc/rc while you are about it) and get that over to me. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 and it worked for 3 reboots... I need logs. What is "did not work"? What is "it worked"? What was the line you commented out? What are the other things that your eye/brain are filtering out that I need to see in copious detail? M 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" has shown up first nearly every time for the past week. Waiting a few minutes to log in has no effect... Still the same one. Now I'm no expert on randomness and the like, but surely this can't be very random. I'll be eating my words tonight, but I swear it wasn't working for me :) (and yes i had the latest rc files). On Wed, 25 Oct 2000, Mark Murray wrote: I am not seeing this, and I am unable to reproduce it. i terefore need better info than "it is so" to do anything about it. Please get a complete log of the boot process (put a set -x in /etc/rc while you are about it) and get that over to me. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 harvested, but it seems that there is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. How exactly are you rebooting? If you're using the 'reboot' command, that explains why entropy reseeding is not working. As has been discussed several times on -current, you only run rc.shutdown if you use another method, like 'shutdown -r now', 'init 6', or even the trust three-finger salute. Good luck, Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 : to the same default state. 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). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 anything writted to /dev/random not reseed it but _reset_ it to the same default state. How do you shutdown your machine: a) reboot or halt b) shutdown -r now If a) the /entropy file is not updated and the existing one will be used at next reboot. Only when using shutdown the /etc/rc.shutdown file will be executed. That was a problem for me, as I often use "halt". I shutdown my machine via Ctrl-Alt-DEL and see "Writting entropy file" message on console, i.e. rc.shutdown is activated. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 default state. BTW, I can't reproduce it on the machine with ethernet card, it happens only on my home dialup machine. It seems random can gather something from ethernet which masks this bug. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 /dev/random not reseed it but _reset_ it to the same default state. How do you shutdown your machine: a) reboot or halt b) shutdown -r now C-A-D usually works too, as does 'init 6'. One of the oft-agreed on topics at the con is that we need a _consistent_ schedule of events for all forms of shutdown that are not explicitly "fast" shutdown paths that for whatever reason we don't want to schedule things like rc.shutdown and sync for. Expect to see conversation about this on -arch sometime soon. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 default state. 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. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 anything writted to /dev/random not reseed it but _reset_ it to the same default state. 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! BTW, 16384 is _minimal_ value, all lower values _not_ cause reseeding. I don't know, why. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 _not_ make that commit. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
entropy reseeding is totally broken
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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
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 default state. How do you shutdown your machine: a) reboot or halt b) shutdown -r now If a) the /entropy file is not updated and the existing one will be used at next reboot. Only when using shutdown the /etc/rc.shutdown file will be executed. That was a problem for me, as I often use "halt". Regards -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 ZT IK 3, Siemens CERT| Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] PGP-2/5 fingerprint | D8 A5 DF 34 EC 87 E8 C6 E2 26 C4 D0 EE 80 36 B2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
