|Андрей Чернов||Oct 19, 2000 9:48 pm|
|Udo Schweigert||Oct 19, 2000 10:57 pm|
|Андрей Чернов||Oct 19, 2000 11:39 pm|
|Андрей Чернов||Oct 19, 2000 11:51 pm|
|Doug Barton||Oct 20, 2000 1:18 am|
|Андрей Чернов||Oct 20, 2000 9:27 am|
|Андрей Чернов||Oct 20, 2000 9:43 am|
|Mark Murray||Oct 20, 2000 10:06 am|
|Андрей Чернов||Oct 20, 2000 1:13 pm|
|Warner Losh||Oct 24, 2000 11:15 am|
|Terry Lambert||Oct 25, 2000 3:35 am|
|Андрей Чернов||Oct 25, 2000 3:50 am|
|Mark Murray||Oct 25, 2000 10:37 am|
|Андрей Чернов||Oct 25, 2000 11:12 am|
|Wesley Morgan||Oct 25, 2000 2:15 pm|
|Mark Murray||Oct 25, 2000 3:12 pm|
|John W. De Boskey||Oct 25, 2000 4:20 pm|
|Wesley Morgan||Oct 25, 2000 4:50 pm|
|Mark Murray||Oct 25, 2000 5:01 pm|
|Doug Barton||Oct 25, 2000 9:28 pm|
|Ed Hall||Oct 26, 2000 12:30 am|
|David O'Brien||Oct 26, 2000 12:50 am|
|Андрей Чернов||Oct 26, 2000 1:47 am|
|Kris Kennaway||Oct 26, 2000 2:17 am|
|Kris Kennaway||Oct 26, 2000 2:21 am|
|Андрей Чернов||Oct 26, 2000 2:54 am|
|Андрей Чернов||Oct 26, 2000 3:01 am|
|Rod Taylor||Oct 26, 2000 3:30 am|
|Андрей Чернов||Oct 26, 2000 3:34 am|
|Jordan Hubbard||Oct 26, 2000 5:20 am|
|John W. De Boskey||Oct 26, 2000 6:24 am|
|Matt Dillon||Oct 26, 2000 9:55 am|
|Mark Murray||Oct 26, 2000 10:06 am|
|Mark Murray||Oct 26, 2000 10:17 am|
|John Baldwin||Oct 26, 2000 11:06 am|
|Андрей Чернов||Oct 26, 2000 11:36 am|
|Terry Lambert||Oct 26, 2000 12:04 pm|
|Mark Murray||Oct 26, 2000 12:39 pm|
|Doug Barton||Oct 26, 2000 12:49 pm|
|David O'Brien||Oct 26, 2000 1:26 pm|
|Mark Murray||Oct 26, 2000 1:29 pm|
|Matt Dillon||Oct 26, 2000 1:47 pm|
|Mark Murray||Oct 26, 2000 2:02 pm|
|Ed Hall||Oct 26, 2000 2:03 pm|
|Matt Dillon||Oct 26, 2000 2:25 pm|
|Doug Barton||Oct 26, 2000 2:44 pm|
|Poul-Henning Kamp||Oct 26, 2000 2:51 pm|
|Wesley Morgan||Oct 26, 2000 3:07 pm|
|David O'Brien||Oct 26, 2000 3:15 pm|
|Poul-Henning Kamp||Oct 26, 2000 3:18 pm|
|Jim Bryant||Oct 26, 2000 3:29 pm|
|Mark Murray||Oct 26, 2000 3:56 pm|
|Doug Barton||Oct 26, 2000 9:00 pm|
|Terry Lambert||Oct 27, 2000 5:19 pm|
|Doug Barton||Oct 27, 2000 7:18 pm|
|Subject:||Re: entropy reseeding is totally broken|
|From:||Terry Lambert (tlam...@primenet.com)|
|Date:||Oct 26, 2000 12:04:53 pm|
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 ter...@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message