[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]

>    Something I didn't mention earlier; we felt that letting the unwashed
>    masses read /dev/*random was not a good idea, as they could deplete
>    the pool of entropy all to easily for attack purposes. 
> That should be a system administration issue.  If someone wants to make
> /dev/random readable only by root at their site, that's their business.
> I don't see any point in trying to enforce that in the kernel code.

Is not in the kernel, this is just the permissions on /dev/*random.

> I don't agree that restricting read access is useful.  First of all, if
> the pool of entropy is depleted, someone who tries to obtain entropy by
> reading /dev/random will know that they didn't get enough entropy.  So
> assuming a program that actually checks return values from system calls,
> this is at worse a denial of service attack, and there are much easier
> ways of performing those srots of attacks: "while (1) fork()", for
> example.

Hmm. Lemme think about this...

> Secondly, making /dev/random only readable by "privileged programs"
> means that people won't be able to compile their own version of PGP that
> can take advantage of the random number generator.  Instead, they would
> have to use a setuid version of PGP, and I'm quite sure PGP wasn't
> written such that it would be safe to turn on its setuid bit.  

How about SetGID? We were going for 660 root.kmem.

> Finally, even if you did have trustworthy applications which you could
> setuid and only allow those programs to have access to /dev/random,
> someone who repeatedly ran those applications could still end up
> depleteing the pool of entropy.
> So in the general case I would advise that /dev/random be left world
> readable, since you *do* want general user programs to have access to
> high quality random numbers.  

Ponder... I'll put this forward.

> Again, /dev/random can be set to whatever permissions the system
> administrator wants.  Secondly, writing to /dev/random merely adds
> randomness to the pool, via the mixing algorithm.  It won't actually
> permit people to *set* the state of the pool, and assuming that the
> state of the pool is not known before the write operation, writing to it
> won't allow the user to know what the state is after the write
> operation.

What happens if some attacker does:

for (;;) {

? "Gut feel" suggests to me that large ammounts of "predicted" input might
be worse than the normal sort of system noise you have been using.

> And, for race condition reasons, something which I need to implement
> soon is an ioctl(), usuable only by root, that simultaneously updates
> the entropy estimate *and* submits data to be mixed into the pool.  (Why
> this is necessary should be obvious after a few minutes thought.)

Clue me in - I'm not quite with you? :-)

>    Are you sure about this? The stochastisity if this would be pretty
>    hefty. Not only would our attacker have to get the _time_ that the
>    interrupt occurred (if it interrupted our machine), he would then have
>    to process in brute-force mode all possible times in his error range.
>    What is more, more interrupts are coming in...
> I didn't say that it would be trivial for an attacker to do this, but
> it's certainly *doable*.  Some of the network traffic analyzers that
> have been made available (I think Sandia National Labs has one that does
> this), records down to millisecond accuracy when a packet was sniffed on
> the network.  

Is this millisecond accuracy quantifiable in terms of bits of entropy?
if so, the ethernet is surely safe?

> For this reason, people shouldn't really trust initializing PGP's random
> number generator over a network connection, since it is possible for an
> adversary to obtain very high quality timings of when your telnet or
> rlogin packets appeared on the network, and hence be able to guess
> (within some error range) what the interkeyboard timings which PGP used
> to initialize its random number generator.
> The adversary might have to try a large number of possibilities, but if
> the number of possibilities is less than a brute-force search, you
> definitely have a weakness --- a fact which Netscape learned to its
> embarassment a few weeks ago.

Again, if you can quantify the number of possibilities into bits of entropy,
your code is good. Depending on current technology, this may have to change.


Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger [email protected] for PGP key