Long story short: no


"Fixing" the problem isn't that hard. What you need to do is generate lots of activity in a semi-random fashion to add to the "entropy pool" at boot time, just enough to hold you over the boot process (we have to assume that once the boot process is done, server activity alone will be enough to continually feed /dev/random and /dev/urandom).

I'm no expert on this, so I can't really give much meaningful advice. The one small piece of advice I can give is to hit up http://www.random.org if you need random integers.

Bill Clinton

Actually, no. Go back and read the previous posts here. Generating entropy may be a problem for some people (I have seen reports on the Internet about that), but I personally don't have that problem, and I don't think that is what others here are having problems with either.

My problem is that something is eating up my entropy, and doing it really quickly. And this happens when I have next to nothing running (i.e. the default programs that come in the Linode Gentoo base image). The only thing I see that may use random entropy is ssh, but I can't see any reason why it would be constantly taking entropy. It is my understanding it needs some when it first negotiates a connection, in order to generate keys or something. Not constantly.

I can go from a full entropy pool (4k or so) to 0 in less than 5 minutes. There is absolutely nothing that should use entropy that fast. It'd be useless if so, because it sure can't be refilled at anywhere near that rate.

I dunno, I've just given up. It's annoying, but I've switched Apache over to urandom, and just have to hope that nothing else is getting borked because of this problem...

-j

_________________
Programs that crash have been proven to be less useful than those that don't.
• Apple TechNote 117 •

There's no magic about /dev/random and /dev/urandom, they're just character devices:

$ ls -l /dev/*random
crw-rw-rw-    1 root     root       1,   8 Feb  2 07:03 /dev/random
cr--r--r--    1 root     root       1,   9 Feb 19 06:56 /dev/urandom

So 'rm /dev/random; mknod -m 666 /dev/random c 1 9'
should do the trick. Since I've not tried this, I'll add the usual caveats: YMMV, AFAIK, IANAL,OIMMBCTTA.

One more serious caveat. Once you've done this, I strongly suggest that you not use this box to generate anything requiring long-term security, such as GPG keys, SSL certificates, etc.

Hmmm, and I don't know why the permissions are different, or why anything would want +w on /dev/random. Maybe I just did something screwy on my box.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.
-- seen on the net

I guess the system writes to the entropy pool through the /dev/random device.

Yeah, I believe it does. My thoughts are that if you were to replace /dev/random with /urandom, then where would urandom gets its entropy. AFAIK, urandom pulls entropy from /random *if there is any* and then makes up its own when it runs out. Replacing /dev/random completely would seem to force urandom to always make up the random digits, which may or may not be a good idea.

I don't know if this is accurate or not, it's just a guess on my part.

Anyway, what I want is a way to tell the whole system to go to /dev/urandom when it needs entropy. Then if there is some in /dev/random, it'll get pulled in automatically, and if there isn't, then urandom will generate some. There really should be some way to do this, though I don't think there is now...

_________________
Programs that crash have been proven to be less useful than those that don't.

• Apple TechNote 117 •

Nope, that's not how it works. /dev/urandom always provides values from a psuedo-random number generator. It does, however, get the seed for the PRNG from the true entropy pool, and, IIRC, occasionally re-seeds, depending on how heavily it's used. What I don't remember is whether or not kernal reads from the entropy pool directory or via the character device, and if it does from the character devices, whether it actually opens /dev/random or just c1,8 directly. If it does open /dev/random, then my former suggestion wouldn't work.

Also /dev/random doesn't get it's entropy via writes to /dev/random. Even if it *did*, you sure wouldn't want anyone except root to write to it. The entropy pool is "restocked" via internal kernel events, such as the timing of the arrival of network packets, disk accesses, and so forth. Anyway, I think the 666 permission on /dev/random is a Debian artifact; on the RH machines I looked at, it's 644.

As for whether or not the PRNG is "good enough", it depends on your use. But that's why I suggested that using it to generate keys that require long-term security was not a good idea.

Are the accounting modules availabie in the Linode kernels? If so, you can enable accouting and (I think) track which processes are opening /dev/random and sucking down your entropy pool.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net

Cool, thanks for chiming in. Yeah, as I said, my understanding is sub-par, and apparently wrong! oh well, but now I know. thanks.



Well, the way its working on my system, (and a few others that have posted here), there is no option to use /dev/random. Believe me, I'd prefer it, but nothing I do has allowed me to keep entropy stocked for longer than 5 minutes, and I can't find anything on the Net to help. oh well... so much for security. (actually, I feel quite safe enough using urandom all the time, from what I've read it is less safe but only theoretically so, and if it were cracked, you would have more issues than just your keys being susceptable)...



I don't know. I am rather new to Linux. I'm a fast learner (I think ) but haven't even started to think about the kernel. I wouldn't know what to do here without some help, so any suggestions would be more than welcome!

thanks again for your helpful post,
-j

_________________
Programs that crash have been proven to be less useful than those that don't.

• Apple TechNote 117 •

I hacked together a quick MRTG helper script to monitor system entropy.

#!/usr/bin/perl -w

open(ENTROPY, "</proc/sys/kernel/random/entropy_avail")
        or die "Couldn't open entropy file for reading: $!";
$entropy = <ENTROPY>;
close ENTROPY;

chomp $entropy;

printf("%d\n%d\n", $entropy, $entropy);

The relevant bits of my MRTG config file are as follows:

## Monitor system entropy
Target[meat.entropy]: `/usr/local/mrtg/entropy.pl`;
Title[meat.entropy]: available entropy
MaxBytes[meat.entropy]: 4096
PageTop[meat.entropy]: <h1> available entropy </h1>
ShortLegend[meat.entropy]: b
Legend1[meat.entropy]: Available Entropy (bits)
LegendI[meat.entropy]: Entropy
Options[meat.entropy]: growright,gauge,noo,noscale

Maybe someone will find this helpful. I've been running it for a little while and it shows my entropy pool staying full, but I'm not running Gentoo.

Hi,
I've solved the problem by getting the content of /dev/random of my workstation (plenty of random data there) to my server. I have a script that I'd be happy to share for loading the data into the entropy pool. With some crontab work transfer is painless and fully automatic.

I spent a few hours last night debugging the entropy problem within the kernel (perhaps not specific to UML). I added printk's all over the place, and indeed, UML is calling the correct random functions to populate entropy.

What I can't figure out is why in Gentoo, doing "cat /proc/sys/kernel/random/entropy_avail" reduces entropy with each successive cat. If I don't touch entropy_avail, it will go up, but as soon as I start cat'ing it, it goes down...

Rebooting into Debian (same kernel version), it doesn't have this problem. entropy_avail continues to rise, no matter how many times I cat the file.

So where the heck does this point towards?

-Chris

Well, that's a good sign! sort of...



My thoughts exactly. I have always assumed that there was something else sucking down the entropy, but upon further consideration, that makes no sense. lsof shows nothing accessing it.

Could cat be guilty? Could it be disfunctional in Gentoo? As stated before, this isn't solely a Linode problem, others in the Gentoo forums echo the problems. (It also appears in other distros, but much more rarely. It could be a different cause for people complaining of similar issues with other distros...)




Is anyone else out there (on Linode) experiencing this problem and NOT on Gentoo?...



Heck if I know...

_________________
Programs that crash have been proven to be less useful than those that don't.

• Apple TechNote 117 •

This is where I'm boggled... Nothing in userspace should cause this, but about only thing I can think of is a problem on gentoo with glibc, and the open/read library calls. The odd thing is that proc files are 'special', handled by the kernel -- it does the same thing regardless of distro..

I suppose comparing "strace cat entropy_avail" on different distros might be of some use...

-Chris

I've been poking around at the /dev/[u]random stuff for a few hours and here's the information I came up with:

1) Most of the services on my system are using /dev/urandom instead of /dev/random.
2) Readin from /dev/urandom depletes /dev/random by however many bytes you read--if there is any.
3) Entropy is replenished by disk activity only. Network traffic has no effect.
4) For some unknown reason, every e-mail that comes in depletes the entropy pool by 2048 bytes. WTF is up with that?

I've had cacti monitoring my entropy pool overnight. This is what it looks like:



(Note: This pic is a link to the generated version, not a static one. What you're looking at is the latest graph.)

I cannot understand why one e-mail would deplete the entropy pool by 2k, and it's going to take a while to track down what's doing it. Between sendmail, milters and the delivery agent there are a lot of possible contenders. Anyway, as you can see, when the system sits around and no mail is coming in, the entropy pool does grow.

Chris, is there any way to get entropy from network activity? I've seen a bunch of posts on the subject (here and elsewhere on the Internet) but have not yet found any really useful information. Mostly vague references to some kernel patches somewhere. Maybe it's in 2.6--does anyone know if it is?

Anyway, that's my $0.02 on the subject. If I find the culprit to the 2k of entropy per e-mail I'll post it here.

-- James

I've looked at the UML code, and indeed interrupts caused by network activity is hooked into the entropy generating code. It might just be that it's not enough of a time difference to generate reliable randomness, but I don't fully understand the code.

Jeff Dike (uml dev) seems to think hooking the host's entropy pool into UML is the solution, but, I'm worried about a single UML depleting the pool. Jeff's response is "UML doesn't do enough random things to generate enough entropy". I'd like to see a solution where the entropy-generating code is a little less picky (but not easy enough to not be random)...

-Chris

Try increasing the pool-size:

echo 8192 >  /proc/sys/kernel/random/poolsize