What would writing to /dev/urandom do?
Allen Kistler
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
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.
--
Andrew Halliwell
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".
--
| spi...@freenet.co.uk | |
| Andrew Halliwell BSc | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" |
| in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
| Computer Science | - Father Jack in "Father Ted" |
Jean-David Beyer
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.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 05:55:01 up 7 days, 16:44, 3 users, load average: 4.16, 4.07, 4.01
Allen Kistler
> Allen Kistler wrote:
>> 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.
> 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.
Allen Kistler
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.
Unruh
>Allen Kistler <acki...@oohay.moc> wrote:
>> 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
Maxwell Lol
Rahul
@nwrddc01.gnilink.net:
> 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.
--
Rahul
Jean-David Beyer
Here is one commercial product:
Just do a search on "hardware random number generator"
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 18:30:01 up 11 days, 5:19, 3 users, load average: 4.11, 4.20, 4.19
Rahul
@nwrddc02.gnilink.net:
> Yes.
>
> Here is one commercial product:
>
> 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?
--
Rahul
John Hasler
> 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 <h...@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
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).
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 20:25:01 up 11 days, 7:14, 3 users, load average: 4.40, 4.32, 4.18
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.
>--
>Rahul
Rahul
> 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.
--
Rahul
Rahul
news:dfE2m.34249$PH1.22441@edtnps82:
> 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?
--
Rahul
John Hasler
> 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.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
The Natural Philosopher
> Rahul writes:
>> 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?
Maxwell Lol
> 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.
Maxwell Lol
> 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.
Jean-David Beyer
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.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 20:55:01 up 13 days, 7:44, 3 users, load average: 4.17, 4.15, 4.25
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
jellybean stonerfish
>
> 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
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.
--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)
Art Werschulz
The Natural Philosopher <t...@invalid.invalid> writes:
> 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
--
Art Werschulz (8-{)} "Metaphors be with you." -- bumper sticker
GCS/M (GAT): d? -p+ c++ l++ u+ P++ e--- m* s n+ h f g+ w+ t+ r-
Net: a...@dsm.fordham.edu http://www.dsm.fordham.edu/~agw
Phone: Fordham U. (212) 636-6325, Columbia U. (212) 939-7060
Rahul
news:slrnh4oc0f.2...@one.localnet:
> 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.
--
Rahul
Rahul
> 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.
--
Rahul
Robert Riches
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.
Allen Kistler
> 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
> 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.
John Hasler
> 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".
Rahul
> 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
> 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.
--
Rahul
jellybean stonerfish
Does reading/writing to your harddrive increase your entropy?
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.
Rahul
> (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.
--
Rahul
Allen Kistler
> Robert Riches wrote:
>> (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
> 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
The trick is to access files that aren't cached.
Rahul
> 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.
--
Rahul
jellybean stonerfish
> Rahul <nos...@nospam.invalid> writes:
>
>> 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
>On Wed, 01 Jul 2009 20:47:29 -0400, Maxwell Lol wrote:
>> Rahul <nos...@nospam.invalid> writes:
>>
>>> 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.
>>
>> 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.
Robert Riches
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
> 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