From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software / Security (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Mid-importance).
Taskforce icon
This article is supported by WikiProject Computer Security (marked as High-importance).
WikiProject Linux (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.

FreeBSD claims are wrong[edit]

It seems some claims for the FreeBSD implementation in the article are incorrect. Since no sources are given, I'd like to change them to something better, since I have no idea, where the FreeBSD /dev/random device never blocks statement originally came from.

FreeBSD documentation ( clearly states that /dev/{u,}random will block if there is not enough entropy and has done so since at least 5.0-RELEASE. has a lot of discussion going on on improving /dev/random on FreeBSD. Most importantly: Both Yarrow and Fortuna need to accumulate a certain amount of entropy before they can start generating random numbers. Until that happens, reads from /dev/random will block. dhke (talk) 09:22, 28 April 2014 (UTC)

Should this all really be in the FreeBSD section?[edit]

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.[1]

I'm removing that part altogether per WP:NOR: the only reference is a link to the web page of the person who added that paragraph. I can't see any reliable-looking source (e.g. academic paper) referenced on that web page. Lamellae (talk) 22:06, 13 August 2013 (UTC)


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. 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...[edit]

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)


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[edit]

f=open('/dev/random', 'r')
print repr(

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')
print ''.join([charset[ord(i)%len(charset)] for i in])

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 /dev/random and /dev/urandom[edit]

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

cat /dev/urandom > /dev/dsp

Other operating systems[edit]

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?[edit]

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 <> (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. 03:17, 5 July 2006 (UTC)

MacOS X uses the FreeBSD Yarrow implementation

Wait, I thought it was part of AT&T UNIX? 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" ?[edit]

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 (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.[2] 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 (talk)


  1. ^ "BIllion Bit Test: Results and Conclusions", LavaRnd, LavaRnd, 22 Sep 2004, retrieved 3 July 2009 
  2. ^ "BIllion Bit Test: Results and Conclusions", LavaRnd, LavaRnd, 22 Sep 2004, retrieved 3 July 2009 

/dev/urandom not used for cryptographically secure random number generation[edit]

As of Feb, 03, 2011 the article has a sentence: "This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. Thus, it may not be used as a cryptographically secure pseudorandom number generator, but it may be suitable for less secure applications."

The first sentence is true. The entropy of say a 1000 digit number taken from /dev/random will contain more entropy than a 1000 digit number taken from /dev/urandom. However, this does not imply that /dev/urandom is not appropriate for use in cryptography. So long as the internal state maintained by /dev/urandom contains more bits than the keys, nonces, etc. generated, it is perfectly suitable for use as a cryptographically secure random number generator.

Consider that Java's SecureRandom number generator is implemented to seed itself from /dev/urandom: Then read the documentation for the SecureRandom class: which clearly states: "This class provides a cryptographically strong pseudo-random number generator (PRNG)."

If /dev/urandom were not a valid cryptographically secure psuedorandom number generator, then it would not be used as the basis for the the SecureRandom implementation. Many applications use /dev/urandom to obtain seed material, keys, nonces, etc. (talk) 22:54, 3 February 2011 (UTC)

No, if it does not contain sufficient entropy there is a chance of a distinguishing attack. That it may still provide the basis for a cryptographically secure pseudorandom generator such as SecureRandom does not mean that it is cryptographically secure "as is". What is required though is a suitable randomness extractor to extract the entropy into a uniformly distributed value. The statement that /dev/urandom may not be suitable for cryptographic purposes is directly from the man page. Nageh (talk) 23:00, 3 February 2011 (UTC)
I don't see that sentence anywhere in the man page, in fact it says: "If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys." The man page is plainly advocating using /dev/urandom for all other cryptographic purposes. (talk) 16:36, 4 February 2011 (UTC)
Huh? Did you click on the link I provided to you? I quote:

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

Nageh (talk) 16:41, 4 February 2011 (UTC)
The man page is very confusing here, and honestly, something just is not right there. I don't know how /dev/urandom is implemented internally but I have changed the article accordingly. The statement that /dev/urandom is suitable as a CSPRG is worrisome as there may be efficient distinguishing attacks when the pool's entropy is very low. In a way, the man page is contradicting itself. Also see the analysis by Noll, who found flaws even in the uniform distribution of /dev/random, which means that neither /dev/urandom nor /dev/random are CSPRGs by the actual definition. Nageh (talk) 17:12, 4 February 2011 (UTC)
Note that nowhere in that sentence does it say /dev/urandom is not cryptographically secure. What it says is that if there are breaks in the algorithm underlying the pseudorandom generations (Which may be AES, SHA-256, etc.) then it may be feasible to distinguish the output of /dev/urandom from a random source. Currently this is in theory possible but requires exponential time to do so. Look at the definition for Cryptographically_secure_pseudorandom_number_generator. Is this the same definition used in this article? To me it seems to differ from the overly strict perfect randomness which this article seems to suggest is meant by cryptographically secure. See: A source doesn't have to be perfectly random to be suitable for cryptographic purposes. Note that even the best and most robust RNG's fail some tests some of the time: (talk) 20:43, 4 February 2011 (UTC)
Let me clarify. First, it is obvious that if some cryptographic primitive used is breakable then so is the PRG built on it. Second, any primitive is breakable in exponential time because that refers to a brute-force complexity. Third, there is a precise definition for what it means for a PRG to be CS. It says that for a certain input key size (the seed) the CSPRG is indistinguishable from a truly random sequence in polynomial complexity assuming that the key has been selected uniformly at random. How can you create a seed of uniform distribution from an entropy source that is biased? Right, you attempt to measure the entropy in given data and extract it into a seed that is close to uniform distribution. So assuming the internal CSPRG is secure and the randomness extractor is secure the overall /dev/random is secure as well (i.e., a CSPRG). Now what happens when you don't get a uniform distribution for the seed because of insufficient entropy? In this case you have one more assumption in stating that /dev/urandom is a CSPRG. But an algorithm can only be a CSPRG as long as no polynomial-time distinguishing attack exists. And that was my initial concern since the man page warns against the use of /dev/urandom for some applications. Sorry, but if you don't have the highest trust in your design you cannot call it a CSPRG. That is best practice, btw: see the Handbook of Applied Cryptography, which explicitly discards certain hash-based PRG designs as being CS. Anyway, I think the current wording in the article is quite spot on (as you seem to agree below). Nageh (talk) 21:53, 4 February 2011 (UTC)
I think your changes look good (talk) 21:11, 4 February 2011 (UTC)

Probably you should check — Preceding unsigned comment added by (talk) 16:12, 29 March 2016 (UTC)

Writing to /dev/random[edit]

(In Linux), who says that you can add entropy by writing to /dev/random? I don't see this in any of the Linux man pages. — Preceding unsigned comment added by (talk) 19:54, 13 July 2011 (UTC)

Citation for usage of device driver noise[edit]

In response to the opening paragraph needing a citation:

"It allows access to environmental noise collected from device drivers and other sources.[citation needed] "

It can be found here: — Preceding unsigned comment added by (talk) 19:41, 31 July 2012 (UTC)

Size of the pool[edit]

Is there a standard pool size ? If not what is it dependent of ? --Martvefun (talk) 09:00, 10 August 2012 (UTC)

This page isn't for questions and answers, but see
That's for Linux kernels and indicates that, for Kernel 2.6, the entropy pool size is 4096 bits. For other Unix-like systems this may be different. For instance on OpenBSD the entropy pool is 2048 words (16384 bits). Needless to say increasing the size of the entropy pool doesn't automatically create more entropy if none is available. --TS 18:48, 10 August 2012 (UTC)

Cross-article contradiction[edit]

The /dev/random article asserts that, /dev/random is suitable for generating one-time pads or keys. But, the one-time pad article asserts the opposite. The /dev/random article has a citation while the one-time pad article does not. Also, the citation link given is broken, so I can not establish the credibility of these statements one way or the other. I have come across come across the link: , but it only claims that "/dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation". The article in question does not provide any references to assert this claim. How should this be approached? Lyle Stephan (talk) 18:41, 5 November 2012 (UTC)

Be careful. There is a loose and a strict interpretation of a "one-time pad". In the strict interpretation, you need a truly random stream to encipher your data. In the loose interpretation, your stream may be pseudo-random, something what a stream cipher implements. In explanation, only a truly random key stream can provide you information-theoretic (perfect) secrecy, whereas a pseudo-random stream (such as provided by /dev/random) provides you computational security. The common principle is that you may use the key stream only once. Nageh (talk) 18:54, 5 November 2012 (UTC)
I need to slightly correct myself. /dev/random is meant to provide close-to-truly random output data. The extent to which it is random (in an information-theoretic sense) is debatable, but it does not provide "true" randomness. Nageh (talk) 20:37, 5 November 2012 (UTC)
I agree with you. I will try and find a source that will allow us to include the caveat that you mentioned. That should resolve it Lyle Stephan (talk) 15:50, 6 November 2012 (UTC)

Update needed[edit]

" They indicated that none of these /dev/random implementations were cryptographically secure because their outputs had uniformity flaws." The reference is dated from 8 years ago.I wonder if the flow still exists(They may be fixed now) in particular for linux Thanks.Ytrezq (talk) 19:59, 28 February 2013 (UTC)

Citation needed for OpenBSD arc4 section[edit]

Citation needed for OpenBSD arc4 section. IMHO, much of this article seems outdated or inaccurate. For example, I searched the OpenBSD mailing list, and I couldn't find any cited reference to the reason for the rc4 to arc4 rename. — Preceding unsigned comment added by Zacts (talkcontribs) 20:34, 13 May 2013 (UTC)

References adjusted. If somebody wants to update the whole section (e.g. correct use of present and past tense), here are the conference slides to look at: "arc4random - 1997 to present" --2001:638:401:102:250:56FF:FEB2:39C6 (talk) 07:43, 7 August 2015 (UTC)

Removed Weaknesses section[edit]

I removed the "Weaknesses" section. It was added by User:Landon Curt Noll, who also owns the website cited as a source. Seems to be WP:OR and cites a non-WP:RELY source, besides looking suspiciously like an advertisement (and probably being wrong). ManishEarthTalkStalk 22:19, 13 August 2013 (UTC)

Add /dev/urandom article[edit] seems to be relevant, maybe add it? — Preceding unsigned comment added by (talk) 07:28, 10 March 2014 (UTC)

Kroah-Hartmann and Torvalds seem to agree: — Preceding unsigned comment added by (talk) 21:17, 10 March 2014 (UTC)

FreeBSD switching from Yarrow to Fortuna[edit]

See; the relevant chapter of "Cryptography Engineering" can be downloaded for free from the author's site ( — Preceding unsigned comment added by (talk) 15:01, 5 November 2014 (UTC)


In Unix-like operating systems, /dev/random is a special file that serves as a blocking pseudorandom number generator. It allows access to environmental noise collected from device drivers and other sources.[1] Not all operating systems implement the same semantics for /dev/random.

I think this introduction and definition flawed out of multiple reasons:

  • It defines "/dev/random" as "blocking" on "Unix-like OS"
  • The citation is flawed for multiple reasons, too.

Ad (1): The article lists how /dev/random is handled on multiple (mainly Unix-like) Operating Systems. Seems in the majority of those /dev/random does not block indeed. A blocking /dev/random seams to be mainly a Linux characteristic -- which is okay as Linux (namely Ted T'so) "invented" it. But that should be stated explicitly, or the "blocking" characteristic should be removed.

Ad (2): The reference is Torvalds, Linus (2005-04-16). "Linux Kernel drivers/char/random.c comment documentation @ 1da177e4". On the one hand, the contents of the introduction of Linux random.c does not refer to "Unix-like Operating Systems", but to Linux specifically. On the other hand, the cited commit is not the one that created the text, but the one with which Linus /imported/ the file (among many others) from the previous repository into the "new" GIT one. Commit message: Initial git repository build. I'm not bothering with the full history, even though we have it. [..]" So Linus himself is probably /not/ the author. --2001:638:401:102:250:56FF:FEB2:39C6 (talk) 08:32, 30 July 2015 (UTC)

/dev/urandom is what you want to use for long-term cryptographic keys[edit]

"While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys."

This sentence needs to be expunged. It's misleading and based on complete bullshit.

Kobra (talk) 14:27, 29 September 2015 (UTC)

  1. ^ Torvalds, Linus (2005-04-16). "Linux Kernel drivers/char/random.c comment documentation @ 1da177e4". Retrieved 2014-07-22.