例如，它可以用于生成一次性密钥吗？ 此外，它的来源是什么以及它如何用于在 x 和 y 之间生成随机数？
答案 0 :(得分：25)
严格地说，/dev/random /dev/random以假设的硬件来源提供某种方式的不可预测性;然后它使用函数（主要是散列函数）混合这些数据，这些函数也是假设是单向的。因此/dev/random的“真正随机性”因此与混合函数的固有安全性相关，安全性不再比任何其他加密原语更安全，特别是隐藏在/dev/urandom中的PRNG。
/dev/random和/dev/urandom之间的区别在于前者会尝试维持一个估算（这意味着“疯狂的猜测”）它已经收集了多少熵，并拒绝输出更多比那个。另一方面，/dev/urandom将很乐意从它的熵中产生数兆字节的数据。
除非您假设“经典”加密算法可以被破解，并且您使用极少数信息理论算法之一（例如OTP或Shamir's secret sharing，否则两种方法之间的安全性差异毫无意义）;即使这样，只有当混合函数仍然被认为是单向的时，/dev/random才被认为比/dev/urandom更安全，这与经典加密算法可以是破碎。所以，在实践中，甚至在理论上，没有任何区别。您可以将/dev/urandom的输出用于OTP，并且由于/dev/urandom内部的任何结构，它不会被破坏 - 获得的流的实际管理将是弱点（尤其是长时间存储）。另一方面，/dev/random有非常实际的问题，即它可以在不合时宜的时刻阻止。当自动操作系统安装阻塞（数小时！）时真的很烦人，因为SSH服务器密钥生成坚持使用/dev/random并且不必要地停止熵。
有许多应用程序将/dev/random视为一种仪式，好像它比/dev/urandom“更好”，可能是在业力水平上。这是完全错误的，特别是当alea要与经典加密算法一起使用时（例如，生成SSH服务器公钥）。不要那样做。相反，使用/dev/urandom，你会活得更长，更快乐。即使是一次性垫。
（为了完整性，是在Linux上实现/dev/urandom的怪癖：它永远不会阻塞，即使它自上次启动后根本没有收集任何熵。通过在安装时使用/dev/random创建“随机种子”来避免此问题，并在每次启动时使用该种子初始化/dev/urandom使用的PRNG;立即重新生成新的随机种子，这确保/dev/urandom总是在足够大的内部种子上工作。/dev/urandom的FreeBSD实现将阻塞，直到达到给定的熵阈值，这样更安全。）
答案 1 :(得分：17)
这个宇宙中唯一可以真正考虑的是基于量子效应的东西。常见的例子是放射性衰变。对于某些原子，你可以确定只有半衰期，但你无法确定接下来哪个原子核会破裂。
关于/dev/random - 这取决于实施情况。在Linux中，它用作熵源：
Linux内核生成熵 从键盘时间，鼠标 动作，IDE时间和制作 可用的随机字符数据 其他操作系统进程 通过特殊文件/ dev / random 和/ dev / urandom。
这意味着它比算法随机生成器更好，但它也不完美。熵可能不是随机分布的，可能有偏差。
这是哲学。实践是在Linux上/dev/random对于绝大多数任务而言是随机的。
随机生成器的实现具有更多的熵源，包括音频输入，CPU温度传感器等的噪声。无论如何，它们不是 true 。
有一个有趣的网站，您可以获得Genuine random numbers, generated by radioactive decay。
答案 2 :(得分：1)
/dev/random将会阻止，而/dev/urandom则不会。相反，/dev/urandom将回归到PRNG（kernel docs）。来自相同的文档：
随机数发生器[熵池]将来自设备驱动程序和其他来源的环境噪声收集到熵池中。
所以/dev/random不是算法，就像PRNG一样，但也可能不是“真正随机”。鼠标移动和击键时间往往遵循模式can be used for exploits，但您必须权衡使用案例的风险。
要使用x获取y和/dev/random之间的随机数，假设您对32位整数感到满意，可以查看Java的方式{ {3}}（nextInt()），用适当的代码替换/dev/random nextBytes()方法。