[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    fairness & liveness wrt /dev/[u]random (Re: linux-ipsec: Re: TRNG, PRNG)
From:       Adam Back <adam () cypherspace ! org>
Date:       1999-07-29 8:14:28
[Download RAW message or body]


Anonymous writes about competition for /dev/random arising from other
processes and from processes using /dev/urandom which will use
/dev/random when available.  ("Use" in the sense that it reseeds using
the /dev/random, and I take it from anonymous analysis actually
removes bytes from /dev/random so that processes consuming from
/dev/urandom could stall processes reading from /dev/random?)

I think the conclusion of the above kind of arguments are that
fairness and liveness ought to be applied to the consumption of
/dev/random and /dev/urandom.  Probably for IPSEC purposes that should
be fairness wrt IP connections to ensure graceful degradation.

But in general I side with the people who effectively say, so use
/dev/urandom, it's "good enough", and this is exactly what it does --
use entropy while available, and rehash old state when not.

People who worry about attacks relying on state compromise (getting a
copy of the RNG state by breaking into the machine, and with no fresh
entropy mixed in being able to predict output) I think though this is
technically a valid attack, _practically_ it is less relevant because
someone who can compromise the RNG state (which requires root) can
just as easily replace the binaries etc.

To elaborate briefly on Ben Laurie's suggestion to use hashcash:
hashcash is designed for making depletion attacks computationally
expensive for the attacker -- with hashcash you are requiring a
tunably computationally expensive computation before the server will
allocate some resource (CPU committment, buffer allocation, random
number consumption).  As the server load increases (say under an
attack), you can increase hashcash computation required per connection
for the connecting process / machine or for all machines.
(http://www.dcs.ex.ac.uk/~aba/hashcash)

Adam

[prev in list] [next in list] [prev in thread] [next in thread]