document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-13 22:30:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF:20161106 Myths about -dev-urandom.md

Browse Source 
part
This commit is contained in:
Xingyu.Wang 2019-04-24 00:09:08 +08:00
parent d76189b874
commit 3a2cbdfb77
1 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
translated/tech/20161106 Myths about -dev-urandom.md
View File

@ -7,31 +7,31 @@
**`/dev/urandom` 不安全。加密用途必须使用 `/dev/random`** **`/dev/urandom` 不安全。加密用途必须使用 `/dev/random`**
事实：`/dev/urandom` 才是类 Unix 操作系统下推荐的加密种子。 *事实*：`/dev/urandom` 才是类 Unix 操作系统下推荐的加密种子。
**`/dev/urandom` 是<ruby>伪随机数生成器<rt>pseudo random number generator</rt></ruby>（PRND），而 `/dev/random` 是“真”随机数生成器。** **`/dev/urandom` 是<ruby>伪随机数生成器<rt>pseudo random number generator</rt></ruby>（PRND），而 `/dev/random` 是“真”随机数生成器。**
事实：它们两者本质上用的是同一种 CSPRNG （一种密码学伪随机数生成器）。它们之间细微的差别和“真”不“真”随机完全无关 事实：它们两者本质上用的是同一种 CSPRNG （一种密码学伪随机数生成器）。它们之间细微的差别和“真”“不真”随机完全无关。
**`/dev/random` 在任何情况下都是密码学应用更好地选择。即便 `/dev/urandom` 也同样安全，我们还是不应该用它。** **`/dev/random` 在任何情况下都是密码学应用更好地选择。即便 `/dev/urandom` 也同样安全，我们还是不应该用它。**
事实：`/dev/random` 有个很恶心人的问题：它是阻塞的。（LCTT 译注：意味着请求都得逐个执行，等待前一个请求完成） *事实*：`/dev/random` 有个很恶心人的问题：它是阻塞的。（LCTT 译注：意味着请求都得逐个执行，等待前一个请求完成）
**但阻塞不是好事吗！`/dev/random` 只会给出电脑收集的信息熵足以支持的随机量。`/dev/urandom` 在用完了所有熵的情况下还会不断吐不安全的随机数给你。** **但阻塞不是好事吗！`/dev/random` 只会给出电脑收集的信息熵足以支持的随机量。`/dev/urandom` 在用完了所有熵的情况下还会不断吐出不安全的随机数给你。**
事实：这是误解。就算我们不去考虑应用层面后续对随机种子的用法，“用完信息熵池”这个概念本身就不存在。仅仅 256 位的熵就足以生成计算上安全的随机数很长、很长的一段时间了。 *事实*：这是误解。就算我们不去考虑应用层面后续对随机种子的用法，“用完信息熵池”这个概念本身就不存在。仅仅 256 位的熵就足以生成计算上安全的随机数很长、很长的一段时间了。
问题的关键还在后头：`/dev/random` 怎么知道有系统会*多少*可用的信息熵？接着看！ 问题的关键还在后头：`/dev/random` 怎么知道有系统会*多少*可用的信息熵？接着看！
**但密码学家老是讨论重新选种子（re-seeding）。这难道不和上一条冲突吗？** **但密码学家老是讨论重新选种子（re-seeding）。这难道不和上一条冲突吗？**
事实：你说的也没错！某种程度上吧。确实，随机数生成器一直在使用系统信息熵的状态重新选种。但这么做（一部分）是因为别的原因。 *事实*：你说的也没错！某种程度上吧。确实，随机数生成器一直在使用系统信息熵的状态重新选种。但这么做（一部分）是因为别的原因。
这样说吧，我没有说引入新的信息熵是坏的。更多的熵肯定更好。我只是说在熵池低的时候阻塞是没必要的。 这样说吧，我没有说引入新的信息熵是坏的。更多的熵肯定更好。我只是说在熵池低的时候阻塞是没必要的。
**好，就算你说的都对，但是 `/dev/(u)random` 的 man 页面和你说的也不一样啊！到底有没有专家同意你说的这堆啊？** **好，就算你说的都对，但是 `/dev/(u)random` 的 man 页面和你说的也不一样啊！到底有没有专家同意你说的这堆啊？**
事实：其实 man 页面和我说的不冲突。它看似好像在说 `/dev/urandom` 对密码学用途来说不安全，但如果你真的理解这堆密码学术语你就知道它说的并不是这个意思。 *事实*：其实 man 页面和我说的不冲突。它看似好像在说 `/dev/urandom` 对密码学用途来说不安全，但如果你真的理解这堆密码学术语你就知道它说的并不是这个意思。
man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也没问题，但绝对不是说必要的），但它也推荐在大多数“一般”的密码学应用下使用 `/dev/urandom` 。 man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也没问题，但绝对不是说必要的），但它也推荐在大多数“一般”的密码学应用下使用 `/dev/urandom` 。
@ -61,13 +61,13 @@ man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也
### 真随机 ### 真随机
什么叫一个随机变量是“真随机的”？ 随机数是“真正随机”是什么意思？
我不想搞的太复杂以至于变成哲学范畴的东西。这种讨论很容易走偏因为随机模型大家见仁见智，讨论很快变得毫无意义。 我不想搞的太复杂以至于变成哲学范畴的东西。这种讨论很容易走偏因为对于随机模型大家见仁见智，讨论很快变得毫无意义。
在我看来“真随机”的“试金石”是量子效应。一个光子穿过或不穿过一个半透镜。或者观察一个放射性粒子衰变。这类东西是现实世界最接近真随机的东西。当然，有些人也不相信这类过程是真随机的，或者这个世界根本不存在任何随机性。这个就百家争鸣了，我也不好多说什么了。 在我看来“真随机”的“试金石”是量子效应。一个光子穿过或不穿过一个半透镜。或者观察一个放射性粒子衰变。这类东西是现实世界最接近真随机的东西。当然，有些人也不相信这类过程是真随机的，或者这个世界根本不存在任何随机性。这个就百家争鸣了，我也不好多说什么了。
密码学家一般都会通过不去讨论什么是“真随机”来避免这种争论。它们更关心的是<ruby>不可预测性<rt> unpredictability</rt></ruby>。只要没有*任何*方法能猜出下一个随机数就可以了。所以当你以密码学应用为前提讨论一个随机数好不好的时候，在我看来这才是最重要的。 密码学家一般都会通过不去讨论什么是“真随机”来避免这种哲学辩论。他们更关心的是<ruby>不可预测性<rt>unpredictability</rt></ruby>。只要没有*任何*方法能猜出下一个随机数就可以了。所以当你以密码学应用为前提讨论一个随机数好不好的时候，在我看来这才是最重要的。
无论如何，我不怎么关心“哲学上安全”的随机数，这也包括别人嘴里的“真”随机数。 无论如何，我不怎么关心“哲学上安全”的随机数，这也包括别人嘴里的“真”随机数。
@ -75,23 +75,23 @@ man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也
但就让我们退一步说，你有了一个“真”随机变量。你下一步做什么呢？ 但就让我们退一步说，你有了一个“真”随机变量。你下一步做什么呢？
你把它们打印出来然后挂在墙上来展示量子宇宙的美与和谐？牛逼！我很理解你。 你把它们打印出来然后挂在墙上来展示量子宇宙的美与和谐？牛逼！我支持你。
但是等等，你说你要*用*它们？做密码学用途？额，那这就废了，因为这事情就有点复杂了。 但是等等，你说你要*用*它们？做密码学用途？额，那这就废了，因为这事情就有点复杂了。
事情是这样的，你的真随机，量子力学加护的随机数即将被用进不理想的现实世界程序里。 事情是这样的，你的真随机、量子力学加护的随机数即将被用进不理想的现实世界算法里去。
因为我们使用的大多数算法并不是<ruby>理论信息学<rt>information-theoretic</rt></ruby>上安全的。它们“只能”提供 **计算意义上的安全**。我能想到为数不多的例外就只有 Shamir 密钥分享 和 One-time pad 算法。并且就算前者是名副其实的（如果你实际打算用的话），后者则毫无可行性可言。 因为我们使用的几乎所有的算法都并不是<ruby>信息论安全性<rt>information-theoretic security </rt></ruby>的。它们“只能”提供**计算意义上的安全**。我能想到为数不多的例外就只有 Shamir 密钥分享和<ruby>一次性密码本<rt>One-time pad</rt></ruby>（OTP）算法。并且就算前者是名副其实的（如果你实际打算用的话），后者则毫无可行性可言。
但所有那些大名鼎鼎的密码学算法，AES、RSA、Diffie-Hellman、椭圆曲线，还有所有那些加密软件包，OpenSSL、GnuTLS、Keyczar、你的操作系统的加密 API，都仅仅是计算意义上的安全的。 但所有那些大名鼎鼎的密码学算法，AES、RSA、Diffie-Hellman、椭圆曲线，还有所有那些加密软件包，OpenSSL、GnuTLS、Keyczar、你的操作系统的加密 API，都仅仅是计算意义上安全的。
那区别是什么呢？理论信息学上的安全肯定是安全的，绝对是，其它那些的算法都可能在理论上被拥有无限计算力的穷举破解。我们依然愉快地使用它们因为全世界的计算机加起来都不可能在宇宙年龄的时间里破解，至少现在是这样。而这就是我们文章里说的“不安全”。 那区别是什么呢？信息论安全的算法肯定是安全的，绝对是，其它那些的算法都可能在理论上被拥有无限计算力的穷举破解。我们依然愉快地使用它们是因为全世界的计算机加起来都不可能在宇宙年龄的时间里破解，至少现在是这样。而这就是我们文章里说的“不安全”。
除非哪个聪明的家伙破解了算法本身——在只需要极少量计算力的情况下。这也是每个密码学家梦寐以求的圣杯：破解 AES 本身、破解 RSA 本身等等。 除非哪个聪明的家伙破解了算法本身 —— 在只需要更少量计算力、在今天可实现的计算力的情况下。这也是每个密码学家梦寐以求的圣杯：破解 AES 本身、破解 RSA 本身等等。
所以现在我们来到了更底层的东西：随机数生成器，你坚持要“真随机”而不是“伪随机”。但是没过一会儿你的真随机数就被喂进了你极为鄙视的伪随机算法里了！ 所以现在我们来到了更底层的东西：随机数生成器，你坚持要“真随机”而不是“伪随机”。但是没过一会儿你的真随机数就被喂进了你极为鄙视的伪随机算法里了！
真相是，如果我们最先进的 hash 算法被破解了，或者最先进的块加密被破解了，你得到这些那些“哲学上不安全的”甚至无所谓了，因为反正你也没有安全的应用方法了。 真相是，如果我们最先进的哈希算法被破解了，或者最先进的分组加密算法被破解了，你得到的这些“哲学上不安全”的随机数甚至无所谓了，因为反正你也没有安全的应用方法了。
所以把计算性上安全的随机数喂给你的仅仅是计算性上安全的算法就可以了，换而言之，用 `/dev/urandom`。 所以把计算性上安全的随机数喂给你的仅仅是计算性上安全的算法就可以了，换而言之，用 `/dev/urandom`。
@ -103,7 +103,7 @@ man 页面确实说在一些情况下推荐使用 `/dev/random` （我觉得也
![image: mythical structure of the kernel's random number generator][1] ![image: mythical structure of the kernel's random number generator][1]
“真随机数”，尽管可能有点瑕疵，进入操作系统然后它的熵立刻被加入内部熵计数器。然后经过“矫偏”和“漂白”之后它进入内核的熵池，然后 `/dev/random` 和 `/dev/urandom` 从里面生成随机数。 “真正的随机性”，尽管可能有点瑕疵，进入操作系统然后它的熵立刻被加入内部熵计数器。然后经过“矫偏”和“漂白”之后它进入内核的熵池，然后 `/dev/random` 和 `/dev/urandom` 从里面生成随机数。
“真”随机数生成器，`/dev/random`，直接从池里选出随机数，如果熵计数器表示能满足需要的数字大小，那就吐出数字并且减少熵计数。如果不够的话，它会阻塞程序直至有足够的熵进入系统。 “真”随机数生成器，`/dev/random`，直接从池里选出随机数，如果熵计数器表示能满足需要的数字大小，那就吐出数字并且减少熵计数。如果不够的话，它会阻塞程序直至有足够的熵进入系统。