Generating random numbers for many security applications requires sufficient entropy — entropy measures how unpredictable the randomness is. A deterministic processor cannot generate entropy, so entropy must come from the outside — either from a hardware component with non-deterministic behavior, or from other factors that are sufficiently hard to reproduce such as the timing of user actions (that's where wiggling the mouse comes in). Once sufficient entropy is available, cryptography can be used to generate a practically unlimited stream of random numbers.

Linux works by accummulating entropy in a pool, then using cryptography to produce acceptable random numbers both through /dev/random and /dev/urandom. The difference is that /dev/random applies an extremely conservative entropy calculation that reduces the estimate of the entropy in the pool for every byte that it generates, whereas /dev/urandom does not concern itself with the amount of entropy in the pool.

If the estimate of entropy in the pool is too low, /dev/random blocks until more entropy can be accumulated. This can severely cripple the rate at which /dev/random can produce output. This is what you're observing here. It has nothing to do with tr; but strings reads output with buffering, so it has to read a full buffer (a few kB) from /dev/random just to produce at least one byte of input.

/dev/urandom is perfectly acceptable for generating a cryptographic key, because entropy does not in fact decrease in any perceptible way. (If you keep your machine running for longer than the universe has existed, you can't neglect these considerations, but otherwise you're good.) There is only one case where /dev/urandom is not good, which is on a freshly installed system that hasn't had time to generate entropy yet, or a freshly booted system that boots from read-only media.

Elimitating strings from your boot chain will probably speed up your process:

&lt;/dev/random LC_ALL=C tr -dc '~-!'


But you can use /dev/urandom here, as long as you take care not to generate passwords on a system that hasn't had time to accummulate sufficient entropy. You can check the level of Linux's entropy pool in /proc/sys/kernel/random/entropy_avail (if you use /dev/random, the figure in this file will be conservative, possibly very much so).

Reading from /dev/random does not produce any data
For analytics purposes, I'm looking at large sets of IP addresses in server log files. I'm trying to perform reverse-DNS lookups to understand where traffic is coming from - e.g. what percentage of IPs resolve to corporations, schools, government, international etc.

Despite a bunch of optimizations, individually reverse-DNS'ing every IP address still appears to be fairly expensive though. So -

is there any way to obtain an entire range of IPs from a reverse-DNS?

If yes, this could greatly reduce the number of actual reverse-DNS lookups.

Example (numbers slightly obfuscated): 


Log file contains a request from an IP 128.151.162.17
Reverse DNS resolves to 11.142.152.128.in-addr.arpa 21599 IN PTR alamo.ceas.rochester.edu
(So this is a visitor from Rochester University, rochester.edu)
Now, would it be safe to assume that all at least all IPs from 128.151.162.* will also resolve to rochester.edu?
What about 128.151.*.*? Is there a way to get the exact IP range?

