rand(2), cons(3): clarify /dev/random behaviour

This commit is contained in:
cinap_lenrek 2016-08-27 21:27:52 +02:00
parent f777743b72
commit b59aa67922
2 changed files with 4 additions and 11 deletions

View file

@ -109,10 +109,6 @@ starting state.
.I Truerand
returns a random unsigned long read from
.BR /dev/random .
Due to the nature of
.BR /dev/random ,
truerand can only return a few hundred bits a
second.
.PP
.I Ntruerand
returns a uniform random integer

View file

@ -114,13 +114,10 @@ The hostowner also has group permissions for any local devices.
.PP
Reads from
.B random
return a stream of random numbers. The numbers are
generated by a low priority kernel process that loops
incrementing a variable. Each clock tick the variable
is sampled and, if it has changed sufficiently, the last
few bits are appended to a buffer. This process is inefficient
at best producing at most a few hundred bits a second.
Therefore,
return a stream of random bytes produced by the kernels cryptographic
random number generator. The rate at which data can be read depends on
the implementation and can vary from hundreds of megabytes to just
a few hundred bits a second. Therefore,
.B random
should be treated as a seed to
pseudo-random number generators which can produce a faster