[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is /dev/random good enough to generate one-time pads?
-----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-----