What would writing to /dev/urandom do?

[Allen Kistler]

I'm using stunnel to wrap some traffic. It's default initialization
reads the contents of a file (.rnd) and writes back to it after
initialization.

I plan on changing the source of randomness to /dev/urandom.

I can configure stunnel *not* to write back to the source (i.e.,
urandom), but I was wondering what happens if I allow it.

1. Nothing. The bytes are discarded.
2. The written bytes stir the entropy pool.
3. Something else that hasn't popped into my head yet.

[John Reiser]

2. The written bytes [to /dev/urandom] stir the entropy pool.

The maintainer of /dev/random, and also other contributors,
claim that this only increases the randomness that can be obtained
from subsequent reads, but they have not exhibited a proof.
Regardless of whether you believe that claim, being able
to stir the entropy pool with chosen data is certainly
the front door through which anybody with a "crack"
(a [partially] successful attack) will choose to enter.

--

[Allen Kistler]

Post by John Reiser

2. The written bytes [to /dev/urandom] stir the entropy pool.

The maintainer of /dev/random, and also other contributors,
claim that this only increases the randomness that can be obtained
from subsequent reads, but they have not exhibited a proof.
Regardless of whether you believe that claim, being able
to stir the entropy pool with chosen data is certainly
the front door through which anybody with a "crack"
(a [partially] successful attack) will choose to enter.

I'm not an expert on all of what random and urandom do to calculate
randomness. I would hope they would be resilient to someone dumping a
bunch of known data into their initialization source, even if it's an
overwhelming amount of data.

But the point is taken. It's probably better not to allow the writes in
the first place, although that's an issue with the F11 configuration of
random/urandom rather than with stunnel.

[Maxwell Lol]

Post by John Reiser

2. The written bytes [to /dev/urandom] stir the entropy pool.

The maintainer of /dev/random, and also other contributors,
claim that this only increases the randomness that can be obtained
from subsequent reads, but they have not exhibited a proof.
Regardless of whether you believe that claim, being able
to stir the entropy pool with chosen data is certainly
the front door through which anybody with a "crack"
(a [partially] successful attack) will choose to enter.
--

Example - writing a trillion zeros.....

[Andrew Halliwell]

Post by Allen Kistler
I'm using stunnel to wrap some traffic. It's default initialization
reads the contents of a file (.rnd) and writes back to it after
initialization.
I plan on changing the source of randomness to /dev/urandom.
I can configure stunnel *not* to write back to the source (i.e.,
urandom), but I was wondering what happens if I allow it.
1. Nothing. The bytes are discarded.
2. The written bytes stir the entropy pool.
3. Something else that hasn't popped into my head yet.

I think it'd most likely be the equivalent of writing to /dev/null.
Nothing, just discarded bytes.
urandom gets its random seed from /dev/random, so I doubt writing to urandom
would "stir the entropy pool".

[Unruh]

Post by Andrew Halliwell

Post by Allen Kistler
I'm using stunnel to wrap some traffic. It's default initialization
reads the contents of a file (.rnd) and writes back to it after
initialization.
I plan on changing the source of randomness to /dev/urandom.
I can configure stunnel *not* to write back to the source (i.e.,
urandom), but I was wondering what happens if I allow it.
1. Nothing. The bytes are discarded.
2. The written bytes stir the entropy pool.
3. Something else that hasn't popped into my head yet.

I think it'd most likely be the equivalent of writing to /dev/null.
Nothing, just discarded bytes.
urandom gets its random seed from /dev/random, so I doubt writing to urandom
would "stir the entropy pool".

It gets its randomness from a process similar to /dev/random, but not from
/dev/random itself. It also tries to save some randomness from previous sessions

[Jean-David Beyer]

Post by Allen Kistler
I'm using stunnel to wrap some traffic. It's default initialization
reads the contents of a file (.rnd) and writes back to it after
initialization.
I plan on changing the source of randomness to /dev/urandom.
I can configure stunnel *not* to write back to the source (i.e.,
urandom), but I was wondering what happens if I allow it.
1. Nothing. The bytes are discarded.
2. The written bytes stir the entropy pool.
3. Something else that hasn't popped into my head yet.

On my machine, running Red Hat Enterprise Linux 5, /dev/urandom file is
read-only by all users. So you would get an error return from the write()
command, or perhaps even the open().

Having played with random number generators in the past, setting the
starting value can be useful for certain applications (certain types of
hashing), setting it to get "more random" numbers does not really help.

There was a thought, once, that having an error in a random number
generation program gave more random numbers. That is plainly incorrect.

[Allen Kistler]

Post by Jean-David Beyer

Post by Allen Kistler
I'm using stunnel to wrap some traffic. It's default initialization
reads the contents of a file (.rnd) and writes back to it after
initialization.
I plan on changing the source of randomness to /dev/urandom.
I can configure stunnel *not* to write back to the source (i.e.,
urandom), but I was wondering what happens if I allow it.
1. Nothing. The bytes are discarded.
2. The written bytes stir the entropy pool.
3. Something else that hasn't popped into my head yet.

On my machine, running Red Hat Enterprise Linux 5, /dev/urandom file is
read-only by all users. So you would get an error return from the
write() command, or perhaps even the open().

On EL5 it is read-only, but on F11 it is read-write by everybody. (I
run stunnel as "nobody.") I didn't bother to check EL5 before, but the
difference to F11 is interesting.

Post by Jean-David Beyer
Having played with random number generators in the past, setting the
starting value can be useful for certain applications (certain types of
hashing), setting it to get "more random" numbers does not really help.
There was a thought, once, that having an error in a random number
generation program gave more random numbers. That is plainly incorrect.

I think I'm inclined not to write back to urandom, basically because now
I'm thinking of changing the perms on it to read-only.

[Rahul]

Post by Jean-David Beyer
Having played with random number generators in the past, setting the
starting value can be useful for certain applications (certain types of
hashing), setting it to get "more random" numbers does not really help.
There was a thought, once, that having an error in a random number
generation program gave more random numbers. That is plainly incorrect.

Don't some of the latest Intel chips come with an on-board random number
generator. I remember this being hardware based (rather than the pseudo
random ones conventionally employed). I believe the idea was amplyfing
minor temperature fluctations from a chip sensor which would mimic a true
random process.

Is this ever used these days? Just curious.

[Jean-David Beyer]

Post by Rahul

Post by Jean-David Beyer
Having played with random number generators in the past, setting the
starting value can be useful for certain applications (certain types of
hashing), setting it to get "more random" numbers does not really help.
There was a thought, once, that having an error in a random number
generation program gave more random numbers. That is plainly incorrect.

Don't some of the latest Intel chips come with an on-board random number
generator. I remember this being hardware based (rather than the pseudo
random ones conventionally employed). I believe the idea was amplyfing
minor temperature fluctations from a chip sensor which would mimic a true
random process.
Is this ever used these days? Just curious.

Yes.

Here is one commercial product:

http://comscire.com/Home/

Just do a search on "hardware random number generator"

[Rahul]

Post by Jean-David Beyer
Yes.
http://comscire.com/Home/
Just do a search on "hardware random number generator"

I was just reading up on /dev/random. Why does this in linux distros not
make use of the on-chip thermal randomness? Shouldn't that be "more
random" [sic] than banking on the entropy of interfaces?

[John Hasler]

Post by Rahul
I was just reading up on /dev/random. Why does this in linux distros not
make use of the on-chip thermal randomness? Shouldn't that be "more
random" [sic] than banking on the entropy of interfaces?

thumper/~ ls /usr/src/linux-source-2.6.26/drivers/char/hw_random
amd-rng.c amd-rng.o geode-rng.c intel-rng.mod.o Makefile rng-core.o
amd-rng.ko built-in.o intel-rng.c intel-rng.o modules.order via-rng.c
amd-rng.mod.c core.c intel-rng.ko ixp4xx-rng.c omap-rng.c virtio-rng.c
amd-rng.mod.o core.o intel-rng.mod.c Kconfig pasemi-rng.c

thumper/~ apt-cache show rng-tools
Package: rng-tools
Priority: optional
Section: utils
Installed-Size: 208
Maintainer: Henrique de Moraes Holschuh <***@debian.org>
Architecture: amd64
Version: 2-unofficial-mt.12-1
Replaces: intel-rng-tools
Provides: intel-rng-tools
Depends: libc6 (>= 2.7-1), makedev (>= 2.3.1-77) | udev (>= 0.053)
Conflicts: intel-rng-tools
Filename: pool/main/r/rng-tools/rng-tools_2-unofficial-mt.12-1_amd64.deb
Size: 42986
MD5sum: 94c3694ff20796f8c4f2d083e1c29fa7
SHA1: e466109152b54d6ebc51e322a6114657a3b1a3b2
SHA256: 7cd96b57556b4b7d8d5c0ded7423b67712d5f3738795d2911cb3f9e6a06122d2
Description: Daemon to use a Hardware TRNG
The rngd daemon acts as a bridge between a Hardware TRNG (true random number
generator) such as the ones in some Intel/AMD/VIA chipsets, and the kernel's
PRNG (pseudo-random number generator).
.
It tests the data received from the TRNG using the FIPS 140-2 (2002-10-10)
tests to verify that it is indeed random, and feeds the random data to the
kernel entropy pool.
.
This increases the bandwidth of the /dev/random device, from a source that
does not depend on outside activity. It may also improve the quality
(entropy) of the randomness of /dev/random.
.
A TRNG kernel module such as hw_random, or some other source of true
entropy that is accessible as a device or fifo, is required to use this
package.
.
This is an unofficial version of rng-tools which has been extensively
modified to add multithreading and a lot of new functionality.
Tag: interface::daemon, network::server, role::program


Of course, to use these you must trust the chip manufacturers...

[Jean-David Beyer]

Post by Rahul

Post by Jean-David Beyer
Yes.
http://comscire.com/Home/
Just do a search on "hardware random number generator"

I was just reading up on /dev/random. Why does this in linux distros not
make use of the on-chip thermal randomness? Shouldn't that be "more
random" [sic] than banking on the entropy of interfaces?

There are cases where a pseudo-random number generator is better than a real
one. One example that actually came up for me is making a superimposed
codeword index for a database. You take the keys and hash them by using a
pseudo-random number generator. You want to be certain that whenever that
key is presented, you get the same sequence of random bits. A true random
number generator would be useless in such an application, but a good
pseudo-random one works just fine (it needs to have pretty uniform
distribution so the basic 16-bit pseudo-random ones are not good enough; in
fact, in our application, a 32-bit one was not very good either, but a
48-bit one was just fine).

[Rahul]

Post by Jean-David Beyer
There are cases where a pseudo-random number generator is better than
a real one.

For sure. I am not advocating getting rid of pseudo random generators. But
I have a hunch that more apps out there care for "real" random numbers than
pseudo. Which is why I felt a "real" random number was a better choice for
/dev/random.

Of course, for pseudo-random numbers any fairly decent math library has a
good generator in it.

[John Hasler]

Post by Rahul
For sure. I am not advocating getting rid of pseudo random
generators. But I have a hunch that more apps out there care for "real"
random numbers than pseudo. Which is why I felt a "real" random number
was a better choice for /dev/random.

/dev/random harvests entropy from the mouse, keyboard, NIC, etc. which it
uses to seed a PRNG. It produces numbers which are effectively quite
random. As I noted previously there is a driver for the Intel source.

[The Natural Philosopher]

Post by John Hasler

Post by Rahul
For sure. I am not advocating getting rid of pseudo random
generators. But I have a hunch that more apps out there care for "real"
random numbers than pseudo. Which is why I felt a "real" random number
was a better choice for /dev/random.

/dev/random harvests entropy from the mouse, keyboard, NIC, etc. which it
uses to seed a PRNG. It produces numbers which are effectively quite
random. As I noted previously there is a driver for the Intel source.

I did something similar once. I hit the hard disk raw sectors and
selected bytes modulo something the RTC I think.....It probably wasnt
very random, but it looked good enough. (random light display as it
happened'

The real question is what you want the random for..These days what about
sampling audio for white noise?

[Art Werschulz]

Hi.

Post by The Natural Philosopher
The real question is what you want the random for.

That's the main issue here.

For example, the Monte Carlo method is often used for approximating
integrals over (say) the $d$-dimensional unit cube. The idea is that
you evaluate your integrand (say, $f$) at $n$ randomly-chosen points
$x_1,x_2,\dots,x_n\in [0,1]^d$,, and then approximate
$$\int_{[0,1]^d} f(x)\,dx \approx n^{-1} \sum_{i=1}^n f(x_i).$$
Assuming that the points are randomly chosen, then the randomized error
is proportional to $n^{-1/2}$, the proportionality factor being the
variance of~$f$.

So what happens when you don't have a truly random source, but only a
pseudorandom number generator?

For the answer, see ...

@article {MR1106984,
AUTHOR = {Traub, J. F. and Wo{\'z}niakowski, H.},
TITLE = {The {M}onte {C}arlo algorithm with a pseudorandom
generator},
JOURNAL = {Math. Comp.},
FJOURNAL = {Mathematics of Computation},
VOLUME = {58},
YEAR = {1992},
NUMBER = {197},
PAGES = {323--339},
ISSN = {0025-5718},
CODEN = {MCMPAF},
MRCLASS = {65C05 (65C10)},
MRNUMBER = {MR1106984 (92e:65007)},
MRREVIEWER = {J. Spanier},
}

You can also find this at
http://en.scientificcommons.org/42930658

[Maxwell Lol]

Post by Rahul
For sure. I am not advocating getting rid of pseudo random generators. But
I have a hunch that more apps out there care for "real" random numbers than
pseudo. Which is why I felt a "real" random number was a better choice for
/dev/random.

It may also depend how much data is needed, and how long an
applicaiton can wait.

A video game that runs out of random numbers would pause.

[Rahul]

Post by Maxwell Lol
It may also depend how much data is needed, and how long an
applicaiton can wait.
A video game that runs out of random numbers would pause.

I think the best way is a compromise. Perhaps a pseudo-random number
frequently reseeded by a randomizer whenever sufficient entropy is
available.

[Allen Kistler]

Post by Rahul
I think the best way is a compromise. Perhaps a pseudo-random number
frequently reseeded by a randomizer whenever sufficient entropy is
available.

Isn't that what urandom does? urandom takes seeds from random, if
available, but otherwise runs unblocked.

[John Hasler]

Post by Rahul
I think the best way is a compromise. Perhaps a pseudo-random number
frequently reseeded by a randomizer whenever sufficient entropy is
available.

That is called "/dev/urandom".

[Jean-David Beyer]

Post by Rahul

Post by Jean-David Beyer
There are cases where a pseudo-random number generator is better than
a real one.

For sure. I am not advocating getting rid of pseudo random generators. But
I have a hunch that more apps out there care for "real" random numbers than
pseudo. Which is why I felt a "real" random number was a better choice for
/dev/random.
Of course, for pseudo-random numbers any fairly decent math library has a
good generator in it.

I am not sure of that. When I was doing random number work, the one that
came with UNIX was just awful. It was a multiplicative congruential type
(which can be very good if carefully programmed; see

http://portal.acm.org/citation.cfm?id=321379

), but it ran with only 15 or 16 bits, so the period was very small. About
that time the _long_ data type was added to the _C_ language, so it was
re-written in long (32 bits or so) and that helped some, but for my
purposes, I needed even better statistics, so I wrote one in triple
precision (48 bits). Later, a friend converted my program to make it more
portable (mine was written in assembler) and he fixed a bug that was in my
program that stole a bit or two from the calculation. It was called drand48
and lrand48. I do not know what you get these days in libraries, but the
drand48 family is still around.

[John Hasler]

I do not know what you get these days in libraries, but the drand48
family is still around.

thumper/~ apropos "random number"
drand48 (3) - generate uniformly distributed pseudo-random numbers
drand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
erand48 (3) - generate uniformly distributed pseudo-random numbers
erand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
initstate (3) - random number generator
initstate_r (3) - reentrant random number generator
jrand48 (3) - generate uniformly distributed pseudo-random numbers
jrand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
lcong48 (3) - generate uniformly distributed pseudo-random numbers
lcong48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
lrand48 (3) - generate uniformly distributed pseudo-random numbers
lrand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
mrand48 (3) - generate uniformly distributed pseudo-random numbers
mrand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
nrand48 (3) - generate uniformly distributed pseudo-random numbers
nrand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
rand (1ssl) - generate pseudo-random bytes
rand (3) - pseudo-random number generator
rand_r (3) - pseudo-random number generator
random (3) - random number generator
random (4) - kernel random number source devices
random_r (3) - reentrant random number generator
seed48 (3) - generate uniformly distributed pseudo-random numbers
seed48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
setstate (3) - random number generator
setstate_r (3) - reentrant random number generator
shuf (1) - generate random permutations
signify (1) - Program to generate semi-random signatures
srand (3) - pseudo-random number generator
srand48 (3) - generate uniformly distributed pseudo-random numbers
srand48_r (3) - generate uniformly distributed pseudo-random numbers reentrantly
srandom (3) - random number generator
srandom_r (3) - reentrant random number generator

[Unruh]

Post by Rahul

Post by Jean-David Beyer
Yes.
http://comscire.com/Home/
Just do a search on "hardware random number generator"

I was just reading up on /dev/random. Why does this in linux distros not
make use of the on-chip thermal randomness? Shouldn't that be "more
random" [sic] than banking on the entropy of interfaces?

Not all chipsets have them. Linux needs to run on all. I think but am not suer
that /dev/random can use the hardware generator if the chipset has one.

Post by Rahul
--
Rahul

[Rahul]

Post by Unruh
Not all chipsets have them. Linux needs to run on all. I think but am
not suer that /dev/random can use the hardware generator if the
chipset has one.

That is true Unruh. But just like you say I was wondering if it does use
the hardware option when it exists (isn't that philosophy pretty standard.
e.g. "if a piece of HW exists then use it; if not then have a fallback
option").

In fact I'm quite curious to see how my /dev/random is wired and if my
chipset supports a hardware random number generator or not.

I just tried cat /dev/random but no output at all. How does one use
/dev/random anyways?

[Maxwell Lol]

Post by Rahul
I just tried cat /dev/random but no output at all. How does one use

I'm guessing that "cat" from a file to a terminal normally reads until
it gets a newline character. That's a 1 in 256 (or 1 in 128 ignoring
parity). chance.


But /dev/random won't output unless the data is truly random
(sufficient entropy).

I used

dd bs=1 count=10</dev/random|od -x

to get 10 bytes. I did it a second time, and it paused - waiting for
more entropy.

Of course the more you use it, the more entropy you use up.
YMMV.

[jellybean stonerfish]

Post by Maxwell Lol

Post by Rahul
I just tried cat /dev/random but no output at all. How does one use

I'm guessing that "cat" from a file to a terminal normally reads until
it gets a newline character. That's a 1 in 256 (or 1 in 128 ignoring
parity). chance.

If you try it, you will see that "cat" will output the complete file,
including newline characters. I believe it stops when it reaches EOF.

[Unruh]

Post by jellybean stonerfish

Post by Maxwell Lol

Post by Rahul
I just tried cat /dev/random but no output at all. How does one use

You exhausted the /dev/random pool and the system is hung waiting for
more random input.

Post by jellybean stonerfish

Post by Maxwell Lol
I'm guessing that "cat" from a file to a terminal normally reads until
it gets a newline character. That's a 1 in 256 (or 1 in 128 ignoring
parity). chance.

If you try it, you will see that "cat" will output the complete file,
including newline characters. I believe it stops when it reaches EOF.

For /dev/random it never stops. It simply blocks.

[jellybean stonerfish]

Post by Rahul
In fact I'm quite curious to see how my /dev/random is wired and if my
chipset supports a hardware random number generator or not.
I just tried cat /dev/random but no output at all. How does one use
/dev/random anyways?

"cat /dev/random" should work. By "work" I mean it outputs random
characters. Maybe you don't have read permission for /dev/random, or you
don't have enough entropy in the pool.

From "man 4 random"
When the entropy pool is empty, reads from /dev/random will
block until additional environmental noise is gathered.

Try "cat /dev/random" again. In another terminal, access your harddrive
and see if the terminal running "cat /dev/random" starts to output
gibberish.

[Robert Riches]

Post by jellybean stonerfish

Post by Rahul
In fact I'm quite curious to see how my /dev/random is wired and if my
chipset supports a hardware random number generator or not.
I just tried cat /dev/random but no output at all. How does one use
/dev/random anyways?

"cat /dev/random" should work. By "work" I mean it outputs random
characters. Maybe you don't have read permission for /dev/random, or you
don't have enough entropy in the pool.
From "man 4 random"
When the entropy pool is empty, reads from /dev/random will
block until additional environmental noise is gathered.
Try "cat /dev/random" again. In another terminal, access your harddrive
and see if the terminal running "cat /dev/random" starts to output
gibberish.

At least with older kernels, simply moving the mouse around could
refill the entropy pool. There was one kernel when I still used
my Alpha machine that required moving the mouse around sometimes
to get X started.

[Rahul]

Post by Robert Riches
At least with older kernels, simply moving the mouse around could
refill the entropy pool. There was one kernel when I still used
my Alpha machine that required moving the mouse around sometimes
to get X started.

No mouse attached locally. No keyboard either. THis is a server with only
remote logins via ssh mostly.

[Robert Riches]

Post by Rahul

Post by Robert Riches
At least with older kernels, simply moving the mouse around could
refill the entropy pool. There was one kernel when I still used
my Alpha machine that required moving the mouse around sometimes
to get X started.

No mouse attached locally. No keyboard either. THis is a server with only
remote logins via ssh mostly.

If you're needing a way to refill the entropy pool, two options
come to mind. 1) If network traffic puts bits in the pool, send
some packets to the server. 2) If you can detect when the pool
is empty, have a background job do a bunch of disk I/O. I'm
pretty sure disk I/O does put bits in the pool.

[Rahul]

Post by Robert Riches
come to mind. 1) If network traffic puts bits in the pool, send
some packets to the server.

There is lots of network traffic to the server constantly. There are cron
processes for updating websites. It is also a nfs export for 800 gigs of
data.

2) If you can detect when the pool

Post by Robert Riches
is empty, have a background job do a bunch of disk I/O. I'm
pretty sure disk I/O does put bits in the pool.

In a typical day 10 - 12 users have ssh sessions open. That must do a lot
of read/writes.

[John Hasler]

Post by Rahul
No mouse attached locally. No keyboard either. THis is a server with only
remote logins via ssh mostly.

Then you cannot reliably use /dev/random.

[jellybean stonerfish]

Post by Rahul

Post by Robert Riches
At least with older kernels, simply moving the mouse around could
refill the entropy pool. There was one kernel when I still used my
Alpha machine that required moving the mouse around sometimes to get X
started.

No mouse attached locally. No keyboard either. THis is a server with
only remote logins via ssh mostly.

Does reading/writing to your harddrive increase your entropy?

[Robert Riches]

Post by jellybean stonerfish

Post by Rahul

Post by Robert Riches
At least with older kernels, simply moving the mouse around could
refill the entropy pool. There was one kernel when I still used my
Alpha machine that required moving the mouse around sometimes to get X
started.

No mouse attached locally. No keyboard either. THis is a server with
only remote logins via ssh mostly.

Does reading/writing to your harddrive increase your entropy?

(I'm not the OP...)

At least with that older Alpha kernel, disk I/O _DID_ fill the
entropy pool. I put code in the X startup script to do a bunch
of disk I/O if the X server didn't come up promptly.

[Rahul]

Post by Robert Riches
(I'm not the OP...)
At least with that older Alpha kernel, disk I/O _DID_ fill the
entropy pool. I put code in the X startup script to do a bunch
of disk I/O if the X server didn't come up promptly.

I am the OP :) ......no, I don't think the HDD R/W increased my entropy. At
least if I did things correctly.

[Allen Kistler]

Post by Rahul

Post by Robert Riches
(I'm not the OP...)
At least with that older Alpha kernel, disk I/O _DID_ fill the
entropy pool. I put code in the X startup script to do a bunch
of disk I/O if the X server didn't come up promptly.

I am the OP :) ......no, I don't think the HDD R/W increased my entropy. At
least if I did things correctly.

New definition of O? Not that it matters. This chain no longer has
anything at all to do with the original post. (Not a complaint. Just
an observation.)

The challenge of attempting to figure out empirically what increases
entropy is that entropy increases even when the machine just sits there,
since "sitting there" is more than just sitting there. Also, not just
sitting there usually involves key presses and mouse movements.

"cat /proc/sys/kernel/random/entropy_avail" if you're interested.

My understanding is that disk seek times feed the entropy pool in Linux.
My interest isn't quite pointy enough to drive me to devise an
experiment that makes my drives seek to points scattered across the
surfaces to files not already in cache. Don't let me discourage anyone
else, though.

[John Hasler]

Post by Allen Kistler
My understanding is that disk seek times feed the entropy pool in
Linux. My interest isn't quite pointy enough to drive me to devise an
experiment that makes my drives seek to points scattered across the
surfaces to files not already in cache. Don't let me discourage anyone
else, though.

According to the comments in drivers/char/random.c disk interrupts are
used.

[Robert Riches]

Post by Rahul

Post by Robert Riches
(I'm not the OP...)
At least with that older Alpha kernel, disk I/O _DID_ fill the
entropy pool. I put code in the X startup script to do a bunch
of disk I/O if the X server didn't come up promptly.

I am the OP :) ......no, I don't think the HDD R/W increased my entropy. At
least if I did things correctly.

The trick is to access files that aren't cached.

[Rahul]

Post by Robert Riches
The trick is to access files that aren't cached.

Now, how does one do that? Care to share your bag of tricks. My naiive
attempts failed:

(1) Accessing a /usr/src Redhat build that I was sure had not been accessed
for months so ought not be ever in the cache.

(2) wget a new tar.gz. That must have to cause a write to disk, right?
Especially if it is huge?

No luck.

[Robert Riches]

Post by Rahul

Post by Robert Riches
The trick is to access files that aren't cached.

Now, how does one do that? Care to share your bag of tricks. My naiive
(1) Accessing a /usr/src Redhat build that I was sure had not been accessed
for months so ought not be ever in the cache.
(2) wget a new tar.gz. That must have to cause a write to disk, right?
Especially if it is huge?
No luck.

Those should have been good bets. Another idea, which I hadn't
tried, is to use dd to read from a raw device. You probably have
to be root to do that.

[jellybean stonerfish]

Post by Rahul
Don't some of the latest Intel chips come with an on-board random number
generator. I remember this being hardware based (rather than the pseudo
random ones conventionally employed). I believe the idea was amplyfing
minor temperature fluctations from a chip sensor which would mimic a
true random process.
Is this ever used these days? Just curious.

These days the hardware random generators are accessed through
/dev/hw_random