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

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

In message <[email protected]>, Mark Murray writes:
>> 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...

When /dev/random doesn't have "enough" enthropy left does reading
from it return an error, or block?  I would strongly suggest
blocking, as the non-blocking behavur is not really all that useful.

Either can simulate the other, but I think it comes down to:

non-blocking worst-case:
 a program calls /dev/random, doesn't get randomness, ignores
 error code, poorly protects some valuable thing, as a result
 the valuable thing gets stolen.

blocking worst-case:
 a program calls /dev/random, waits a long time to get random numbers,
 user curses the slow machine/program, valuable thing gets sent late,
 but is not stolen.

non-blocking best-case failure:
 a program calls /dev/random, doesn't get randomness, informs smart
 user, who finds the bad guy sucking all bits from /dev/random,
 has them ejected from system.

blocking best-case failure:
 same as worst-case (i.e. the worst-case is lots better, the best-case
 is worse).  This can be transformed to the non-blocking best-case 
 failure by clever programming (threads, or fork, or sigalarm), the
 people who do this are far more likely to actually try to issue a
 good error message then the people who get non-blocking by default.