> 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
- Ts'o's algorithm does something analogous with SHA1/MD5 (depending
on which version you're using), by modifying the pool when you draw
> > 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
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).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message