[lkml]   [1996]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CONFIG_RANDOM (compromise?)

On Sun, 19 May 1996 08:32:17 -0500 (CDT), lilo
<> said:

> On Fri, 17 May 1996, Harald Anlauf wrote:
>> Still, I maintain that DEK's generator is superior to what most people
>> use. For non-networked machines, where security is not first priority,
>> a clearly leaner and (I think) acceptable solution.

> As long as these devices don't have the same minor numbers. Programs which
> are indiscriminate enough not to check the device before using it can then
> settle for whatever they get. Programs which consider the quality and
> derivation of the number sequences important can check, and they'll know you
> are providing a lame generator which they presumably will then want to avoid
> using....

This still misses the point. /dev/random has only one reason for
being --- to provide a clean interface to a really dirty operation:
the gathering of system-wide entropy into a random bit pool.

If you don't need this, then *you shouldn't be doing the random
generation in kernel space*!! There are dozens of pseudo-random
number generators out there, and many of them are good enough for just
about any application where unpredictability is required. In these
cases, it is perfectly adequate to generate the random sequence in
user code.

The only reason why /dev/random is needed is that to get true
unpredictability, we need to make observations of genuinely
unpredictable behaviour, and the kernel is much much better placed to
make these observations than user code is.

Programs which don't need this true unpredictability shouldn't be
using /dev/random at all --- the overhead involved is too great for
applications where the entropy isn't needed. There's no point in
replacing it with a weaker /dev/random in this case; we shouldn't be
using the kernel at all.

Only programs which genuinely require true unpredictability need to
use /dev/random, and for these applications a weak substitute is not
an option.

Stephen Tweedie <>
Department of Computer Science, Edinburgh University, Scotland.

 \ /
  Last update: 2005-03-22 13:37    [W:0.154 / U:7.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site