PRF:20161106 Myths about -dev-urandom.md

@Moelf 这篇翻译的很好，辛苦了。

translated/tech/20161106 Myths about -dev-urandom.md

@@ -11,33 +11,33 @@
 
 **`/dev/urandom` 是<ruby>伪随机数生成器<rt>pseudo random number generator</rt></ruby>（PRND），而 `/dev/random` 是“真”随机数生成器。**
 
-事实：它们两者本质上用的是同一种 CSPRNG （一种密码学伪随机数生成器）。它们之间细微的差别和“真”“不真”随机完全无关。
+*事实*：它们两者本质上用的是同一种 CSPRNG （一种密码学伪随机数生成器）。它们之间细微的差别和“真”“不真”随机完全无关。（参见：“Linux 随机数生成器的构架”一节）
 
 **`/dev/random` 在任何情况下都是密码学应用更好地选择。即便 `/dev/urandom` 也同样安全，我们还是不应该用它。**
 
-*事实*：`/dev/random` 有个很恶心人的问题：它是阻塞的。（LCTT 译注：意味着请求都得逐个执行，等待前一个请求完成）
+*事实*：`/dev/random` 有个很恶心人的问题：它是阻塞的。（参见：“阻塞有什么问题？”一节）（LCTT 译注：意味着请求都得逐个执行，等待前一个请求完成）
 
 **但阻塞不是好事吗！`/dev/random` 只会给出电脑收集的信息熵足以支持的随机量。`/dev/urandom` 在用完了所有熵的情况下还会不断吐出不安全的随机数给你。**
 
-*事实*：这是误解。就算我们不去考虑应用层面后续对随机种子的用法，“用完信息熵池”这个概念本身就不存在。仅仅 256 位的熵就足以生成计算上安全的随机数很长、很长的一段时间了。
+*事实*：这是误解。就算我们不去考虑应用层面后续对随机种子的用法，“用完信息熵池”这个概念本身就不存在。仅仅 256 位的熵就足以生成计算上安全的随机数很长、很长的一段时间了。（参见：“那熵池快空了的情况呢？”一节）
 
 问题的关键还在后头：`/dev/random` 怎么知道有系统会*多少*可用的信息熵？接着看！
 
 **但密码学家老是讨论重新选种子（re-seeding）。这难道不和上一条冲突吗？**
 
-*事实*：你说的也没错！某种程度上吧。确实，随机数生成器一直在使用系统信息熵的状态重新选种。但这么做（一部分）是因为别的原因。
+*事实*：你说的也没错！某种程度上吧。确实，随机数生成器一直在使用系统信息熵的状态重新选种。但这么做（一部分）是因为别的原因。（参见：“重新选种”一节）
 
 这样说吧，我没有说引入新的信息熵是坏的。更多的熵肯定更好。我只是说在熵池低的时候阻塞是没必要的。
 
 **好，就算你说的都对，但是 `/dev/(u)random` 的 man 页面和你说的也不一样啊！到底有没有专家同意你说的这堆啊？**
 
-*事实*：其实 man 页面和我说的不冲突。它看似好像在说 `/dev/urandom` 对密码学用途来说不安全，但如果你真的理解这堆密码学术语你就知道它说的并不是这个意思。
+*事实*：其实 man 页面和我说的不冲突。它看似好像在说 `/dev/urandom` 对密码学用途来说不安全，但如果你真的理解这堆密码学术语你就知道它说的并不是这个意思。（参见：“random 和 urandom 的 man 页面”一节）
 
 man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也没问题，但绝对不是说必要的），但它也推荐在大多数“一般”的密码学应用下使用 `/dev/urandom` 。
 
 虽然诉诸权威一般来说不是好事，但在密码学这么严肃的事情上，和专家统一意见是很有必要的。
 
-所以说呢，还确实有一些*专家*和我的一件事一致的：`/dev/urandom` 就应该是类 UNIX 操作系统下密码学应用的首选。显然的，是他们的观点说服了我而不是反过来的。
+所以说呢，还确实有一些*专家*和我的一件事一致的：`/dev/urandom` 就应该是类 UNIX 操作系统下密码学应用的首选。显然的，是他们的观点说服了我而不是反过来的。（参见：“正道”一节）
 
 ------
 
@@ -45,9 +45,9 @@ man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也
 
 我尝试不讲太高深的东西，但是有两点内容必须先提一下才能让我们接着论证观点。
 
-首当其冲的，*什么是随机性*，或者更准确地：我们在探讨什么样的随机性？
+首当其冲的，*什么是随机性*，或者更准确地：我们在探讨什么样的随机性？（参见：“真随机”一节）
 
-另外一点很重要的是，我*没有尝试以说教的态度*对你们写这段话。我写这篇文章是为了日后可以在讨论起的时候指给别人看。比 140 字长（LCTT 译注：推特长度）。这样我就不用一遍遍重复我的观点了。能把论点磨炼成一篇文章本身就很有助于将来的讨论。
+另外一点很重要的是，我*没有尝试以说教的态度*对你们写这段话。我写这篇文章是为了日后可以在讨论起的时候指给别人看。比 140 字长（LCTT 译注：推特长度）。这样我就不用一遍遍重复我的观点了。能把论点磨炼成一篇文章本身就很有助于将来的讨论。（参见：“你是在说我笨？！”一节）
 
 并且我非常乐意听到不一样的观点。但我只是认为单单地说 `/dev/urandom` 坏是不够的。你得能指出到底有什么问题，并且剖析它们。
 
@@ -55,7 +55,7 @@ man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也
 
 绝对没有！
 
-事实上我自己也相信了 “`/dev/urandom` 是不安全的” 好些年。这几乎不是我们的错，因为那么德高望重的人在 Usenet、论坛、推特上跟我们重复这个观点。甚至*连 man 手册*都似是而非地说着。我们当年怎么可能鄙视诸如“信息熵太低了”这种看上去就很让人信服的观点呢？
+事实上我自己也相信了 “`/dev/urandom` 是不安全的” 好些年。这几乎不是我们的错，因为那么德高望重的人在 Usenet、论坛、推特上跟我们重复这个观点。甚至*连 man 手册*都似是而非地说着。我们当年怎么可能鄙视诸如“信息熵太低了”这种看上去就很让人信服的观点呢？（参见：“random 和 urandom 的 man 页面”一节）
 
 整个流言之所以如此广为流传不是因为人们太蠢，而是因为但凡有点关于信息熵和密码学概念的人都会觉得这个说法很有道理。直觉似乎都在告诉我们这流言讲的很有道理。很不幸直觉在密码学里通常不管用，这次也一样。
 
@@ -123,25 +123,25 @@ man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也
 
 ![image: actual structure of the kernel's random number generator before Linux 4.8][2] 
 
-> 这是个很粗糙的简化。实际上不仅有一个，而是三个熵池。一个主池，另一个给 `/dev/random`，还有一个给 `/dev/urandom`，后两者依靠从主池里获取熵。这三个池都有各自的熵计数器，但二级池（后两个）的计数器基本都在 0 附近，而“新鲜”的熵总在需要的时候从主池流过来。同时还有好多混合和回流进系统在同时进行。整个过程对于这篇文档来说都过于复杂了我们跳过。
-
-你看到最大的区别了吗？CSPRNG 并不是和随机数生成器一起跑的，以 `/dev/urandom` 需要输出但熵不够的时候进行填充。CSPRNG 是整个随机数生成过程的内部组件之一。从来就没有什么 `/dev/random` 直接从池里输出纯纯的随机性。每个随机源的输入都在 CSPRNG 里充分混合和散列过了，这一切都发生在实际变成一个随机数，被 `/dev/urandom` 或者 `/dev/random` 吐出去之前。
+你看到最大的区别了吗？CSPRNG 并不是和随机数生成器一起跑的，它在 `/dev/urandom` 需要输出但熵不够的时候进行填充。CSPRNG 是整个随机数生成过程的内部组件之一。从来就没有什么 `/dev/random` 直接从池里输出纯纯的随机性。每个随机源的输入都在 CSPRNG 里充分混合和散列过了，这一切都发生在实际变成一个随机数，被 `/dev/urandom` 或者 `/dev/random` 吐出去之前。
 
 另外一个重要的区别是这里没有熵计数器的任何事情，只有预估。一个源给你的熵的量并不是什么很明确能直接得到的数字。你得预估它。注意，如果你太乐观地预估了它，那 `/dev/random` 最重要的特性——只给出熵允许的随机量——就荡然无存了。很不幸的，预估熵的量是很困难的。
 
-Linux 内核只使用事件的到达时间来预估熵的量。它通过多项式插值，某种模型，来预估实际的到达时间有多“出乎意料”。这种多项式插值的方法到底是不是好的预估熵量的方法本身就是个问题。同时硬件情况会不会以某种特定的方式影响到达时间也是个问题。而所有硬件的取样率也是个问题，因为这基本上就直接决定了随机数到达时间的颗粒度。
+> 这是个很粗糙的简化。实际上不仅有一个，而是三个熵池。一个主池，另一个给 `/dev/random`，还有一个给 `/dev/urandom`，后两者依靠从主池里获取熵。这三个池都有各自的熵计数器，但二级池（后两个）的计数器基本都在 0 附近，而“新鲜”的熵总在需要的时候从主池流过来。同时还有好多混合和回流进系统在同时进行。整个过程对于这篇文档来说都过于复杂了，我们跳过。
+
+Linux 内核只使用事件的到达时间来预估熵的量。根据模型，它通过多项式插值来预估实际的到达时间有多“出乎意料”。这种多项式插值的方法到底是不是好的预估熵量的方法本身就是个问题。同时硬件情况会不会以某种特定的方式影响到达时间也是个问题。而所有硬件的取样率也是个问题，因为这基本上就直接决定了随机数到达时间的颗粒度。
 
 说到最后，至少现在看来，内核的熵预估还是不错的。这也意味着它比较保守。有些人会具体地讨论它有多好，这都超出我的脑容量了。就算这样，如果你坚持不想在没有足够多的熵的情况下吐出随机数，那你看到这里可能还会有一丝紧张。我睡的就很香了，因为我不关心熵预估什么的。
 
-最后强调一下终点：`/dev/random` 和 `/dev/urandom` 都是被同一个 CSPRNG 喂的输入。只有它们在用完各自熵池（根据某种预估标准）的时候，它们的行为会不同：`/dev/random` 阻塞，`/dev/urandom` 不阻塞。
+最后要明确一下：`/dev/random` 和 `/dev/urandom` 都是被同一个 CSPRNG 饲喂的。只有它们在用完各自熵池（根据某种预估标准）的时候，它们的行为会不同：`/dev/random` 阻塞，`/dev/urandom` 不阻塞。
 
 ##### Linux 4.8 以后
 
-在 Linux 4.8 里，`/dev/random` 和 `/dev/urandom` 的等价性被放弃了。现在 `/dev/urandom` 的输出不来自于熵池，而是直接从 CSPRNG 来。
-
 ![image: actual structure of the kernel's random number generator from Linux 4.8 onward][3]
 
-*我们很快会理解*为什么这不是一个安全问题。
+在 Linux 4.8 里，`/dev/random` 和 `/dev/urandom` 的等价性被放弃了。现在 `/dev/urandom` 的输出不来自于熵池，而是直接从 CSPRNG 来。
+
+*我们很快会理解*为什么这不是一个安全问题。（参见：“CSPRNG 没问题”一节）
 
 ### 阻塞有什么问题？
 
@@ -149,7 +149,7 @@ Linux 内核只使用事件的到达时间来预估熵的量。它通过多项
 
 这些都是问题。阻塞本质上会降低可用性。换而言之你的系统不干你让它干的事情。不用我说，这是不好的。要是它不干活你干嘛搭建它呢？
 
-> 我在工厂自动化里做过和安全相关的系统。猜猜看安全系统失效的主要原因是什么？被错误操作。就这么简单。很多安全措施的流程让工人恼火了。比如时间太长，或者太不方便。你要知道人很会找捷径来“解决”问题。
+> 我在工厂自动化里做过和安全相关的系统。猜猜看安全系统失效的主要原因是什么？操作问题。就这么简单。很多安全措施的流程让工人恼火了。比如时间太长，或者太不方便。你要知道人很会找捷径来“解决”问题。
 
 但其实有个更深刻的问题：人们不喜欢被打断。它们会找一些绕过的方法，把一些诡异的东西接在一起仅仅因为这样能用。一般人根本不知道什么密码学什么乱七八糟的，至少正常的人是这样吧。
 
@@ -157,23 +157,23 @@ Linux 内核只使用事件的到达时间来预估熵的量。它通过多项
 
 到头来如果东西太难用的话，你的用户就会被迫开始做一些降低系统安全性的事情——你甚至不知道它们会做些什么。
 
-我们很容易会忽视可用性之类的重要性。毕竟安全第一对吧？所以比起牺牲安全，不可用，难用，不方便都是次要的？
+我们很容易会忽视可用性之类的重要性。毕竟安全第一对吧？所以比起牺牲安全，不可用、难用、不方便都是次要的？
 
 这种二元对立的想法是错的。阻塞不一定就安全了。正如我们看到的，`/dev/urandom` 直接从 CSPRNG 里给你一样好的随机数。用它不好吗！
 
 ### CSPRNG 没问题
 
-现在情况听上去很沧桑。如果连高质量的 `/dev/random` 都是从一个 CSPRNG 里来的，我们怎么敢在高安全性的需求上使用它呢？
+现在情况听上去很惨淡。如果连高质量的 `/dev/random` 都是从一个 CSPRNG 里来的，我们怎么敢在高安全性的需求上使用它呢？
 
-实际上，“看上去随机”是现存大多数密码学基础组件的基本要求。如果你观察一个密码学哈希的输出，它一定得和随机的字符串不可区分，密码学家才会认可这个算法。如果你生成一个块加密，它的输出（在你不知道密钥的情况下）也必须和随机数据不可区分才行。
+实际上，“看上去随机”是现存大多数密码学基础组件的基本要求。如果你观察一个密码学哈希的输出，它一定得和随机的字符串不可区分，密码学家才会认可这个算法。如果你生成一个分组加密，它的输出（在你不知道密钥的情况下）也必须和随机数据不可区分才行。
 
-如果任何人能比暴力穷举要更有效地破解一个加密，比如它利用了某些 CSPRNG 伪随机的弱点，那这就又是老一套了：一切都废了，也别谈后面的了。块加密、哈希，一切都是基于某个数学算法，比如 CSPRNG。所以别害怕，到头来都一样。
+如果任何人能比暴力穷举要更有效地破解一个加密，比如它利用了某些 CSPRNG 伪随机的弱点，那这就又是老一套了：一切都废了，也别谈后面的了。分组加密、哈希，一切都是基于某个数学算法，比如 CSPRNG。所以别害怕，到头来都一样。
 
 ### 那熵池快空了的情况呢？
 
 毫无影响。
 
-加密算法的根基建立在攻击者不能预测输出上，只要最一开始有足够的随机性（熵）就行了。一般的下限是 256 位，不需要更多了。
+加密算法的根基建立在攻击者不能预测输出上，只要最一开始有足够的随机性（熵）就行了。“足够”的下限可以是 256 位，不需要更多了。
 
 介于我们一直在很随意的使用“熵”这个概念，我用“位”来量化随机性希望读者不要太在意细节。像我们之前讨论的那样，内核的随机数生成器甚至没法精确地知道进入系统的熵的量。只有一个预估。而且这个预估的准确性到底怎么样也没人知道。
 
@@ -211,7 +211,7 @@ Linux 内核只使用事件的到达时间来预估熵的量。它通过多项
 
 我们在回到 man 页面说：“使用 `/dev/random`”。我们已经知道了，虽然 `/dev/urandom` 不阻塞，但是它的随机数和 `/dev/random` 都是从同一个 CSPRNG 里来的。
 
-如果你真的需要信息论理论上安全的随机数（你不需要的，相信我），那才有可能成为唯一一个你需要等足够熵进入 CSPRNG 的理由。而且你也不能用 `/dev/random`。
+如果你真的需要信息论安全性的随机数（你不需要的，相信我），那才有可能成为唯一一个你需要等足够熵进入 CSPRNG 的理由。而且你也不能用 `/dev/random`。
 
 man 页面有毒，就这样。但至少它还稍稍挽回了一下自己：
 
@@ -227,7 +227,7 @@ man 页面有毒，就这样。但至少它还稍稍挽回了一下自己：
 
 ### 正道
 
-本篇文章里的观点显然在互联网上是“小众”的。但如果问问一个真正的密码学家，你很难找到一个认同阻塞 `/dev/random` 的人。
+本篇文章里的观点显然在互联网上是“小众”的。但如果问一个真正的密码学家，你很难找到一个认同阻塞 `/dev/random` 的人。
 
 比如我们看看 [Daniel Bernstein][5]（即著名的 djb）的看法：
 
@@ -238,8 +238,6 @@ man 页面有毒，就这样。但至少它还稍稍挽回了一下自己：
 >
 > 对密码学家来说这甚至都不好笑了
 
-
-
 或者 [Thomas Pornin][6] 的看法，他也是我在 stackexchange 上见过最乐于助人的一位：
 
 > 简单来说，是的。展开说，答案还是一样。`/dev/urandom` 生成的数据可以说和真随机完全无法区分，至少在现有科技水平下。使用比 `/dev/urandom` “更好的“随机性毫无意义，除非你在使用极为罕见的“信息论安全”的加密算法。这肯定不是你的情况，不然你早就说了。
@@ -260,13 +258,13 @@ Linux 的 `/dev/urandom` 会很乐意给你吐点不怎么随机的随机数，
 
 FreeBSD 的行为更正确点：`/dev/random` 和 `/dev/urandom` 是一样的，在系统启动的时候 `/dev/random` 会阻塞到有足够的熵为止，然后它们都再也不阻塞了。
 
-> 与此同时 Linux 实行了一个新的<ruby>系统调用<rt>syscall</rt></ruby>，最早由 OpenBSD 引入叫 `getentrypy(2)`，在 Linux 下这个叫 `getrandom(2)`。这个系统调用有着上述正确的行为：阻塞到有足够的熵为止，然后再也不阻塞了。当然，这是个系统调用，而不是一个字节设备（LCTT 译注：指不在 `/dev/` 下），所以它在 shell 或者别的脚本语言里没那么容易获取。这个系统调用 自 Linux 3.17 起存在。
+> 与此同时 Linux 实行了一个新的<ruby>系统调用<rt>syscall</rt></ruby>，最早由 OpenBSD 引入叫 `getentrypy(2)`，在 Linux 下这个叫 `getrandom(2)`。这个系统调用有着上述正确的行为：阻塞到有足够的熵为止，然后再也不阻塞了。当然，这是个系统调用，而不是一个字节设备（LCTT 译注：不在 `/dev/` 下），所以它在 shell 或者别的脚本语言里没那么容易获取。这个系统调用 自 Linux 3.17 起存在。
 
-在 Linux 上其实这个问题不太大，因为 Linux 发行版会在启动的过程中储蓄一点随机数（这发生在已经有一些熵之后，因为启动程序不会在按下电源的一瞬间就开始运行）到一个种子文件中，以便系统下次启动的时候读取。所以每次启动的时候系统都会从上一次会话里带一点随机性过来。
+在 Linux 上其实这个问题不太大，因为 Linux 发行版会在启动的过程中保存一点随机数（这发生在已经有一些熵之后，因为启动程序不会在按下电源的一瞬间就开始运行）到一个种子文件中，以便系统下次启动的时候读取。所以每次启动的时候系统都会从上一次会话里带一点随机性过来。
 
 显然这比不上在关机脚本里写入一些随机种子，因为这样的显然就有更多熵可以操作了。但这样做显而易见的好处就是它不用关心系统是不是正确关机了，比如可能你系统崩溃了。
 
-而且这种做法在你真正第一次启动系统的时候也没法帮你随机，不过好在系统安装器一般会写一个种子文件，所以基本上问题不大。
+而且这种做法在你真正第一次启动系统的时候也没法帮你随机，不过好在 Linux 系统安装程序一般会保存一个种子文件，所以基本上问题不大。
 
 虚拟机是另外一层问题。因为用户喜欢克隆它们，或者恢复到某个之前的状态。这种情况下那个种子文件就帮不到你了。