RE: kernel security questions
SEILER Werner - BD3 (werner.seiler@aut.alcatel.at)
Wed, 18 Mar 1998 17:29:13 +0100
> ----------
> From: James Mastros[SMTP:root@jennifer-unix.dyn.ml.org]
> Sent: Wednesday, 18. March 1998 16:59
> To: Jon Lewis
> Cc: Theodore Y. Ts'o; Dave Wreski; linux-kernel
> Subject: Re: kernel security questions
>
> On Mon, 16 Mar 1998, Jon Lewis wrote:
> > On Mon, 16 Mar 1998, Theodore Y. Ts'o wrote:
> > > urandom is the faster less secure random generator. Looking at
> a few dd's
> > > from it, I would think it would work as well for this purpose.
> Instead of
> > > using isalpha and friends, just make sure the char value is
> between 32 and
> > > 126. That'll give you a better range of usable but non-alpha
> characters.
> > >
> > > /dev/urandom and /dev/random use the same algorithm for generating
> > > random numbers, and so their speed is the same. The big
> difference
> > > between the two is that the random number generator keeps
> traccxcxcx
> >
> > If you try to read signifigant amounts of data from both /dev/random
> and
> > /dev/urandom, you'll find urandom to be orders of magnitude faster.
> > Perhaps this is just because /dev/random runs out of random bytes
> and
> > makes you wait for more to accumulate.
> Exactly. Take a look at the output from "cat /dev/random" -- it
> outputs a
> fair amount (no more then 256 chars, though -- the max. size of the
> random
> pool), then pauses for a while.
>
> > Perhaps trying to read large
> > amounts of data from either is misuse.
> It is. /dev/random will only return a maximum of the amount of
> randomness
> it has before blocking, whereas /dev/urandom will return bytes that
> are
> significantly less random at that point.
>
> > Either way, I took what I said
> > straight from devices.txt:
> >
> > 8 = /dev/random Nondeterministic random
> number gen.
> > 9 = /dev/urandom Faster, less secure random
> number gen.
> I suguest that you read drivers/char/random.c, which is very
> understandable
> to laypeople (the comments, anyway <G>). Specificly, lines 107-119
> are
> significant here:
> * The two other interfaces are two character devices /dev/random and
> * /dev/urandom. /dev/random is suitable for use when very high
> * quality randomness is desired (for example, for key generation or
> * one-time pads), as it will only return a maximum of the number of
> * bits of randomness (as estimated by the random number generator)
> * contained in the entropy pool.
> *
> * The /dev/urandom device does not have this limit, and will return
> * as many bytes as are requested. As more and more random bytes are
> * requested without giving time for the entropy pool to recharge,
> * this will result in random numbers that are merely
> cryptographically
> * strong. For many applications, however, this is acceptable.
>
> > If you want to generate large amounts of random data, like for
> creating
> > big files full of junk for testing new disks, using something like
> > putchar(rand()); is considerably faster than reading /dev/urandom.
>
> Not surprising. I don't think rand() uses the kernel-baised random
> number
> generator -- glibc's rand() manpage only describes rand() as returning
> "psudo-random" numbers. Also, straceing the program "main () {while
> (1)
> rand();}" revals no syscalls. This means that rand() produces
> psudo-random
> numbers with significantly less randomness.
>
The number sequence rand() (see man 3 rand) is not random at all.
Each time you let your program run, you will get the same number
sequence. Unless you seed it differently with srand.
The number sequence produced just looks random to the naked eye
and good pseudo-random number generators pass several statistical
tests about randomness.
It good for testing hardware or software with random data but don't use
it for any cryptographical purposes.
Werner Seiler
> -=- James Mastros
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu