[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.