On / dev / urandom rumors end | Linux China
We had a lot of /dev/urandom and /dev/random rumors continue to circulate among the people. But rumors are rumors after all.
In this article we are for recent Linux operating system, and other Unix-like operating system will not be discussed within the range.
/dev/urandom Insecurity. Encryption purposes must be used /dev/random
Fact: /dev/urandom Recommended is the Unix-like operating system encryption seeds.
/dev/urandom Pseudo-random number generator pseudo random number generator (PRND), and /dev/randomis "true" random number generator.
Fact: They both are using essentially the same CSPRNG (one kind of cryptographic pseudorandom number generator). Nuances between them and the "real" "not true" random completely unrelated. (See: "Linux random number generator framework" a)
/dev/random Cryptography applications are better choice in any case. Even if /dev/urandom it's safe, we should not use it.
Fact: /dev/random There is a very sick person's problem: it is blocked. (See also: "Blocking What is the problem?" A) (LCTT Annotation: means that the request had executed one by one, waiting for the completion of a previous request)
But blocking is not a good thing it! /dev/random The information collected will only give the computer enough to support the entropy of a random amount. /dev/urandom In the case of run out of entropy will continue to spit insecure random number to you.
Fact: This is a misunderstanding. Even if we do not consider the application level subsequent usage of random seed, "run out of information entropy pool" concept itself does not exist. Only 256 of entropy is enough to generate a secure random number calculated on a long, long period of time. (See: "? That entropy pool is almost empty case it" one)
The key issue is yet to come: /dev/random how will know how much free information entropy of the system? Then look!
But cryptographers always discuss the re-election seed (re-seeding). Is not this a conflict and on it?
Fact: You're also right! To some extent it. Indeed, the random number generator has been using state of the system entropy re-selection. But to do so (part) because of other reasons. (See: "Re-selection" a)
Put it this way, I did not say that the introduction of new information entropy is bad. More entropy definitely better. I'm just saying when blocking low entropy pool is not necessary.
Well, even if you say all right, but /dev/(u)random the man pages are not the same and you say ah! In the end there are no experts agree with you that this heap ah?
Fact: In fact, man pages, and I said do not conflict. It looks as if to say /dev/urandom on the use of cryptography is unsafe, but if you really understand this pile password academic language you know what it says is not what it means. (See: "random and urandom the man page" a)
man page did say in some cases recommended /dev/random (I think it is no problem, but definitely not to say necessary), but it is also recommended to use in most "normal" of cryptography applications /dev/urandom .
While appealing to authority in general is not a good thing, but on cryptography such a serious matter, and expert consensus is necessary.
So I say, still does have some experts and one thing I consistent: /dev/urandom it should be the school of choice application passwords under UNIX-like operating systems. Obviously, the view is that they convinced me instead of vice versa. (See also: the "right way" a)
Hard to believe it? I certainly feel wrong? Read on to see if I can convince you.
I try not speak too deep stuff, but there are two elements must mention before we then demonstrate point of view.
Bear the brunt of what is random, or more precisely: we are discussing what kind of randomness? (See: "true random" a)
Another point is very important, I did not try to preach attitude towards you write these words. I write this article is to discuss the future can refer to when played for others to see. Than 140 word length (LCTT Annotation: Twitter length). So I do not have to repeat over and over again my point of view. Can the argument to temper article itself is very useful for future discussions. (See: "Are you saying I'm stupid?!" A)
And I am very happy to hear different opinions. But I just think just to say that /dev/urandom bad is not enough. You have to be able to point out in the end what is the problem, and analyze them.
Are you saying I'm stupid? !
Absolutely no!
I also believe the fact " /dev/urandom is not safe" for some years. This is hardly our fault, because then the highly respected people repeat this point of view with us on Usenet, forums, tweets. Even the man pages are specious talking. Then how could we despise, such as "information entropy is too low," this looks very convincing view? (See: "random and urandom the man page" a)
The whole rumor was so widespread not because people are stupid, but because it comes a little information about who will be the concept of entropy and cryptography think this argument makes sense. Intuition seems to tell us that rumors talking about makes sense. Unfortunately intuition in cryptology usually does not work, this is the same.
True random
Random number is "truly random" What does it mean?
I do not want to get too complicated to turn into something Philosophy. This discussion because it is easy to go the wrong stochastic model for all a matter of opinion, the discussion quickly becomes meaningless.
In my opinion "true random" and "touchstone" is a quantum effect. A photon passing through or not passing through a half mirror. Or a radioactive particle decay was observed. Such things are closest to the real world really random stuff. Of course, some people do not believe that this type of process is truly random, or the world does not exist any randomness. This would contend, and not a lot of what I say.
Cryptographers usually avoid this philosophical debate by not discussing what is "truly random." They are more concerned about the unpredictability unpredictability. As long as there is no way you can guess the next random number on it. So when you as a precondition to discuss the application of a cryptographic random number it really is good, in my opinion this is the most important.
Anyway, I do not care "safety philosophy" of random numbers, which also includes the "true" random number someone else's mouth.
Two security, a useful
But let us step back and say, you have a "true" random variable. What do you do next?
You print them out and hang on the wall to show the beauty and harmony of the quantum universe? Niubi! I'm with you.
But wait, you say you want to use them? Do cryptography use? Amount, that this waste, because this thing is a bit complicated.
The way it is, you really random, random quantum mechanics care is going to be used into the real world is not ideal algorithm go.
Because almost all the algorithms we use are not information-theoretic security of the information-theoretic security. They "only" to provide security in the computing sense. I can think of only one of the few exceptions Shamir key share and one-time pad One-time pad (OTP) algorithm. And even if the former is a true (if you actually intend to use it), the latter is no feasible at all.
But all those famous cryptographic algorithm, AES, RSA, Diffie-Hellman, elliptic curves, as well as all those encryption packages, OpenSSL, GnuTLS, Keyczar, your operating system's encryption API, are only calculated on the sense of security .
What difference is it? Information-theoretic security algorithm is certainly safe, absolutely, those other algorithms may be theoretically have unlimited computing power to crack exhaustive. We are still happily using computer together because they are all over the world can not break in time in the age of the universe, at least for now. And this is what we say in the article "unsafe."
Unless Which smart guy cracked the algorithm itself - just need more computing power in a small amount, in computing power can be achieved under today's circumstances. This is the Holy Grail of each cryptographers: AES itself crack, crack RSA itself, and so on.
So now we come to the bottom of something more: a random number generator, you insist on "true random" rather than "pseudo-random." But after a while you did not truly random numbers was fed into a pseudo-random algorithm you very despised in it!
The truth is, if we have the most advanced hashing algorithm is broken, or the most advanced block cipher was cracked, "unsafe philosophy" of these random number you get even does not matter, anyway, because you do not have safe application of the method.
So the security of random numbers on computational fed you calculate only on the security of the algorithm on it, in other words, use /dev/urandom.
Linux random number generator framework
A wrong view
You understand the random number generator of the kernel is likely to be something like this:
image: mythical structure of the kernel's random number generator
"True randomness", although perhaps a bit flawed, into the operating system and its entropy was immediately added to the internal counter entropy. Then after a "partial correction" and "bleaching" it into the kernel entropy pool, and then /dev/random , and /dev/urandom generates a random number from the inside.
"True" random number generator /dev/random, the random number is selected directly from the pool, if the counter indicates entropy needs to meet the size of the figures, it is discharged and reduced entropy digital count. If not, then it will block the program until there is enough entropy into the system.
Here is a very important part of /dev/random almost exclusively only after the necessary "bleaching" directly after those randomness into the system spit out, without distortion.
While /dev/urandom , things are the same. Except when there is not enough entropy, it does not block, but will from the pseudo-random number generator has been running (of course, is the safety of cryptography, CSPRNG) spit "low quality" of random numbers. The CSPRNG only use "true random number" seed production once (or several times, it does not matter), but you can not believe it special.
在这种对随机数生成的理解下，很多人会觉得在 Linux 下尽量避免 /dev/urandom 看上去有那么点道理。
因为要么你有足够多的熵，你会相当于用了 /dev/random。要么没有，那你就会从几乎没有高熵输入的 CSPRNG 那里得到一个低质量的随机数。
看上去很邪恶是吧？很不幸的是这种看法是完全错误的。实际上，随机数生成器的构架更像是下面这样的。
更好地简化
Linux 4.8 之前
image: actual structure of the kernel's random number generator before Linux 4.8
你看到最大的区别了吗？CSPRNG 并不是和随机数生成器一起跑的，它在 /dev/urandom 需要输出但熵不够的时候进行填充。CSPRNG 是整个随机数生成过程的内部组件之一。从来就没有什么 /dev/random 直接从池里输出纯纯的随机性。每个随机源的输入都在 CSPRNG 里充分混合和散列过了，这一切都发生在实际变成一个随机数，被 /dev/urandom 或者 /dev/random 吐出去之前。
另外一个重要的区别是这里没有熵计数器的任何事情，只有预估。一个源给你的熵的量并不是什么很明确能直接得到的数字。你得预估它。注意，如果你太乐观地预估了它，那 /dev/random最重要的特性——只给出熵允许的随机量——就荡然无存了。很不幸的，预估熵的量是很困难的。
这是个很粗糙的简化。实际上不仅有一个，而是三个熵池。一个主池，另一个给
/dev/random，还有一个给/dev/urandom，后两者依靠从主池里获取熵。这三个池都有各自的熵计数器，但二级池（后两个）的计数器基本都在 0 附近，而“新鲜”的熵总在需要的时候从主池流过来。同时还有好多混合和回流进系统在同时进行。整个过程对于这篇文档来说都过于复杂了，我们跳过。
Linux 内核只使用事件的到达时间来预估熵的量。根据模型，它通过多项式插值来预估实际的到达时间有多“出乎意料”。这种多项式插值的方法到底是不是好的预估熵量的方法本身就是个问题。同时硬件情况会不会以某种特定的方式影响到达时间也是个问题。而所有硬件的取样率也是个问题，因为这基本上就直接决定了随机数到达时间的颗粒度。
说到最后，至少现在看来，内核的熵预估还是不错的。这也意味着它比较保守。有些人会具体地讨论它有多好，这都超出我的脑容量了。就算这样，如果你坚持不想在没有足够多的熵的情况下吐出随机数，那你看到这里可能还会有一丝紧张。我睡的就很香了，因为我不关心熵预估什么的。
最后要明确一下：/dev/random 和 /dev/urandom 都是被同一个 CSPRNG 饲喂的。只有它们在用完各自熵池（根据某种预估标准）的时候，它们的行为会不同：/dev/random 阻塞，/dev/urandom 不阻塞。
Linux 4.8 以后
image: actual structure of the kernel's random number generator from Linux 4.8 onward
在 Linux 4.8 里，/dev/random 和 /dev/urandom 的等价性被放弃了。现在 /dev/urandom 的输出不来自于熵池，而是直接从 CSPRNG 来。
我们很快会理解为什么这不是一个安全问题。（参见：“CSPRNG 没问题”一节）
阻塞有什么问题？
你有没有需要等着 /dev/random 来吐随机数？比如在虚拟机里生成一个 PGP 密钥？或者访问一个在生成会话密钥的网站？
这些都是问题。阻塞本质上会降低可用性。换而言之你的系统不干你让它干的事情。不用我说，这是不好的。要是它不干活你干嘛搭建它呢？
我在工厂自动化里做过和安全相关的系统。猜猜看安全系统失效的主要原因是什么？操作问题。就这么简单。很多安全措施的流程让工人恼火了。比如时间太长，或者太不方便。你要知道人很会找捷径来“解决”问题。
但其实有个更深刻的问题：人们不喜欢被打断。它们会找一些绕过的方法，把一些诡异的东西接在一起仅仅因为这样能用。一般人根本不知道什么密码学什么乱七八糟的，至少正常的人是这样吧。
为什么不禁止调用 random()？为什么不随便在论坛上找个人告诉你用写奇异的 ioctl 来增加熵计数器呢？为什么不干脆就把 SSL 加密给关了算了呢？
到头来如果东西太难用的话，你的用户就会被迫开始做一些降低系统安全性的事情——你甚至不知道它们会做些什么。
我们很容易会忽视可用性之类的重要性。毕竟安全第一对吧？所以比起牺牲安全，不可用、难用、不方便都是次要的？
这种二元对立的想法是错的。阻塞不一定就安全了。正如我们看到的，/dev/urandom 直接从 CSPRNG 里给你一样好的随机数。用它不好吗！
CSPRNG 没问题
现在情况听上去很惨淡。如果连高质量的 /dev/random 都是从一个 CSPRNG 里来的，我们怎么敢在高安全性的需求上使用它呢？
实际上，“看上去随机”是现存大多数密码学基础组件的基本要求。如果你观察一个密码学哈希的输出，它一定得和随机的字符串不可区分，密码学家才会认可这个算法。如果你生成一个分组加密，它的输出（在你不知道密钥的情况下）也必须和随机数据不可区分才行。
如果任何人能比暴力穷举要更有效地破解一个加密，比如它利用了某些 CSPRNG 伪随机的弱点，那这就又是老一套了：一切都废了，也别谈后面的了。分组加密、哈希，一切都是基于某个数学算法，比如 CSPRNG。所以别害怕，到头来都一样。
那熵池快空了的情况呢？
毫无影响。
加密算法的根基建立在攻击者不能预测输出上，只要最一开始有足够的随机性（熵）就行了。“足够”的下限可以是 256 位，不需要更多了。
介于我们一直在很随意的使用“熵”这个概念，我用“位”来量化随机性希望读者不要太在意细节。像我们之前讨论的那样，内核的随机数生成器甚至没法精确地知道进入系统的熵的量。只有一个预估。而且这个预估的准确性到底怎么样也没人知道。
重新选种
但如果熵这么不重要，为什么还要有新的熵一直被收进随机数生成器里呢？
djb 提到 太多的熵甚至可能会起到反效果。
首先，一般不会这样。如果你有很多随机性可以拿来用，用就对了！
但随机数生成器时不时要重新选种还有别的原因：
想象一下如果有个攻击者获取了你随机数生成器的所有内部状态。这是最坏的情况了，本质上你的一切都暴露给攻击者了。
你已经凉了，因为攻击者可以计算出所有未来会被输出的随机数了。
但是，如果不断有新的熵被混进系统，那内部状态会再一次变得随机起来。所以随机数生成器被设计成这样有些“自愈”能力。
但这是在给内部状态引入新的熵，这和阻塞输出没有任何关系。
random 和 urandom 的 man 页面
这两个 man 页面在吓唬程序员方面很有建树：
从
/dev/urandom读取数据不会因为需要更多熵而阻塞。这样的结果是，如果熵池里没有足够多的熵，取决于驱动使用的算法，返回的数值在理论上有被密码学攻击的可能性。发动这样攻击的步骤并没有出现在任何公开文献当中，但这样的攻击从理论上讲是可能存在的。如果你的应用担心这类情况，你应该使用/dev/random。实际上已经有
/dev/random和/dev/urandom的 Linux 内核 man 页面的更新版本。不幸的是，随便一个网络搜索出现我在结果顶部的仍然是旧的、有缺陷的版本。此外，许多 Linux 发行版仍在发布旧的 man 页面。所以不幸的是，这一节需要在这篇文章中保留更长的时间。我很期待删除这一节！
没有“公开的文献”描述，但是 NSA 的小卖部里肯定卖这种攻击手段是吧？如果你真的真的很担心（你应该很担心），那就用 /dev/random 然后所有问题都没了？
然而事实是，可能某个什么情报局有这种攻击，或者某个什么邪恶黑客组织找到了方法。但如果我们就直接假设这种攻击一定存在也是不合理的。
而且就算你想给自己一个安心，我要给你泼个冷水：AES、SHA-3 或者其它什么常见的加密算法也没有“公开文献记述”的攻击手段。难道你也不用这几个加密算法了？这显然是可笑的。
我们在回到 man 页面说：“使用 /dev/random”。我们已经知道了，虽然 /dev/urandom不阻塞，但是它的随机数和 /dev/random 都是从同一个 CSPRNG 里来的。
如果你真的需要信息论安全性的随机数（你不需要的，相信我），那才有可能成为唯一一个你需要等足够熵进入 CSPRNG 的理由。而且你也不能用 /dev/random。
man 页面有毒，就这样。但至少它还稍稍挽回了一下自己：
如果你不确定该用
/dev/random还是/dev/urandom，那你可能应该用后者。通常来说，除了需要长期使用的 GPG/SSL/SSH 密钥以外，你总该使用/dev/urandom。该手册页的当前更新版本毫不含糊地说：
/dev/random接口被认为是遗留接口，并且/dev/urandom在所有用例中都是首选和足够的，除了在启动早期需要随机性的应用程序；对于这些应用程序，必须替代使用getrandom(2)，因为它将阻塞，直到熵池初始化完成。
行。我觉得没必要，但如果你真的要用 /dev/random 来生成 “长期使用的密钥”，用就是了也没人拦着！你可能需要等几秒钟或者敲几下键盘来增加熵，但这没什么问题。
但求求你们，不要就因为“你想更安全点”就让连个邮件服务器要挂起半天。
正道
本篇文章里的观点显然在互联网上是“小众”的。但如果问一个真正的密码学家，你很难找到一个认同阻塞 /dev/random 的人。
比如我们看看 Daniel Bernstein（即著名的 djb）的看法：
我们密码学家对这种胡乱迷信行为表示不负责。你想想，写
◈ (1) 我们不知道如何用一个 256 位长的/dev/randomman 页面的人好像同时相信：/dev/random的输出来生成一个无限长的随机密钥串流（这是我们需要/dev/urandom吐出来的），但与此同时◈ (2) 我们却知道怎么用单个密钥来加密一条消息（这是 SSL，PGP 之类干的事情）对密码学家来说这甚至都不好笑了
或者 Thomas Pornin 的看法，他也是我在 stackexchange 上见过最乐于助人的一位：
简单来说，是的。展开说，答案还是一样。
/dev/urandom生成的数据可以说和真随机完全无法区分，至少在现有科技水平下。使用比/dev/urandom“更好的“随机性毫无意义，除非你在使用极为罕见的“信息论安全”的加密算法。这肯定不是你的情况，不然你早就说了。urandom 的 man 页面多多少少有些误导人，或者干脆可以说是错的——特别是当它说
/dev/urandom会“用完熵”以及 “/dev/random是更好的”那几句话；
或者 Thomas Ptacek 的看法，他不设计密码算法或者密码学系统，但他是一家名声在外的安全咨询公司的创始人，这家公司负责很多渗透和破解烂密码学算法的测试：
用 urandom。用 urandom。用 urandom。用 urandom。用 urandom。
没有完美
/dev/urandom 不是完美的，问题分两层：
在 Linux 上，不像 FreeBSD，/dev/urandom 永远不阻塞。记得安全性取决于某个最一开始决定的随机性？种子？
Linux 的 /dev/urandom 会很乐意给你吐点不怎么随机的随机数，甚至在内核有机会收集一丁点熵之前。什么时候有这种情况？当你系统刚刚启动的时候。
FreeBSD 的行为更正确点：/dev/random 和 /dev/urandom 是一样的，在系统启动的时候 /dev/random 会阻塞到有足够的熵为止，然后它们都再也不阻塞了。
与此同时 Linux 实行了一个新的系统调用syscall，最早由 OpenBSD 引入叫
getentrypy(2)，在 Linux 下这个叫getrandom(2)。这个系统调用有着上述正确的行为：阻塞到有足够的熵为止，然后再也不阻塞了。当然，这是个系统调用，而不是一个字节设备（LCTT 译注：不在/dev/下），所以它在 shell 或者别的脚本语言里没那么容易获取。这个系统调用 自 Linux 3.17 起存在。
On Linux Actually, this is not too large, because Linux distributions will save one o'clock random number during startup (which has happened in some entropy after, because the program does not start by pressing the power began to run in the moment) to a seed file in order to read the next system start time. So every time you start when the system will come a little randomness from the last session inner tube.
Obviously, this can not compare with the write off some random seed in the script, because this is obviously have more entropy can operate. But this obvious benefit is that it is not concerned about the system is not properly shut down, such as your system may crash.
And this approach when you actually start the system for the first time also can not help you random, but fortunately Linux system installation program usually save a seed file, so basically no problem.
A virtual machine is another layer of problems. Because users like clone them, or revert to a previous state. In this case the seed file will not help you.
But the solution still use and /dev/random it does not matter, but you should be right for each clone or mirror recovery regenerate seed file.
Do not look too long
Do not ask, ask is to use /dev/urandom !
via: https://www.2uo.de/myths-about-urandom/
Author: Thomas Hühn Translator: Moelf proofread: wxy
This article compiled by the LCTT original, Linux is proud to offer Chinese