我目前正在gpg --genkeyLinux 虚拟机上进行测试。不幸的是，这个软件似乎依赖于/dev/random收集熵，并礼貌地要求用户在加密随机输入屏幕后手动键入屏幕，因此它最终可能会生成密钥，而且我发现没有命令行参数可以告诉它使用另一个文件作为熵源（那个家伙在此视频中遇到同样的问题...）。
但是，用户应该可以自由选择使用/dev/urandom因为没有什么问题。它主要是作为对较旧的 PRNG 算法的回忆，从密码学的角度来看，这些算法较弱。例如，虽然NetBSD 联机帮助页承认这种区别在很早的启动阶段仍然有用，它描述了这样的区别：“民俗学”和“仅防御幻想威胁模型的想象理论”。没有人同意该命令所需的熵量也没有事实证明熵是实际消耗的东西，如GPG 联机帮助页（“请不要使用此命令，除非您知道自己在做什么，它可能会从系统中删除宝贵的熵！”）。
我读过关于人们安装rngd守护进程并将其配置为用作/dev/urandom供给的熵源/dev/random，但我发现这种做法非常肮脏。
我尝试以 FreeBSD 方式解决该问题，将/dev/random其删除并链接到/dev/urandom：
rm /dev/random
ln -s /dev/urandom /dev/random
我认为这就像一个背景在讲述“我相信/dev/urandom作为熵源”。
我担心我会遇到某种错误，但这似乎提供了预期的结果，因为命令现在立即成功返回。
我的问题是：/dev/random在 Linux 系统上链接到/dev/urandomFreeBSD 系统默认情况下是否有任何已知的、实际的和错误的副作用？或者是否可以设想永久设置此设置（例如在启动过程结束时的脚本中），以防由于/dev/random锁定某些服务而出现重复问题？
答案1
看关于乌兰多姆的神话，没有已知的对 /dev/urandom 的攻击不会也是对 /dev/random 的攻击。 Linux 系统的主要问题是当它克隆并作为多个虚拟机运行时，克隆后没有重置保存的熵池。这是一个与你想要的相切的极端情况。
答案2
有一件事不同的是，/dev/random它在使用熵池后停止输出。尝试这个：
$ cat /dev/random
(a few short lines of gibberish)^C
$
/dev/urandom但是将重用同一个池来继续输出。如图所示：
$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$
（当您尝试捕获这些特殊设备时，您的提示可能会混乱。只需键入reset并输入，您的终端就会恢复正常）
/dev/urandom当您只需要用“随机”位的恒定流填充某些内容时使用。/dev/random用于需要绝对随机的密钥。
答案3
在 Linux 中，/dev/random提供高质量的随机位。它们的来源是不是可预测和不是可重复，在机器外部。相反，/dev/urandom使用与（如果可用）相同的随机数据/dev/random，如果没有，则使用伪随机数生成器，即确定性的。对于大多数目的来说，它是足够不可预测的，但是不是对于要求非常高的应用程序（如密码学），更不用说用于创建长期有效的密钥（如 GPG）。