Talk:/dev/random

Should this all really be in the FreeBSD section?

In 2004, Landon Curt Noll tested the FreeBSD 5.2.1 version of /dev/random and found that it was not a cryptographically strong random number generator because its output had multiple uniformity flaws according to the Billion bit test. Similar flaws were found in the Linux 2.4.21-20, Solaris 8 patch 108528-18, and Mac OS X 10.3.5 implementations of /dev/random.

Typical?

The article says:

It is typically used for providing a character stream for encryption, incompressible data, or securely overwriting files.

No. These are not typical uses but rather they are just some of the typical uses. But it is no more secure to overwrite a file with random data than it is do to do will nulls, so that is a poor and inefficient way of overwriting files!

Paul Beardsell 23:27, 27 Sep 2004 (UTC)

Actually, I (and apparently the U.S. gov't) disagree.

The DoD regulation for deleting files securely states that overwriting with random material (maybe up to 5 times) will ensure that any orderly data is gone. If you only use 0s and 1s, the possibility is there that a clever recovery could analyze the HD and determine if parts are not totally zeroed out. Theoretically, this would permit an attacker/recovery expert to locate segments of files. Random overwrite makes this impossible: the underlying structure is now totally random. nneonneo 18:48, 30 January 2006 (UTC)

This is wrong. First, the DoD would rather you melt or grind the media. Second, it's silly to go to extreme measures defeating an exotic threat without also addressing the problem of bad block replacement relocating your data. Your data may be all over the drive, never overwritten, because the hard drive decided that a sector was about to fail. It is better to be fast, just in case you get interrupted by the enemy, and so that you are not tempted to skip the operation. 24.110.60.225 03:08, 5 July 2006 (UTC)

Using a journaling file system carries a similar risk. IMHO, the most reliable way to ensure that deleted data is unreadable is to never write unencrypted data to the platter in the first place. Failing that, overwriting with several passes of random data is best, precisely because it decreases the signal-to-noise ratio for any attacker trying to read the old bits. See Peter Gutmann's 1996 paper Secure Deletion of Data from Magnetic and Solid-State Memory for a thorough discussion of the issues.

That said, /dev/random is unsuitable for wiping disks simply because it's slow, even if you use urandom. I use it to seed a fast CSPRNG and use that for the overwriting. Unless you expect a major corporation or intelligence agency to try to read your disk, and have data they would find interesting, it works well enough. Tualha (Talk) 17:46, 24 November 2006 (UTC)

How do we know...

How do we know that stuff that comes from /dev/random isn't actually XOR'd with what goes into /dev/null? That /dev/null info has to go back into the machine somehow, or else it might collect inside the CPU fan and hinder that source of information.

This /dev/random seems like it could be hazardous if overused--it could overflow into /dev/zero and junk up the whole system. There should be a /dev/monitor that puts information back into the entropy pool and junks the pool when it gets close to overflowing. Though where this junk goes to could be a problem. There should probably be some type of information bottle that the user could change when necessary.

This bottle of potentially valuable information could then be sold to an InfoDump, which would distill the sticky black stuff into clear, pure inert information and sell the excess junk to some bigger InfoDump... --Ihope127 23:58, 11 July 2005 (UTC)

Sounds to me as if it's already overflowed into your brain. Wiseguy ;) Tualha (Talk) 17:46, 24 November 2006 (UTC)

Confusion

I am confused. urandom takes the output of random, and applies additional transformations? In which case, why is it called a "pseudo-random" number generator? I associate psuedo-random with purely numerical algorithms that produce predictable, but hopefully acceptable output given a seed. Sdedeo 22:24, 2 September 2005 (UTC)

• /dev/urandom is the non-blocking form of /dev/random. It outputs exactly what /dev/random does up until the entropy pool runs out, at which point it uses a different PRNG to generate values. Thus, it is non-blocking, but output isn't guaranteed to be of high quality. nneonneo 18:35, 30 January 2006 (UTC)

This is probably not true. /dev/urandom continues to give out pseudo random numbers with the same algoritm, but without adding new entropy to its pool (and possibly missing some other transformation because of that). --LPfi (talk) 11:29, 11 May 2009 (UTC)

Python Code

f=open('/dev/random', 'r')
print repr(f.read(10))
'\xb6.\x06\xd4\x93\x8d\r\x86\x19W'

I am not sure how to parse this. Looks like there are Unicode characters (prefixed with \) and Ascii characters with the forward slash...

• /dev/[u]random generate bytes in the entire possible range (0x00 - 0xFF). Thus, there isn't any particular pattern, the bytes are meant to be used in a crypto ky, for example.

To get random letters from /dev/random, you would likely try code like this:

# Run me using sudo on most systems!
f=open('/dev/random', 'rb')
charset='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890'
print ''.join([charset[ord(i)%len(charset)] for i in f.read(100)])
f.close()

This generates 10 random characters in [a-zA-Z0-9]. There is a slight bias that must be noted: due to the limited range of a byte, the letters appearing earlier in the string will appear slightly more frequently than those appearing last. nneonneo 19:07, 30 January 2006 (UTC)

Others uses of /devv/random and /dev/urandom

• /dev/urandom can be used to test a sound card,headphones...

cat /dev/urandom > /dev/dsp

Other operating systems

Maybe there are others, but for certain there's NoiseSYS - a device driver which runs under DOS and provides RANDOM and URANDOM (RANDOM$ and URANDOM$ in later versions) which do the same. As DOS allows device names to be preceeded by /DEV the /DEV/RANDOM is a fully possible solution under DOS. maybe that should be mentioned?

UNIX systems?

Is /dev/random a typical device of a UNIX system? I thought that this was introduced with the Linux kernel and adopted by OpenBSD/FreeBSD a bit later and by Solaris a lot later. Anybody has knowledge on that?

Sure. Theodore Ts'o <tytso@mit.edu> (pronounced "Cho", with a long O sound) wrote it for Linux. FreeBSD cloned it, badly, failing to do the entropy accounting that is so critical to preventing undiscovered hash/cipher weaknesses from affecting the randomness quality. Solaris is indeed recent. MacOS X has a /dev/random too. 24.110.60.225 03:17, 5 July 2006 (UTC)

MacOS X uses the FreeBSD Yarrow implementation

Wait, I thought it was part of AT&T UNIX? 71.81.37.151 05:47, 21 November 2006 (UTC)

If MacOS X uses the Yarrow thing, I think the article should say so (as it does for FreeBSD). Karadoc** (talk) 06:50, 28 January 2008 (UTC)

Did you say "true random number generator" ?

How an algorithm could be "truely" random without any external source such as the decay of an isotope ? The quality of /dev/random output can't be truely random, indistinguishable from random maybe but truely random it's not. —Preceding unsigned comment added by 83.115.108.91 (talk) 08:14, 28 March 2008 (UTC)

I know it's been a long time since the posting of this question, but I hate to leave an unanswered question on the page. Hardware random number generator states that the noise is generated from quantum phenomena, such as thermal noise or the photoelectric effect, which are truly random. This noise is gathered into the entropy pool that /dev/random uses. So why could it NOT be truly random, if the sources it retrieves from are? I can agree that /dev/urandom (the unlocked source) could potentially be less truly random, but /dev/random is by far well enough for high-security purposes. PseudoOne (talk) 21:02, 21 January 2009 (UTC)

The Billion bit test has found multiple uniformity flaws in a number of /dev/random implementations. In fact, I have never found a /dev/random implementation that did not suffer from at least one uniformity flaw, except maybe those /dev/random implementations that bypassed the standard /dev/random driver code and directly accessed a Cryptographically sound hardware source. ( BTW: The sited page lists observed flaws in the FreeBSD 5.2.1, Solaris 8 patch 108528-18, Linux 2.4.21-20, OS X 10.3.5 implementations of /dev/random. Not listed are a numer of more recent tests under RedHat Linux, OS X, FreeBSD, etc.)

Based on my testing experience, I would hesitate to call /dev/random a Cryptographically secure pseudorandom number generator. The output appears to be statistically distinguishable from a true random source. chongo (talk) 03:48, 3 July 2009 (UTC)

I don't think the reference you cite (for your claim that no /dev/random implementation is cryptographically strong) is credible. I'm a cryptographer, and I think that page has misunderstood randomness testing. In my view, that page is not from a credible source, it is not verifiable, it has not been replicated. It is making an extraordinary claim, and extraordinary claims require stronger substantiation than that. The claims that /dev/random is flawed should be deleted from the Wikipedia article: they are not credible. (21:14, 29 July 2010 (UTC)) —Preceding unsigned comment added by 128.32.153.194 (talk)