例如，它是否可以用于生成一次一密 key ？
另外，它的来源是什么？如何使用它来生成介于 x 和 y 之间的随机数？
最佳答案
严格来说，/dev/random 不是真的完全随机的。 /dev/random 以假设在某种程度上不可预测的硬件资源为基础；然后它使用函数(主要是散列函数)混合这些数据，这些函数也被假定为单向的。因此，/dev/random 的“真正随机性”因此与混合函数的内在安全性相关，这种安全性并不比任何其他密码原语(尤其是隐藏在/dev/urandom.
/dev/random 和 /dev/urandom 之间的区别在于，前者将尝试维持一个估计(这意味着“疯狂猜测”)它已经收集了很多熵，并且将拒绝输出比这更多的比特。另一方面，/dev/urandom 将愉快地从它拥有的熵中产生数兆字节的数据。
这两种方法之间的安全差异是没有意义的，除非您假设“经典”密码算法可以被破解，并且您使用极少数信息论算法之一(例如 OTP 或 Shamir's secret sharing )；并且，即便如此，/dev/random 可能被认为比 /dev/urandom 更安全，前提是混合函数仍然被认为是单向的，这是与可以破解经典密码算法的想法不兼容。因此，在实践中，甚至在理论上，都没有任何区别。您可以将 /dev/urandom 的输出用于 OTP，它不会因为 /dev/urandom 内部的任何结构而被破坏——所获得的实际管理流将是弱点(尤其是长期存储)。另一方面，/dev/random 有非常实际的问题，即它可以在不合时宜的瞬间阻塞。当自动操作系统安装阻塞(数小时!)时真的很烦人，因为 SSH 服务器 key 生成坚持使用 /dev/random 并且不必要地停止熵。
有许多应用程序将 /dev/random 视为一种仪式，就好像它比 /dev/urandom“更好”，可能是因果报应等级。这是完全错误的，尤其是当 alea 与经典加密算法一起使用时(例如生成 SSH 服务器公钥)。不要那样做。相反，使用 /dev/urandom 你会活得更久、更快乐。即使是一次性一密本。
(只是为了完整起见，是在 Linux 上实现的 /dev/urandom 有一个怪癖:它永远不会阻塞，即使它没有收集任何熵所有自上次启动以来。发行版通过在安装时使用 /dev/random 创建“随机种子”来避免此问题，并在每次启动时使用该种子来初始化 /使用的 PRNG dev/urandom; 立即重新生成一个新的随机种子，用于下次启动。这确保 /dev/urandom 始终在足够大的内部种子上工作。 的 FreeBSD 实现/dev/urandom 将阻塞直到达到给定的熵阈值，这样更安全。)
关于linux -/dev/random 被认为是真正随机的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5635277/