加载失败
这篇帖子讨论的是一篇 2014 年的 Linux 文章《Myths about /dev/urandom》，作者在 2024 年补注说：文章对 entropy 和 randomness 的原理仍然正确，但 Linux kernel 的随机数子系统已经重构了多次，今天看起来和当年不一样了。早期 Linux 依赖 entropy estimation 和分离的 `/dev/random`、`/dev/urandom` 接口，前者可能阻塞，后者不阻塞，因此长期引发“哪个更安全”的争论。现代实现更像一个 CSPRNG，会在启动阶段收集系统熵，再混合硬件来源和运行时噪声，很多场景下两者已经没有过去那么大的差别。这个话题之所以反复被讨论，是因为历史上确实发生过 Debian SSH key 生成、factorable.net 低熵密钥和 Android ASLR 低熵等真实问题，导致很多人的认知还停留在旧时代。
很多人先被这篇文章的结构劝退，抱怨事实和“神话”之间的分界几乎看不出来，读起来像在拆谜题。有人指出旧版网页和旧 CSS 更容易辨认段落层次，说明后来排版改动可能放大了混乱。也有人直接表示看不懂，甚至把阅读体验拿去和《Deadpool》相比。
评论普遍认为这篇 2014 年旧文在原理层面还成立，但 Linux kernel 的 random number generator 早已多次重写。现在的常见说法是：早期 boot 时 `/dev/random` 仍可能因为熵不足而阻塞，`/dev/urandom` 不阻塞；但一旦 `crng init done`，两者在现代 Linux 上基本可以互换。有人还补充，新的实现更接近 OpenBSD（一个以安全著称的类 Unix 系统）的思路，会把系统熵、RDRAND 和调度抖动等来源混合进 ChaCha20-based CSPRNG。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有人质疑 kernel PRNG 预测是否真算得上严重攻击面，认为在现代 OS 的各种攻击路径里它可能排得很后。回应则强调，这类问题一旦存在往往是结构性缺陷，爆雷时影响很大，而且曾经确实出现过 Debian SSH key generation fiasco、factorable.net 披露的低熵密钥可预测问题，以及 Android 的 ASLR 相关低熵漏洞。整体共识是：这不是纯粹的 security theater，但风险主要集中在老旧 kernel、早期启动阶段或配置不当的环境。
评论里反复贴出 2014、2015、2017、2018、2020 的旧讨论，说明关于 `/dev/random` 和 `/dev/urandom` 的误解并没有随着时间自动消失。有人直接追问 man page 是否已经修正，暗示官方文档可能还没有把现代行为讲清楚。还有人把问题延伸到短命的 isolated VMs 和云环境，说明真正难点不只是算法，而是不同运行场景能否稳定拿到高质量熵源。
/dev/random: Linux 的随机数设备之一，早期在熵不足时会阻塞，常被拿来讨论是否“更安全”.
/dev/urandom: Linux 的非阻塞随机数设备；在现代 kernel 完成初始化后，通常与 `/dev/random` 基本等价用于多数用途。
CSPRNG: cryptographically secure pseudo-random number generator，适合用于加密场景的伪随机数生成器。
entropy: 系统中可用的不确定性来源，用来给随机数生成器播种或补充随机性。
ChaCha20: 一种常用于现代随机数实现的流密码，也常被用作 RNG 的核心算法。
RDRAND: Intel CPU 提供的硬件随机数指令，常作为 entropy 来源之一。
VirtIO RNG: 虚拟机环境中的随机数来源接口，可由宿主机向 VM 提供高质量熵。