/dev/urandom vs. /dev/random

**Joona I Palaste** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

Ron Peterson <rpeterso@mthol yoke.edu> scribbled the following:[color=blue]
> In the following piece of code, which simply generates a sequence of
> (random) octal codes, I'm surprised by the apparent non-randomness of
> /dev/random. It's not noticeable unless RAND_LENGTH is largish. I was
> under the assumption that /dev/random was "more random" than
> /dev/urandom, and that it would block if it ran out of entropy until it
> got more. Why am I seeing so many zeroes in my output?[/color]

Your question is about the Unix devices /dev/random and /dev/urandom,
not about C. Please continue discussion about this on
comp.unix.progr ammer.
[color=blue]
> #include <stdio.h>
> #include <fcntl.h>
> #define RAND_LEN 1024[/color]
[color=blue]
> void
> read_random( const char* dev ) {
> int i, fd;
> char dat[RAND_LEN];[/color]
[color=blue]
> fd = open( dev, O_RDONLY );[/color]
[color=blue]
> dat[RAND_LEN] = '\0';[/color]
[color=blue]
> if( fd != -1 ) {
> read( fd, dat, RAND_LEN );
> for( i = 0; i < RAND_LEN; i++ ) {
> dat[i] = (dat[i] >> 4 & 0x07) + 48;
> }
> printf( "%s: %s\n\n", dev, dat );
> } else {
> exit( 1 );
> }[/color]
[color=blue]
> close( fd );
> }[/color]
[color=blue]
> int
> main( void ) {
> read_random( "/dev/random" );
> read_random( "/dev/urandom" );
> return( 0 );
> }[/color]
[color=blue]
> 506$ ./test[/color]
[color=blue]
> /dev/random: 200050617063526 437602510346655 072474031767426 306605046222320 604001730615000 243427435070303 503367456120754 173510400040000 000050000000000 007737204577300 001773560405044 500220434040000 340417736104640 464040000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000640423461 000000000000000 000000000000000 000000000000024 040000000041007 000000063461000 000000000000000 000000000000000 000000000000000 000000000000000 000000005604000 000000000340437 730400377305043 000000047730000 000000000000000 0[/color]
000000003000100 000000000000000 000000000000000 000000000000000 000000000000000 000000004500450 040000000020007 004130433040704 000017043404170 405042773070405 040030160457732 404000067040000 000000000000000 070042000640400 003404000064046 773000450040000 000057732000700 413043304070400 001704340464044 000477307044000 077000007773240 400005704000000 000000000000000 000000034047100 070477732204170 467040000000000 007773000000000 000000007700773 540405041604630 407045773377302 047000200040044 773577311046414 641437736504641 457733404000054 0
417732204640457 04
[color=blue]
> /dev/urandom: 103137002760751 330471453227547 317447153305403 055445577241174 112554437473707 174466515247147 230165510321673 032612147044376 361336471103425 426601777564215 275375065067605 320467556775450 023436261315455 011306014006753 403112324146646 175070523075164 557244007157744 425536470274352 332415164131435 115125573101442 745565447177770 545201523517642 416662075710077 001223562356301 231171774154712 461726216545424 416106151774201 651063200446176 135471662402411 424412532245563 115451424762236 647021720005536 526122475115504[/color]
245147261210474 110355324013261 471071077552457 243201117615642 610621436346764 640170271720054 525337367306022 203674555216357 653675736157531 236151625103600 640302611364212 474263063442224 321677233017736 071340646247534 536645354770361 405340770217451 441530701353725 673225577676034 024065113165756 376675063056177 024303522225056 407015430715065 670415500366164 627720133246523 045641760343566 266442731667313 365016666076430 236732103100735 453566475641705 242516630662601 345037070127506 753760326567356 031232252607702 215722340421132 3
047413633213326 054

--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson

**infobahn** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

Ron Peterson wrote:[color=blue]
>
> In the following piece of code, which simply generates a sequence of
> (random) octal codes, I'm surprised by the apparent non-randomness of
> /dev/random. It's not noticeable unless RAND_LENGTH is largish. I was
> under the assumption that /dev/random was "more random" than
> /dev/urandom, and that it would block if it ran out of entropy until it
> got more. Why am I seeing so many zeroes in my output?
>
> #include <stdio.h>
> #include <fcntl.h>
> #define RAND_LEN 1024
>
> void
> read_random( const char* dev ) {
> int i, fd;
> char dat[RAND_LEN];
>
> fd = open( dev, O_RDONLY );
>
> dat[RAND_LEN] = '\0';[/color]

This assignment violates dat's bounds, invoking undefined behaviour.
So all bets are off.

Make it char dat[RAND_LEN + 1];
[color=blue]
>
> if( fd != -1 ) {
> read( fd, dat, RAND_LEN );
> for( i = 0; i < RAND_LEN; i++ ) {
> dat[i] = (dat[i] >> 4 & 0x07) + 48;[/color]

Again, undefined behaviour. This time it's because you're reading
an indeterminate value, dat[i].
[color=blue]
> }
> printf( "%s: %s\n\n", dev, dat );
> } else {
> exit( 1 );
> }
>
> close( fd );
> }
>
> int
> main( void ) {
> read_random( "/dev/random" );
> read_random( "/dev/urandom" );[/color]

Leaving those bugs unfixed, does swapping these two calls
reverse the behaviour? That is, if you do this instead:

read_random( "/dev/urandom" );
read_random( "/dev/random" );

are the excess 0s now associated with /dev/urandom instead?

If so, you can be reasonably sure that the problem lies with
the problems I've mentioned.

**Ron Peterson** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

I was copying bits and pieces from other code, and made a couple of
errors. I should have typed:

char dat[RAND_LEN + 1]; (so I'm not going beyond end of array)

and

dat[i] = (dat[i] & 0x07) + '0'; (I don't need to bit shift, I just want
three bits).

Anyway, when I do these things, I still get long strings of zeroes from
/dev/random. ?

Not exactly a C question, I know. I could direct this to the kernel
list, as the kernel provides random and urandom, but I was thinking the
behaviour should be consistent between kernels, so it's not really a
kernel question. If someone can suggest a more appropriate list, that's
helpful too.

BTW, I'm using linux 2.6.x. If anyone running a BSD variant could
compile this and compare the results, that might be interesting.

-Ron-

On 7 Jan 2005 09:33:44 -0500, Ron Peterson <rpeterso@mthol yoke.edu> wrote:[color=blue]
> In the following piece of code, which simply generates a sequence of
> (random) octal codes, I'm surprised by the apparent non-randomness of
> /dev/random. It's not noticeable unless RAND_LENGTH is largish. I was
> under the assumption that /dev/random was "more random" than
> /dev/urandom, and that it would block if it ran out of entropy until it
> got more. Why am I seeing so many zeroes in my output?
>
> #include <stdio.h>
> #include <fcntl.h>
> #define RAND_LEN 1024
>
> void
> read_random( const char* dev ) {
> int i, fd;
> char dat[RAND_LEN];
>
> fd = open( dev, O_RDONLY );
>
> dat[RAND_LEN] = '\0';
>
> if( fd != -1 ) {
> read( fd, dat, RAND_LEN );
> for( i = 0; i < RAND_LEN; i++ ) {
> dat[i] = (dat[i] >> 4 & 0x07) + 48;
> }
> printf( "%s: %s\n\n", dev, dat );
> } else {
> exit( 1 );
> }
>
> close( fd );
> }
>
> int
> main( void ) {
> read_random( "/dev/random" );
> read_random( "/dev/urandom" );
> return( 0 );
> }
>
> 506$ ./test
>
> /dev/random: 200050617063526 437602510346655 072474031767426 306605046222320 604001730615000 243427435070303 503367456120754 173510400040000 000050000000000 007737204577300 001773560405044 500220434040000 340417736104640 464040000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000640423461 000000000000000 000000000000000 000000000000024 040000000041007 000000063461000 000000000000000 000000000000000 000000000000000 000000000000000 000000005604000 000000000340437 730400377305043 000000047730000 000000000000000 000000000300010 000000000000000 000000000000000 000000000000000 000000000000000 000000000450045 004000000002000 700413043304070 400001704340417 040504277307040 504003016045773 240400006704000 000000000000000 007004200064040 000340400006404 677300045004000 000005773200070 041304330407040 000170434046404 400047730704400 007700000777324 040000570400000 000000000000000 000000003404710 007047773220417 046704000000000 000777300000000 000000000770077 354040504160463 040704577337730 204700020004004 477357731104641 464143773650464 145773340400005 404177322046404 5704
>
> /dev/urandom: 103137002760751 330471453227547 317447153305403 055445577241174 112554437473707 174466515247147 230165510321673 032612147044376 361336471103425 426601777564215 275375065067605 320467556775450 023436261315455 011306014006753 403112324146646 175070523075164 557244007157744 425536470274352 332415164131435 115125573101442 745565447177770 545201523517642 416662075710077 001223562356301 231171774154712 461726216545424 416106151774201 651063200446176 135471662402411 424412532245563 115451424762236 647021720005536 526122475115504 245147261210474 110355324013261 471071077552457 243201117615642 610621436346764 640170271720054 525337367306022 203674555216357 653675736157531 236151625103600 640302611364212 474263063442224 321677233017736 071340646247534 536645354770361 405340770217451 441530701353725 673225577676034 024065113165756 376675063056177 024303522225056 407015430715065 670415500366164 627720133246523 045641760343566 266442731667313 365016666076430 236732103100735 453566475641705 242516630662601 345037070127506 753760326567356 031232252607702 215722340421132 304741363321332 6054
>[/color]

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College

**Jens.Toerring@physik.fu-berlin.de** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

Ron Peterson <rpeterso@mthol yoke.edu> wrote:[color=blue]
> I was copying bits and pieces from other code, and made a couple of
> errors. I should have typed:[/color]
[color=blue]
> char dat[RAND_LEN + 1]; (so I'm not going beyond end of array)[/color]
[color=blue]
> and[/color]
[color=blue]
> dat[i] = (dat[i] & 0x07) + '0'; (I don't need to bit shift, I just want
> three bits).[/color]
[color=blue]
> Anyway, when I do these things, I still get long strings of zeroes from
> /dev/random. ?[/color]
[color=blue]
> Not exactly a C question, I know. I could direct this to the kernel
> list, as the kernel provides random and urandom, but I was thinking the
> behaviour should be consistent between kernels, so it's not really a
> kernel question. If someone can suggest a more appropriate list, that's
> helpful too.[/color]

Joona set the follow-up to comp.unix.progr ammer where it's more
on-topic and where I tried to answer the question...

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

**Christopher Benson-Manica** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

infobahn <infobahn@btint ernet.com> spoke thus:
[color=blue][color=green]
> > if( fd != -1 ) {
> > read( fd, dat, RAND_LEN );
> > for( i = 0; i < RAND_LEN; i++ ) {
> > dat[i] = (dat[i] >> 4 & 0x07) + 48;[/color][/color]
[color=blue]
> Again, undefined behaviour. This time it's because you're reading
> an indeterminate value, dat[i].[/color]

It isn't necessarily undefined behavior, if RAND_LEN bytes happen to
have been read. Unless I'm missing something, the code could be
corrected with

if( fd != EOF ) { /* right? */
int bytes=read( fd, dat, RAND_LEN );
if( bytes == -1 ) {
/* error */
}
if( bytes ) { /* bytes == 0 implies end of file */
for( i=0; i < bytes; i++ ) {
/* ... */
}
}
/* ... */
}

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

**infobahn** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

Ron Peterson wrote:[color=blue]
>
> I was copying bits and pieces from other code, and made a couple of
> errors. I should have typed:[/color]

Oh dear. We'd prefer to debug your program errors, not your
typographical errors. :-(
[color=blue]
>
> char dat[RAND_LEN + 1]; (so I'm not going beyond end of array)[/color]

Fair enough.
[color=blue]
>
> and
>
> dat[i] = (dat[i] & 0x07) + '0'; (I don't need to bit shift, I just want
> three bits).[/color]

This is still broken. Please refer to my earlier reply.

**Chris Croughton** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

On 7 Jan 2005 09:33:44 -0500, Ron Peterson
<rpeterso@mthol yoke.edu> wrote:
[color=blue]
> In the following piece of code, which simply generates a sequence of
> (random) octal codes, I'm surprised by the apparent non-randomness of
> /dev/random. It's not noticeable unless RAND_LENGTH is largish. I was
> under the assumption that /dev/random was "more random" than
> /dev/urandom, and that it would block if it ran out of entropy until it
> got more. Why am I seeing so many zeroes in my output?[/color]

For a start, your question is not really C related, it could happen in
any language. Not only is /dev/random device specific but you are also
using POSIX I/O functions (open/read etc.) rather than the C ones.
[color=blue]
> read( fd, dat, RAND_LEN );[/color]

What is the length read? It is quite possible that read() is returning
when it gets the first byte or few bytes, and the rest of the array is
undefined.
[color=blue]
> for( i = 0; i < RAND_LEN; i++ ) {[/color]

You are assuming that you know that the whole array was filled. I
suggest that it wasn't.

(I have a reason for suggesting this. I used dd(1) to read a block from
/dev/random into a file. The first time it got 1024 bytes. The next
time it got two, the one after around 30. I'd be pretty sure that dd(1)
is using the same mechanism to read data. That was on Linux kernel
2.2.19...)

Which does make it a sort-of C question, because if you used the C I/O
(fopen, fread etc.) you might find different behaviour. Or perhaps
not...

Chris C

**infobahn** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

Christopher Benson-Manica wrote:[color=blue]
>
> infobahn <infobahn@btint ernet.com> spoke thus:
>[color=green][color=darkred]
> > > if( fd != -1 ) {
> > > read( fd, dat, RAND_LEN );
> > > for( i = 0; i < RAND_LEN; i++ ) {
> > > dat[i] = (dat[i] >> 4 & 0x07) + 48;[/color][/color]
>[color=green]
> > Again, undefined behaviour. This time it's because you're reading
> > an indeterminate value, dat[i].[/color]
>
> It isn't necessarily undefined behavior, if RAND_LEN bytes happen to
> have been read.[/color]

My apologies to the OP. I didn't spot the read()! (Duh...)

In that case, I am not sure that anything remains for comp.lang.c
to contribute here. Perhaps comp.unix.progr ammer could help.

**Ron Peterson** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

On 7 Jan 2005 11:46:47 -0500, Ron Peterson <rpeterso@mthol yoke.edu> wrote:
[color=blue]
> Anyway, when I do these things, I still get long strings of zeroes from
> /dev/random. ?
>
> Not exactly a C question, I know. I could direct this to the kernel
> list, as the kernel provides random and urandom, but I was thinking the
> behaviour should be consistent between kernels, so it's not really a
> kernel question.[/color]

Pencils down. The LKML list pinned it down for me.

It was in fact a C programming error. I wasn't checking the return
value of 'read', to see how much data was actually read.

Best.

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College

**Christopher Benson-Manica** · Nov 14 '05, 05:16 PM

Re: /dev/urandom vs. /dev/random

Ron Peterson <rpeterso@mthol yoke.edu> spoke thus:
[color=blue]
> Pencils down. The LKML list pinned it down for me.[/color]
[color=blue]
> It was in fact a C programming error. I wasn't checking the return
> value of 'read', to see how much data was actually read.[/color]

Not to boast, but note my response elsethread :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

**Michael Wojcik** · Nov 14 '05, 05:19 PM

Re: /dev/urandom vs. /dev/random

In article <41def70b$1@nap .mtholyoke.edu> , Ron Peterson <rpeterso@mthol yoke.edu> writes:[color=blue]
>
> It was in fact a C programming error. I wasn't checking the return
> value of 'read', to see how much data was actually read.[/color]

This is a POSIX programming error, not a C programming error. You
could make precisely the same mistake with any language capable of
making system calls on a POSIX system. read is not a C function;
it's a POSIX function.

And that is precisely why this question was OT for comp.lang.c, and
topical for comp.unix.progr ammer.

--
Michael Wojcik michael.wojcik@ microfocus.com

Painful lark, labouring to rise!
The solemn mallet says:
In the grave's slot
he lies. We rot. -- Basil Bunting

**Michael Wojcik** · Nov 14 '05, 05:19 PM

Re: /dev/urandom vs. /dev/random

In article <crmgo0$mtr$1@c hessie.cirr.com >, Christopher Benson-Manica <ataru@nospam.c yberspace.org> writes:[color=blue]
>
> if( fd != EOF ) { /* right? */[/color]

Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.

fd is the return value from the POSIX open function. open returns
a file descriptor, which is a non-negative integer, or -1 on failure.
Since EOF may not be -1, that's not the appropriate value to compare
it to.
[color=blue]
> int bytes=read( fd, dat, RAND_LEN );
> if( bytes == -1 ) {
> /* error */
> }
> if( bytes ) { /* bytes == 0 implies end of file */
> for( i=0; i < bytes; i++ ) {
> /* ... */
> }
> }[/color]

This does fix part of the error in the OP's code (it appears that
he expects the read_random function to populate the entire buffer,
so it really needs to loop around calls to read until it's done so),
but note that the test "if( bytes )" is extraneous, since the for
loop does nothing if bytes == 0.

--
Michael Wojcik michael.wojcik@ microfocus.com

Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".

**Christopher Benson-Manica** · Nov 14 '05, 05:21 PM

Re: /dev/urandom vs. /dev/random

Michael Wojcik <mwojcik@newsgu y.com> spoke thus:
[color=blue]
> Wrong, I'm afraid, and yet another example of why we shouldn't try
> to answer off-topic questions here.[/color]

Well, it wasn't totally off-topic, since we agree that OP failed to
use the standard read() function correctly.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

**Martin Ambuhl** · Nov 14 '05, 05:21 PM

Re: /dev/urandom vs. /dev/random

Christopher Benson-Manica wrote:[color=blue]
> Michael Wojcik <mwojcik@newsgu y.com> spoke thus:
>
>[color=green]
>>Wrong, I'm afraid, and yet another example of why we shouldn't try
>>to answer off-topic questions here.[/color]
>
>
> Well, it wasn't totally off-topic, since we agree that OP failed to
> use the standard read() function correctly.
>[/color]

There is no standard function in C called "read". If you are referring
to the POSIX function called "read", then you know that it is topical in
newsgroups addressing POSIX issues and off-topic in newsgroups
addressing C issues. Your "reason" for the question's not being
"totally off-topic" is completely bogus.

/dev/urandom vs. /dev/random

/dev/urandom vs. /dev/random

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment