Linux /dev/random 被认为是真正随机的吗？

Is /dev/random considered truly random?

提问by seriousdev

For instance, could it be used to generate a one-time pad key?
Also, what are its sources and how could it be used to generate a random number between xand y?

例如，它可以用于生成一次性键盘密钥吗？
此外，它的来源是什么以及如何使用它来生成x和y之间的随机数？

采纳答案by Andrey

The only thing in this universe that can be considered truly is one based on quantum effects. Common example is radioactive decay. For certain atoms you can be sure only about half-life, but you can't be sure which nucleus will break up next.

这个宇宙中唯一可以真正被认为是基于量子效应的。常见的例子是放射性衰变。对于某些原子，您只能确定其半衰期，但您无法确定下一个原子核会分解。

About /dev/random- it depends on implementation. In Linux it uses as entropy sources:

关于/dev/random- 这取决于实现。在 Linux 中，它用作熵源：

The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom.

Linux 内核根据键盘计时、鼠标移动和 IDE 计时生成熵，并通过特殊文件 /dev/random 和 /dev/urandom 将随机字符数据提供给其他操作系统进程。

Wiki

维基

It means that it is better than algorithmic random generators, but it is not perfect as well. The entropy may not be distributed randomly and can be biased.

这意味着它比算法随机生成器更好，但也不完美。熵可能不是随机分布的，可能有偏差。

This was philosophy. Practice is that on Linux /dev/randomis random enough for vast majority of tasks.

这就是哲学。实践是，在 Linux/dev/random上对于绝大多数任务来说是足够随机的。

There are implementations of random generators that have more entropy sources, including noise on audio inputs, CPU temperature sensors etc. Anyway they are not true.

有一些随机生成器的实现具有更多的熵源，包括音频输入上的噪声、CPU 温度传感器等。无论如何它们都不是真的。

There is interesting site where you can get Genuine random numbers, generated by radioactive decay.

有一个有趣的站点，您可以在其中获得由放射性衰变生成的真正随机数。

回答by Jonathan

/dev/randomwill block if there's not enough random data in the entropy poolwhereas /dev/urandomwill not. Instead, /dev/urandomwill fall back to a PRNG (kernel docs). From the same docs:

/dev/random如果熵池中没有足够的随机数据，则会阻塞，而/dev/urandom不会。相反，/dev/urandom将回退到 PRNG（内核文档）。来自相同的文档：

The random number generator [entropy pool] gathers environmental noise from device drivers and other sources into an entropy pool.

随机数生成器 [熵池] 将来自设备驱动程序和其他来源的环境噪声收集到一个熵池中。

So /dev/randomis not algorithmic, like a PRNG, but it may not be "truly random" either. Mouse movements and keystroke timings tend to follow patterns and can be used for exploitsbut you'll have to weigh the risk against your use case.

所以/dev/random不是算法，就像 PRNG 一样，但它也可能不是“真正随机的”。鼠标移动和击键时间往往遵循模式，可用于漏洞利用，但您必须权衡风险与您的用例。

To get a random number between xand yusing /dev/random, assuming you're happy with a 32-bit integer, you could have a look at the way the Java java.util.Random class does it(nextInt()), substituting in appropriate code to read from /dev/randomfor the nextBytes()method.

要在x和yusing之间获取随机数/dev/random，假设您对 32 位整数感到满意，您可以查看 Java java.util.Random 类的执行方式( nextInt())，替换为适当的代码以读取/dev/randomfor的nextBytes()方法。

回答by Thomas Pornin

Strictly speaking, /dev/randomis not reallycompletely random. /dev/randomfeeds on hardware sources which are assumedto be impredictible in some way; then it mixes such data using functions (hash functions, mostly) which are also assumedto be one-way. So the "true randomness" of /dev/randomis thus relative to the inherent security of the mixing functions, security which is no more guaranteed than that of any other cryptographic primitive, in particular the PRNG hidden in /dev/urandom.

严格来说，/dev/random并不是真的完全随机。以在某些方面/dev/random被认为是不可预测的硬件资源为食；然后它使用函数（主要是散列函数）混合这些数据，这些函数也被认为是单向的。因此， 的“真正随机性”/dev/random与混合函数的固有安全性有关，安全性不比任何其他密码原语的安全性更有保证，尤其是隐藏在/dev/urandom.

The difference between /dev/randomand /dev/urandomis that the former will try to maintain an estimate (which means "a wild guess") of how much entropy it has gathered, and will refuse to output more bits than that. On the other hand, /dev/urandomwill happily produce megabytes of data from the entropy it has.

/dev/random和之间的区别在于，/dev/urandom前者将尝试保持对其收集的熵的估计（这意味着“疯狂的猜测”），并且将拒绝输出比这更多的位。另一方面，它/dev/urandom会很高兴地从它拥有的熵中产生兆字节的数据。

The security difference between the two approaches is meaningless unless you assume that "classical" cryptographic algorithms can be broken, and you use one of the very few information-theoretic algorithms (e.g. OTPor Shamir's secret sharing); and, even then, /dev/randommay be considered as more secure than /dev/urandomonly if the mixing functions are still considered to be one-way, which is not compatible with the idea that a classical cryptographic algorithm can be broken. So, in practice and even in theory, no difference whatsoever. You can use the output of /dev/urandomfor an OTP and it will not be broken because of any structure internal to /dev/urandom-- actual management of the obtained stream will be the weak point (especially long-time storage). On the other hand, /dev/randomhas very real practical issues, namely that it can block at untimely instants. It is really irksome when an automated OS install blocks (for hours !) because SSH server key generation insists on using /dev/randomand needlessly stalls for entropy.

除非您假设“经典”密码算法可以被破解，并且您使用极少数信息论算法之一（例如OTP或Shamir 的秘密共享），否则这两种方法之间的安全差异是没有意义的；并且，即使这样，/dev/random也可能被认为比/dev/urandom仅当混合函数仍然被认为是单向的更安全，这与经典密码算法可以被破解的想法不兼容。因此，在实践中甚至在理论上，没有任何区别。您可以使用/dev/urandomOTP的输出，并且它不会因为任何内部结构而被破坏/dev/urandom- 获得的流的实际管理将是弱点（尤其是长时间存储）。另一方面，/dev/random有非常现实的实际问题，即它可以在不合时宜的瞬间阻塞。当自动操作系统安装阻塞（几个小时！）时真的很烦人，因为 SSH 服务器密钥生成坚持使用/dev/random并且不必要地停止熵。

There are many applications which read /dev/randomas a kind of ritual, as if it was "better" than /dev/urandom, probably on a karmic level. This is plain wrong, especially when the alea is to be used with classical cryptographic algorithms (e.g. to generate a SSH server public key). Do not do that. Instead, use /dev/urandomand you will live longer and happier. Even for one-time pad.

有许多应用程序读/dev/random作一种仪式，好像它比“更好” /dev/urandom，可能在业力水平上。这是完全错误的，尤其是当 alea 与经典加密算法一起使用时（例如生成 SSH 服务器公钥）。不要那样做。相反，使用/dev/urandom，你会活得更久、更快乐。即使是一次性垫。

(Just for completeness, there isa quirk with /dev/urandomas implemented on Linux: it will never block, even if it has not gathered any entropy at all since previous boot. Distributions avoid this problem by creating a "random seed" at installation time, with /dev/random, and using that seed at each boot to initialize the PRNG used by /dev/urandom; a new random seed is regenerated immediately, for next boot. This ensures that /dev/urandomalways works over a sufficiently big internal seed. The FreeBSD implementation of /dev/urandomwill block until a given entropy threshold is reached, which is safer.)

（只是为了保持完整性，有是有怪癖/dev/urandom在Linux上实现的：它绝不会阻止，即使它并没有因为先前的引导收集的任何熵都分布避免通过创建一个“随机种子”这个问题在安装时，使用。/dev/random, 并在每次启动时使用该种子来初始化由 使用的 PRNG /dev/urandom; 立即重新生成新的随机种子，用于下次启动。这确保/dev/urandom始终在足够大的内部种子上工作。FreeBSD 实现/dev/urandom将阻塞，直到给定的熵阈值达到了，这样更安全。）