-----BEGIN PGP SIGNED MESSAGE----- On Wed, 27 Nov 1996, Igor Chudov @ home wrote:

Subj sez it all.

Thank you.

- Igor.

Yes, as a matter of fact it is. /dev/random is based on an entropy pool taken from hardware interrupts and such, thus is a RNG, not a PRNG (thats right IPG, Linux uses hardware to get random numbers... imagine that!). /dev/urandom is, however, a PRNG... Below is the doc that comes with the linux source, if you want more info... (this was taken from my /usr/src/linux/drivers/char/random.c, the code _would be_ at the end, but i think 1200 lines of C might be a bit excessive to answer your question) - ----BEGIN random.c EXCERPT----- /* * random.c -- A strong random number generator * * Version 1.00, last modified 26-May-96 * * Copyright Theodore Ts'o, 1994, 1995, 1996. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, and the entire permission notice in its entirety, * including the disclaimer of warranties. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote * products derived from this software without specific prior * written permission. * * ALTERNATIVELY, this product may be distributed under the terms of * the GNU Public License, in which case the provisions of the GPL are * required INSTEAD OF the above restrictions. (This clause is * necessary due to a potential bad interaction between the GPL and * the restrictions contained in a BSD-style copyright.) * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. */ /* * (now, with legal B.S. out of the way.....) * * This routine gathers environmental noise from device drivers, etc., * and returns good random numbers, suitable for cryptographic use. * Besides the obvious cryptographic uses, these numbers are also good * for seeding TCP sequence numbers, and other places where it is * desirable to have numbers which are not only random, but hard to * predict by an attacker. * * Theory of operation * =================== * * Computers are very predictable devices. Hence it is extremely hard * to produce truly random numbers on a computer --- as opposed to * pseudo-random numbers, which can easily generated by using a * algorithm. Unfortunately, it is very easy for attackers to guess * the sequence of pseudo-random number generators, and for some * applications this is not acceptable. So instead, we must try to * gather "environmental noise" from the computer's environment, which * must be hard for outside attackers to observe, and use that to * generate random numbers. In a Unix environment, this is best done * from inside the kernel. * * Sources of randomness from the environment include inter-keyboard * timings, inter-interrupt timings from some interrupts, and other * events which are both (a) non-deterministic and (b) hard for an * outside observer to measure. Randomness from these sources are * added to an "entropy pool", which is mixed using a CRC-like function. * This is not cryptographically strong, but it is adequate assuming * the randomness is not chosen maliciously, and it is fast enough that * the overhead of doing it on every interrupt is very reasonable. * As random bytes are mixed into the entropy pool, the routines keep * an *estimate* of how many bits of randomness have been stored into * the random number generator's internal state. * * When random bytes are desired, they are obtained by taking the MD5 * hash of the contents of the "entropy pool". The MD5 hash avoids * exposing the internal state of the entropy pool. It is believed to * be computationally infeasible to derive any useful information * about the input of MD5 from its output. Even if it is possible to * analyze MD5 in some clever way, as long as the amount of data * returned from the generator is less than the inherent entropy in * the pool, the output data is totally unpredictable. For this * reason, the routine decreases its internal estimate of how many * bits of "true randomness" are contained in the entropy pool as it * outputs random numbers. * * If this estimate goes to zero, the routine can still generate * random numbers; however, an attacker may (at least in theory) be * able to infer the future output of the generator from prior * outputs. This requires successful cryptanalysis of MD5, which is * not believed to be feasible, but there is a remote possibility. * Nonetheless, these numbers should be useful for the vast majority * of purposes. * * Exported interfaces ---- output * =============================== * * There are three exported interfaces; the first is one designed to * be used from within the kernel: * * void get_random_bytes(void *buf, int nbytes); * * This interface will return the requested number of random bytes, * and place it in the requested buffer. * * The two other interfaces are two character devices /dev/random and * /dev/urandom. /dev/random is suitable for use when very high * quality randomness is desired (for example, for key generation or * one-time pads), as it will only return a maximum of the number of * bits of randomness (as estimated by the random number generator) * contained in the entropy pool. * * The /dev/urandom device does not have this limit, and will return * as many bytes as are requested. As more and more random bytes are * requested without giving time for the entropy pool to recharge, * this will result in random numbers that are merely cryptographically * strong. For many applications, however, this is acceptable. * * Exported interfaces ---- input * ============================== * * The current exported interfaces for gathering environmental noise * from the devices are: * * void add_keyboard_randomness(unsigned char scancode); * void add_mouse_randomness(__u32 mouse_data); * void add_interrupt_randomness(int irq); * void add_blkdev_randomness(int irq); * * add_keyboard_randomness() uses the inter-keypress timing, as well as the * scancode as random inputs into the "entropy pool". * * add_mouse_randomness() uses the mouse interrupt timing, as well as * the reported position of the mouse from the hardware. * * add_interrupt_randomness() uses the inter-interrupt timing as random * inputs to the entropy pool. Note that not all interrupts are good * sources of randomness! For example, the timer interrupts is not a * good choice, because the periodicity of the interrupts is to * regular, and hence predictable to an attacker. Disk interrupts are * a better measure, since the timing of the disk interrupts are more * unpredictable. * * add_blkdev_randomness() times the finishing time of block requests. * * All of these routines try to estimate how many bits of randomness a * particular randomness source. They do this by keeping track of the * first and second order deltas of the event timings. * * Ensuring unpredictability at system startup * ============================================ * * When any operating system starts up, it will go through a sequence * of actions that are fairly predictable by an adversary, especially * if the start-up does not involve interaction with a human operator. * This reduces the actual number of bits of unpredictability in the * entropy pool below the value in entropy_count. In order to * counteract this effect, it helps to carry information in the * entropy pool across shut-downs and start-ups. To do this, put the * following lines an appropriate script which is run during the boot * sequence: * * echo "Initializing random number generator..." * # Carry a random seed from start-up to start-up * # Load and then save 512 bytes, which is the size of the entropy pool * if [ -f /etc/random-seed ]; then * cat /etc/random-seed >/dev/urandom * fi * dd if=/dev/urandom of=/etc/random-seed count=1 * * and the following lines in an appropriate script which is run as * the system is shutdown: * * # Carry a random seed from shut-down to start-up * # Save 512 bytes, which is the size of the entropy pool * echo "Saving random seed..." * dd if=/dev/urandom of=/etc/random-seed count=1 * * For example, on many Linux systems, the appropriate scripts are * usually /etc/rc.d/rc.local and /etc/rc.d/rc.0, respectively. * * Effectively, these commands cause the contents of the entropy pool * to be saved at shut-down time and reloaded into the entropy pool at * start-up. (The 'dd' in the addition to the bootup script is to * make sure that /etc/random-seed is different for every start-up, * even if the system crashes without executing rc.0.) Even with * complete knowledge of the start-up activities, predicting the state * of the entropy pool requires knowledge of the previous history of * the system. * * Configuring the /dev/random driver under Linux * ============================================== * * The /dev/random driver under Linux uses minor numbers 8 and 9 of * the /dev/mem major number (#1). So if your system does not have * /dev/random and /dev/urandom created already, they can be created * by using the commands: * * mknod /dev/random c 1 8 * mknod /dev/urandom c 1 9 * * Acknowledgements: * ================= * * Ideas for constructing this random number generator were derived * from the Pretty Good Privacy's random number generator, and from * private discussions with Phil Karn. Colin Plumb provided a faster * random number generator, which speed up the mixing function of the * entropy pool, taken from PGP 3.0 (under development). It has since * been modified by myself to provide better mixing in the case where * the input values to add_entropy_word() are mostly small numbers. * Dale Worley has also contributed many useful ideas and suggestions * to improve this driver. * * Any flaws in the design are solely my responsibility, and should * not be attributed to the Phil, Colin, or any of authors of PGP. * * The code for MD5 transform was taken from Colin Plumb's * implementation, which has been placed in the public domain. The * MD5 cryptographic checksum was devised by Ronald Rivest, and is * documented in RFC 1321, "The MD5 Message Digest Algorithm". * * Further background information on this topic may be obtained from * RFC 1750, "Randomness Recommendations for Security", by Donald * Eastlake, Steve Crocker, and Jeff Schiller. */ - ----END random.c EXCERPT---- This answer your question? --Deviant PGP KeyID = E820F015 Fingerprint = 3D6AAB628E3DFAA9 F7D35736ABC56D39 "Evil does seek to maintain power by suppressing the truth." "Or by misleading the innocent." -- Spock and McCoy, "And The Children Shall Lead", stardate 5029.5. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMp2wWTCdEh3oIPAVAQGXDwf9F8OyHkVFGBDtb2mXrkYy89KewH9uylVS VQAmEwxAggAC/C/FbhhXcQNWVCCmcRCvXFMXtZmxnc5dP2/Hn+kzAJuXjBJLA8bO EcgWTGYCuyoZhXcon63FCW1EXg8/9qakfb66B3kc+tsx5UVbSlbzk4wfNPAzXWFE V1ASeaoE708Dd/FN+2DODyFXssJ4aVxDYm8tv07AD7WYT4rbW896om0nKynj1DCW xgA9+GVs37El2gMhz9j7sS3WouFnEckCmXuUWKzSUBGA68T5eJqSRywOs0ePgPQi +t6KABJ20TEQX4u8wAvdg/F58B4wZZPcE66IAIITeDQm+uE+a5NilA== =9zj/ -----END PGP SIGNATURE-----