Talk:/dev/random

message: 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 (http://www.freebsd.org/cgi/man.cgi?query=random&apropos=0&sektion=4&manpath=FreeBSD+10.0-stable&arch=default&format=html) clearly states that /dev/{u,}random will block if there is not enough entropy and has done so since at least 5.0-RELEASE. 
https://wiki.freebsd.org/201308DevSummit/Security/DevRandom 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)
thread_title:  FreeBSD claims are wrong 

message: 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.
: 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)
thread_title:  Should this all really be in the FreeBSD section? 

message: 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)
replies: text: Sounds to me as if it's already overflowed into your brain. Wiseguy ;) Tualha (Talk) 17:46, 24 November 2006 (UTC)
thread_title:  How do we know... 

message: 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)
replies: text: 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)
thread_title:  Did you say "true random number generator" ? 

message: (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 17.209.4.116 (talk) 19:54, 13 July 2011 (UTC)
thread_title:  Writing to /dev/random 

message: 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: http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html#DESCRIPTION  — Preceding unsigned comment added by 66.76.35.131 (talk) 19:41, 31 July 2012 (UTC)
thread_title:  Citation for usage of device driver noise 

message: 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: http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html#DESCRIPTION , 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)
replies: text: 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)

text: 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)
replies: text: 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)
thread_title:  Cross-article contradiction 

message: " 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)
thread_title:  Update needed 

message: 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 (talk • contribs) 20:34, 13 May 2013 (UTC)
replies: text: 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)
thread_title:  Citation needed for OpenBSD arc4 section 

message: 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). ManishEarthTalk • Stalk 22:19, 13 August 2013 (UTC)
thread_title:  Removed Weaknesses section 

message: http://www.2uo.de/myths-about-urandom/ seems to be relevant, maybe add it?  — Preceding unsigned comment added by 217.237.185.168 (talk) 07:28, 10 March 2014 (UTC)
thread_title:  Add /dev/urandom article 

message: See https://svnweb.freebsd.org/base?view=revision&revision=273872; the relevant chapter of "Cryptography Engineering" can be downloaded for free from the author's site (https://www.schneier.com/fortuna.html)  — Preceding unsigned comment added by 79.6.154.127 (talk) 15:01, 5 November 2014 (UTC)
thread_title:  FreeBSD switching from Yarrow to Fortuna 

message: In Unix-like operating systems,  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. Not all operating systems implement the same semantics for .
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)
thread_title:  Introduction/Definition 

message: "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.
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
http://blog.cr.yp.to/20140205-entropy.html
Kobra (talk) 14:27, 29 September 2015 (UTC)
replies: text: The good news is that Linux also agrees and decided to change; the article is also fixed. The bad news is that the "complete bullshit" in the manual page has not been fixed. It's partly my fault: I sent a patch but got bored by the small code review requests. My manpage-writing computer holding a clone of the linux-man-pages git repo is also in a cold room; turning on the heat is a lot of bother. Artoria2e5 🌉 05:30, 6 February 2024 (UTC)

text: I think something was changed about entropy_avail too -- there used to be something that tracks "spent entropy", which of course is silly. It's not in my proposed revision of the manual, so some more source-reading is required to hunt that down. --Artoria2e5 🌉 05:47, 6 February 2024 (UTC)
thread_title:  /dev/urandom is what you want to use for long-term cryptographic keys 

message: I am not an expert in these matters, but I read that macOS no longer uses Yarrow. According to this post from /r/crypto, Craig Federighi said they now use CoreCrypto and, "The NDRNG feeds entropy from the pool into the DRBG on demand. The NDRNG provides 256-bits of entropy." He also provides a link to the official Apple documenation.
I don't know enough about this topic to properly edit the macOS section of this page. I'm providing this info so someone who knows more than me can update it.
Auctoris (talk) 21:16, 23 November 2019 (UTC)
thread_title:  macOS No Longer Uses Yarrow 

message: Linux kernel 5.4.53 mixes the CPU hardware random number generator with its entropy pool using exclusive-or. I don't know when this change was introduced into 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c
Must have been after this article arose (2017?). /drivers/char/hw_random contains hardware random number drivers for Intel, AMD, Atmel, Broadcom, Niagra2(Sparc), Via, OMAP, Octeon, VirtIO, Freescale, among others.
Assumptions based upon software deterministic random number generators must be updated. /dev/random is no longer correctly described in this article. XOR-ing non-deterministic ring-oscillator noise sources with timer-based entropy obsoletes this article's software-based random number focus.
https://www.amd.com/system/files/TechDocs/amd-random-number-generator.pdf
Hpfeil (talk) 19:28, 23 July 2020 (UTC)
thread_title:  Update needed 

message: depicts
depicted entity (see also P921: main subject)
depiction of  painting of  motif  portrait of  landscape of represents  portrays  subject depicting  pictures Crtn32002 (talk) 15:07, 25 March 2021 (UTC)
thread_title:  AKJK-Android-DATA  

message: A Wikipedia lead section should be accessible to as broad an audience as possible. As a user of random number generators, I was intrigued to find out more about how Linux handles them, but as I am not an expert in computer science, I was very confused by the terminology used in the lead. This is the first time I've come across 'blocking' and 'entropy' used in such a context. Would it be possible to come up with a more accessible lead and leave such terminology for the main text? 
Also, I suggest not starting the main text with an example. That would make more sense further down the page.
AstroMark (talk) 09:37, 7 February 2022 (UTC)
thread_title:  Confusing Lead