Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Oct 2000 12:39:57 -0700
From:      Mark Murray <mark@grondar.za>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        current@FreeBSD.ORG, markm@FreeBSD.ORG
Subject:   Re: entropy reseeding is totally broken 
Message-ID:  <200010261940.e9QJdvA00438@grimreaper.grondar.za>
In-Reply-To: <200010261905.MAA03050@usr08.primenet.com> ; from Terry Lambert <tlambert@primenet.com>  "Thu, 26 Oct 2000 19:05:15 -0000."
References:  <200010261905.MAA03050@usr08.primenet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010261940.e9QJdvA00438>