Date: Sun, 27 Aug 2000 09:35:32 +0200 From: Mark Murray <mark@grondar.za> To: Adam Back <adam@cypherspace.org> Cc: current@FreeBSD.ORG, kris@FreeBSD.ORG, jeroen@vangelderen.org Subject: Re: yarrow & /dev/random Message-ID: <200008270735.e7R7ZXp28310@grimreaper.grondar.za> In-Reply-To: <200008262349.SAA06044@cypherspace.org> ; from Adam Back <adam@cypherspace.org> "Sat, 26 Aug 2000 18:49:56 EST." References: <200008262349.SAA06044@cypherspace.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Mark writes: > > [...] > > FreeBSD is using an earlier version of T'so's code; I beiieve he > > improved it later, but it has no (or little) backtracking protection, > > and can be too easily attacked "from both sides". > > OK, I agree that that's an area where yarrow offers better protection. > But it's not like Ted's code is broken or anything. We would break > things using /dev/random by switching as is to yarrow, so this is why > I don't like it: we're trying to improve things (Yarrows protection > aginst the attacks you describe), but in order to do this we're doing > some other damage. We should at least do no damage: we're improving > one thing and breaking something else. Again, I'm not so sure; Yarrow goes to great trouble to protect its internal state; by blocking, I have this very nasty suspicion that this carefully guarded state is being disclosed. The moment you block, you are confiding in the fact that you have no updating entropy, and as a result /dev/urandom gan be attacked to get the internal state. > > > The solution as I see it is to modify yarrow to bypass the yarrow > > > output function and grab raw de-skewing function output for > > > /dev/random output. You'd also want to do what John Kelsey was > > > suggesting and XOR the bypassed de-skewing function output with > > > /dev/urandom output as an additional safety measure. > > > > I'll look that up; It sounds like quite a departure from yarrow to > > me though; that makes me nervous. > > Well you leave most of yarrow alone, you just add the ability to > reserve de-skewing function outputs for /dev/random. /dev/urandom > still goes through the normal yarrow output function. OK - reasonable. > > ...there may not be a suitable monkey at the keyboard. What about > > a server in an unattended colo? MHO - hardware RNG. > > Unattended servers are a problem alright. > > One thing you can do is if your server has any private keys -- and it > generally will have if it's doing crypto -- is mix the private key > into the random pool along with the curren time. As the attacker > doesn't know your private key (if he does it's game over anyway), you > get a /dev/urandom which is secure. That works with what I already have: cat $privatekey > /dev/random :-) > The other thing you can do is mix in encrypted IVs people connecting > to your server send you -- for example SSL, SSH, and PGP and so on > tend to do this. It can't hurt because you're only mixing, and you > can't destroy entropy with a good mixing function; and if you presume > the collection of people who connect to you aren't colluding it helps. > (If there is only one person communicating with you, it doesn't matter > anyway, because they have their own plaintext.) > > We should encourage people to do these two things. I agree. we also need a device driver for Intel's harware RNG. I have some example code. 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?200008270735.e7R7ZXp28310>