如您所知，/ dev / random是一种加密强度高的伪随机数生成器（CSPRNG），存在一个令人不快的问题-阻塞。 本文介绍了如何解决它。
在过去的几个月中，在内核中生成随机数的方法已经稍作改进，但是该子系统中的问题已在更宽的
时间内得到解决。 进行了
最新更改 ，以防止在系统引导期间长时间阻塞getrandom（）系统调用，但是其背后的原因是阻塞随机池的行为。 最近的补丁程序将删除此池，并且可以预期它将进入主内核。
Andy Lutomirski于12月下旬发布了该补丁的第三版。 它对
随机Linux API进行了两个基本的语义改变 。 该补丁将新的GRND_INSECURE标志添加到getrandom（）系统调用中（尽管Lutomirsky将其称为getentropy（），这在glibc中使用带有固定标志的getrandom（）实现）； 该标志强制调用始终返回请求的数据量，但不保证数据是随机的。 内核将尽力提供给定时间的最佳随机数据。
“也许您能做的最好的事情就是将其称为“ INSECURE” （不安全），以防止将其用于需要安全的事物。”
修补程序还会删除阻塞池。 当前，内核支持两个随机数据池，其中一个对应于/ dev / random，另一个对应于/ dev / urandom，如本2015年
文章中所述 。 阻塞池是/ dev / random的池； 该设备的读取将被阻止（表示其名称），直到从系统收集到“足够”的熵以满足要求为止。 如果池中没有足够的熵，则也会阻止对该文件的进一步读取。
删除锁池意味着从/ dev / random读取的行为类似于getrandom（），其标志值设置为零（并将GRND_RANDOM标志变为noop）。 初始化密码随机数生成器（CRNG）后，从/ dev / random读取并调用getrandom（...，0）将不会阻塞，并且将返回请求的随机数据量。
Lutomirsky说：
“我相信Linux阻塞池已经过时了。 CRNG Linux生成的输出足以用于密钥生成。 阻塞池在任何实质意义上都不强大，它需要大量具有可疑价值的基础架构来维护它。”进行这些更改的目的是确保现有程序不会真正受到影响，并且实际上，长时间等待之类的问题（例如生成GnuPG密钥）的问题会变小。
这些系列不应违反任何现有程序。 / dev / urandom保持不变。 / dev / random仍然在加载后立即阻止，但是它比以前更少。 带有现有标志的getentropy（）将返回一个结果，该结果将和以前一样实际。”Lutomirsky指出，核心是否应提供所谓的“真实随机数”（在某种程度上应由阻塞核心来完成）尚待解决。 他只看到一个原因：“遵守国家标准”。 Lutomirsky建议，如果内核应提供此功能，则应通过完全不同的接口来完成此操作，或者应将其转移到用户空间，从而允许它检索可用于创建这种锁池的未处理事件模式。
StephanMüller建议，他的Linux随机数生成器（LRNG）
补丁集（当前已发布版本26）可能是一种为需要它的应用程序提供真实随机数的方法。 LRNG“完全符合”建议中关于用于生成随机比特的熵源“ SP800-90B”的要求，这使其成为解决州标准问题的方法。
马修·加勒特（Matthew Garrett）反对“真正的随机数据”一词，并指出，原则上可以对可选设备进行足够精确的建模以使其可预测：“我们不在这里进行量子事件。”
Muller回答说，该术语来自德国标准AIS 31，用来描述一个随机数生成器，该生成器仅“以与底层噪声源生成熵的速度相同的速度”生成结果。
除了对术语的误解之外，LRNG修补程序建议的锁池的存在也将直接导致各种问题，至少在没有特权的情况下可用。
正如Lutomirsky所说：
“这不能解决问题。 如果两个不同的用户运行诸如gnupg之类的愚蠢程序，则它们只会互相耗尽。 我发现/ dev / random目前存在两个主要问题：它容易受到DoS（即资源枯竭，有害影响或类似的东西）的影响，并且由于它不需要任何特权才能使用它，因此遭受滥用。 Gnupg是错误的，它是完全崩溃。 如果我们添加一个新的gnupg和类似程序将使用的非特权接口，我们将再次失败。”Muller指出，添加getrandom（）现在将允许GnuPG使用此接口，因为它将为池已初始化提供必要的保证。 根据与GnuPG开发人员Werner Koch的讨论，穆勒认为，保修是GnuPG当前直接从/ dev / random中读取的唯一原因。 但是，如果有一个非特权接口遭到拒绝服务（截至今天/ dev / random），那么根据Lutomirsky的说法，它将被某些应用程序滥用。
Linux随机数子系统的开发者Theodore Yue Tak Ts'o似乎改变了对阻塞池的需求。 他说删除该池将有效摆脱Linux具有真正的随机数生成器（TRNG）的想法：
“这不是废话，因为这正是BSD一直在做的事情。”他还担心提供TRNG机制将只是应用程序开发人员的诱饵，并认为实际上，考虑到Linux支持的各种类型的硬件，不可能在内核中保证TRNG。 即使基于根特权使用设备的能力也无法解决问题：
“出于安全原因，应用程序开发人员指定将其应用程序安装为root用户，因为这是访问“真正好的”随机数的唯一方法。穆勒（Muller）问曹是否拒绝实施他本人早就提出的封锁池。 曹回答说，他计划安装Lutomirsky补丁，并积极反对将阻塞接口添加回内核。
“内核无法保证噪声源是否已正确表征。 GPG或OpenSSL开发人员唯一能获得的就是模糊的感觉，即TRUERANDOM是“更好的”，并且由于他们想要更高的安全性，他们无疑会尝试使用它。 在某个时候，它将被阻止，并且当其他一些聪明的用户（也许是发行专家）将其插入init脚本中并且系统停止工作时，用户只需要向Linus Torvalds自己抱怨即可。”曹还提倡为密码学家和真正需要TRNG的人们提供一种在用户空间中收集自己的熵的方法，以便他们可以视需要使用它。 他说，熵收集不是内核可以在其支持的各种硬件上执行的过程，此外，内核本身无法估计各种来源提供的熵的数量。
“内核不应该将不同的噪声源混合在一起，当然，它不应该试图声称知道当它尝试在对丑陋的用户来说简单的CPU架构上玩某种“熵的疯狂游戏”时，它知道接收了多少熵。 “ IOT /嵌入式情况，当所有内容都与单个主生成器不同步，没有CPU指令重新排序或重命名寄存器时，等等。”
“我们可以谈论提供尝试进行这些计算的工具，但是这些事情应该在每个用户的设备上执行，这对于大多数分发工具包用户来说是不切实际的。 如果这仅适用于密码学家，则请在他们的用户空间中完成。 而且，我们不要简化GPG，OpenSSL等，以至于每个人都说：“我们想要“真正的随机性”，不要在其他方面达成共识。” 我们可以讨论如何为密码学家提供接口，以便他们可以通过访问分离并命名的主要噪声源来获取必要的信息，并且有可能以某种方式在图书馆或用户空间应用程序中对噪声源进行身份验证。”对于这种接口的外观进行了一些讨论，因为例如，对于某些事件，可能会涉及安全性。 曹指出，键盘扫描代码（即击键）是作为熵收集的一部分混入池中的：“即使通过特权系统调用，将其转移到用户空间也至少是不合理的。” 其他事件定时可能会通过辅助通道造成某种形式的信息泄漏。
因此，有一种Linux随机数子系统的长期存在的问题即将解决的感觉。 实际上，随机数子系统最近发生的变化实际上仅在其使用过程中导致DoS问题。 现在有有效的方法来获得内核可以提供的最佳随机数。 如果TRNG对于Linux仍然是理想的，那么将来将需要解决此缺点，但是很可能不会在内核内部完成。
一点广告：）
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的资料吗？ 通过下订单或向您的朋友推荐给
开发人员的基于云的VPS， 最低 价格为4.99美元 ，
这是我们为您发明的入门级服务器的
独特类似物： 关于VPS（KVM）E5-2697 v3（6核）的全部真相10GB DDR4 480GB SSD 1Gbps从$ 19还是如何划分服务器？ （RAID1和RAID10提供选件，最多24个内核和最大40GB DDR4）。
阿姆斯特丹的Equinix Tier IV数据中心的戴尔R730xd便宜2倍吗？ 仅
在荷兰，我们有
2台Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100电视 ！ 戴尔R420-2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB-$ 99起！ 阅读有关
如何构建基础架构大厦的信息。 使用价格为9000欧元的Dell R730xd E5-2650 v4服务器的上等课程？