From owner-freebsd-current Thu Oct 26 12:40:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (adsl-63-206-96-212.dsl.snfc21.pacbell.net [63.206.96.212]) by hub.freebsd.org (Postfix) with ESMTP id 03DD337B479; Thu, 26 Oct 2000 12:40:27 -0700 (PDT) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.1/8.11.1) with ESMTP id e9QJdvA00438; Thu, 26 Oct 2000 12:40:06 -0700 (PDT) (envelope-from mark@grondar.za) Message-Id: <200010261940.e9QJdvA00438@grimreaper.grondar.za> To: Terry Lambert Cc: current@FreeBSD.ORG, markm@FreeBSD.ORG Subject: Re: entropy reseeding is totally broken References: <200010261905.MAA03050@usr08.primenet.com> In-Reply-To: <200010261905.MAA03050@usr08.primenet.com> ; from Terry Lambert "Thu, 26 Oct 2000 19:05:15 -0000." Date: Thu, 26 Oct 2000 12:39:57 -0700 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message