From owner-freebsd-current  Sun Aug 27  8:10:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cypherspace.org (modemcable228.178-201-24.mtl.mc.videotron.net [24.201.178.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 743FD37B424; Sun, 27 Aug 2000 08:10:23 -0700 (PDT)
Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id LAA07481; Sun, 27 Aug 2000 11:11:55 -0500
Date: Sun, 27 Aug 2000 11:11:55 -0500
Message-Id: <200008271611.LAA07481@cypherspace.org>
From: Adam Back <adam@cypherspace.org>
To: mark@grondar.za
Cc: current@FreeBSD.ORG, kris@FreeBSD.ORG, jeroen@vangelderen.org
In-reply-to: <200008270735.e7R7ZXp28310@grimreaper.grondar.za> (message from
	Mark Murray on Sun, 27 Aug 2000 09:35:32 +0200)
Subject: Re: yarrow & /dev/random
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


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