Date: Sun, 27 Aug 2000 11:11:55 -0500 From: Adam Back <adam@cypherspace.org> To: mark@grondar.za Cc: current@FreeBSD.ORG, kris@FreeBSD.ORG, jeroen@vangelderen.org Subject: Re: yarrow & /dev/random Message-ID: <200008271611.LAA07481@cypherspace.org> In-Reply-To: <200008270735.e7R7ZXp28310@grimreaper.grondar.za> (message from Mark Murray on Sun, 27 Aug 2000 09:35:32 %2B0200)
next in thread | previous in thread | raw e-mail | index | archive | help
Mark writes: > Adam writes: > > 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. Are we talking Yarrow or Ts'o's algorithm? If you have no entropy, both Yarrow and Ts'o algorithm for non-blocking IO aren't going to leak the state any time soon for computationally bounded attackers -- they only release output through one way functions (SHA1 in Ts'o and counter-mode 3DES in Yarrow-160). - Yarrow-160 has it's Gate operation to ensure you don't compromise too much old output if you obtain the pool state due to host compromise. - Ts'o's algorithm does something analogous with SHA1/MD5 (depending on which version you're using), by modifying the pool when you draw output. > > 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 :-) Yes. But the /dev/random device is traditionally crw-r--r-- which means user processes can't write to it. So you'd have to be root to do that. What could be done for yarrow is to change the device permissions to crw-rw-rw- and mix into a shared user source and set k_of_n_thresh so that the user can only trigger fast reseeds, and consider slow reseed de-skewing function output for blocking /dev/random; or just add user input with an entropy estimate of 0 so they can't affect reseeding, and draw fast reseed de-skewing function output for block /dev/random (slow output may be too slow). Adam 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?200008271611.LAA07481>