Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 4 down vote favorite
1

I have a server that cannot generate enough entropy to support /dev/random. The particular piece of software having problems can't be configured to use /dev/urandom.

I tried moving /dev/random to /dev/realrandom and symlinking /dev/random to /dev/urandom, but lsof /dev/realrandom still shows processes using it.

In Does urandom share the same entropy of random?, the suggestion is to use mknod /dev/random 1 9. Will this hold across restarts? Should I be using udev somehow?

share|improve this question
1  
I'd rather you didn't modify the question to suit the answers. I am not asking how to increase entropy. – Brian Henk Jul 13 '11 at 18:06

4 Answers

up vote 8 down vote

You should consider adding more entropy rather than compromising your system.

share|improve this answer
I have neither physical access to these systems to add hardware to increase entropy nor permanent shell access to apply kernel patches when it is updated. Are there other options to legitimately increase entropy? – Brian Henk Jul 12 '11 at 21:12
2  
None of those entropy daemons are kernel patches. – Ignacio Vazquez-Abrams Jul 12 '11 at 21:15
How is something like timer entropy daemon better for randomness than whatever urandom uses? I don't have a sound card or video device attached, so the other two listed there will not help. – Brian Henk Jul 12 '11 at 21:34
1  
urandom uses a mathematical formula to generate the next random value whenever real entropy isn't available. This mathematical formula, although seemingly random, is deterministic. Even a small bit of actual entropy is better than nothing. – Ignacio Vazquez-Abrams Jul 12 '11 at 21:40
From what I understand, urandom still uses entropy if it is available. I am willing to accept the relatively minuscule risk of using a not so random number when there is low entropy available with the trade-off being that the system responds more reliably. Adding entropy to the pool using a daemon is not a bad idea, but it is still possible to run out and that is what I want to avoid. – Brian Henk Jul 13 '11 at 18:01
show 1 more comment
up vote 4 down vote

If you need /dev/random, then you can not afford to use /dev/urandom.

The point here is that dev/random would rather block that return a pseudo-random number (i.e. return when there is insufficient entropy in the pool) and dev/urandom is willing to return a pseudo-random numbers to avoid blocking

One is good for games and Monte Carlo and keeping your kid sister from reading your files, the other is good for keeping major governments from reading your files (well, hopefully).

share|improve this answer
+1 - I tend to agree with this. – boehj Jul 13 '11 at 10:37
Security is only as strong as its weakest link. I would be very happy if my random numbers being theoretically predictable was the weakest part of my defense. – Brian Henk Jul 13 '11 at 18:05
up vote 1 down vote

I've used egd to solve this problem. I'm betting you're using this with gpg. I needed to compile gpg from source to get it to work with egd, but once I did it worked very well.

Another suggestion: Sign up for an account here and download a gob of random numbers. I think you can add entropy with a simple cat file_with_random_numbers > /dev/random. There is also a utility on that site called qrand (needs to be compiled IIRC) that will download from the service and seed your /dev/random for you.

share|improve this answer
Unfortunately, this is a proprietary program that is reading directly from the device, so I don't think EGD would work. – Brian Henk Jul 12 '11 at 21:17
@ultra it's not really a good idea to get entropy from an unknown source like that. One of the key aspects you are after in the local entropy is that it is also unique. Getting it from an unknown source over a network means it may be logged, intercepted, or copied by someone else thus negating its value. – Keith Jul 13 '11 at 3:33
Not for super high security needs, of course not. It certainly isn't best practice. However, another secure source of random numbers could be gathered elsewhere and securely uploaded to feed the entropy. Record 10 minutes of TV static off of an analog TV or VCR, upload the resultant .wav file to server (securely) and feed it to /dev/random. – ultrasawblade Jul 13 '11 at 4:50
up vote 0 down vote

All you need to do is to create something like /etc/udev/rules.d/70-disable-random-entropy-estimation.rules with the following contents:

# /etc/udev/rules.d/70-disable-random-entropy-estimation.rules
# Disables /dev/random entropy estimation (it's mostly snake oil anyway).
#
# udevd will warn that the kernel-provided name 'random' and NAME= 'eerandom'
# disagree.  You can ignore this warning.

# Use /dev/eerandom instead of /dev/random for the entropy-estimating RNG.
KERNEL=="random", NAME="eerandom"

# Remove any existing /dev/random, then create symlink /dev/random pointing to
# /dev/urandom
KERNEL=="urandom", PROGRAM+="/bin/rm -f /dev/random", SYMLINK+="random"
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.