Hi Philipp, hi Markus, Philip Guenther wrote on Sat, Oct 14, 2017 at 12:05:55AM -0700: > On Fri, Oct 13, 2017 at 11:54 PM, Mohammad BadieZadegan <mbzade...@gmail.com
>> arandom entropy is better than urandom and I need arandom for better >> entropy and better speed in comparison about /dev/random. > Umm, I don't understand. /dev/arandom was an OpenBSD "innovation" that we > have since regretted and rescinded: on modern OpenBSD, /dev/arandom and > /dev/urandom behave *exactly the same*. Go look in sys/dev/rnd.c and > you'll see that the minor device number is ignored. RTFS is all well and good, but trying to understand your postings, i also tried to RTFM. schwarze@isnote $ man urandom man: No entry for urandom in the manual. This is ungood. So i looked at random(4) and found multiple issues. * srandom and urandom are missing from NAME. That's particularly unfortunate for urandom(4) because that's the best of the four for portable software, IIUC. * I think we want a strong deprecation notice here, like for crypt(3). We usually put that at the top of the DESCRIPTION, such that people won't study all the text before realizing that they have to start over with a different page. * Given that these devices are only useful for (some situations) of portable code, it seems quite counter-productive to only talk about what OpenBSD does, and the failure to make clear which of the statements apply to OpenBSD only is even worse. * It should certainly be said that if at all, urandom(4) is the one to use. * There is no need to say twice that these devices produce high-quality random data. * Add the missing FILES entries. * Kill the reference to the deprecated random(3) APIs. * We don't need to get into the argument whether Linux is an operating system or just a kernel. Instead, we usually mention the release something first appeared in. But i'm too lazy to research Linux kernel version numbers, and maybe they are not even all that interesting, so i'm just putting the year. * Author names belong in AUTHORS, not HISTORY. Instead, HISTORY should say when ARC4 was introduced here. * It's weird to mention who implemented a former algorithm, but to not say the same for the current one. This patch in likely not perfect yet, there is more weirdness, but i don't know the best way to fix that. If this is a bad patch, i hope it triggers a good one. * Are the .Xr's to md5(3) and md5(9) still relevant? How does reading md5(3) and md5(9) potentially help somebody who is considering to use /dev/urandom? I'd like to delete these, but if we want to keep them, shouldn't we explain why they are relevant? * I strongly suspect the sentence "This is a cloned interface" is completely misplaced in HISTORY. But i'm not quite sure what it means and whether it is true, so i have no idea where to move it. Feedback? Or even an OK? Ingo Index: random.4 =================================================================== RCS file: /cvs/src/share/man/man4/random.4,v retrieving revision 1.31 diff -u -p -r1.31 random.4 --- random.4 10 Sep 2015 17:55:21 -0000 1.31 +++ random.4 14 Oct 2017 16:59:14 -0000 @@ -28,34 +28,62 @@ .Os .Sh NAME .Nm random , -.Nm arandom +.Nm arandom , +.Nm srandom , +.Nm urandom .Nd random data source devices .Sh SYNOPSIS .In sys/types.h .In dev/rndvar.h .Sh DESCRIPTION -The various +These devices are deprecated. +Use the +.Xr arc4random 3 +family of functions instead, which can be called in almost all +coding environments, including +.Xr pthreads 3 , +.Xr chroot 2 , +and +.Xr pledge 2 , +and which avoids accessing a device every time. +.Pp +On +.Ox , +all these various .Nm -devices produce high quality random output data. +devices behave identically and produce high quality pseudo-random +output data. Entropy data is collected from system activity (such as disk, network, and clock device interrupts), and then used to key the ChaCha stream cipher to generate the output. -All the random devices are expected to provide high quality -pseudo-random output data. .Pp +On other operating systems, some devices may exhibit various defects. +For example, +.Nm +and +.Nm srandom +might block, or +.Nm random +might only return data from hardware random generators. The -.Xr arc4random 3 -function in userland libraries should be used instead, as it works -without the need to access these devices every time. +.Nm arandom +variant is a deprecated +.Ox +extension that should no longer be used. +.Pp +If using one of these devices cannot be avoided in a portable +program, prefer +.Nm urandom . .Sh FILES .Bl -tag -width /dev/arandom -compact .It Pa /dev/random .It Pa /dev/arandom +.It Pa /dev/srandom +.It Pa /dev/urandom .El .Sh SEE ALSO .Xr arc4random 3 , .Xr md5 3 , -.Xr random 3 , .Xr amdpm 4 , .Xr glxsb 4 , .Xr pchb 4 , @@ -64,11 +92,17 @@ without the need to access these devices .Sh HISTORY A .Nm -device first appeared in the Linux operating system. +device first appeared in Linux in 1994. This is a cloned interface. .Pp -ARC4 routines added by David Mazieres. -Changed to use the ChaCha cipher in +ARC4 was first used in +.Ox 2.0 +and replaced by the ChaCha cipher in .Ox 5.5 . +.Sh AUTHORS +The ARC4 routines were added by +.An David Mazieres , +the ChaCha routines by +.An Markus Friedl Aq Mt mar...@openbsd.org . .Sh BUGS No randomness testing suite provided.
