Ale*_*lev 40
使用/dev/random可能需要等待结果,因为它使用所谓的熵池,此时可能无法获得随机数据.
/dev/urandom返回用户请求的字节数,因此它的随机性不如/dev/random.
可以从手册页中读取:
随机
读取时,
/dev/random设备将仅返回熵池中估计的噪声位数内的随机字节./dev/random应该适用于需要非常高质量随机性的用途,例如一次性垫或密钥生成.当熵池为空时,读取/dev/random将阻止,直到收集到额外的环境噪声.
urandom的
从
/dev/urandom设备读取不会阻止等待更多熵.结果,如果熵池中没有足够的熵,则理论上返回的值易受对驱动程序使用的算法的加密攻击.目前未分类的文献中没有关于如何做到这一点的知识,但理论上可能存在这样的攻击.如果这是您的应用程序中的问题,请/dev/random改用.
出于加密目的,您应该真正使用它,/dev/random因为它返回的数据的性质.为了安全起见,IMO应该将可能的等待视为可接受的权衡.
当您需要快速随机数据时,您/dev/urandom当然应该使用.
Iro*_*nny 28
始终使用/ dev/urandom.
/ dev/urandom和/ dev/random使用相同的随机数生成器.它们都由相同的熵池播种.它们都会给出一个任意大小的随机数.它们都可以提供无限量的随机数,只有256位种子.只要初始种子具有256位熵,就可以无限量地提供任意长的随机数.使用/ dev/random没有任何好处.事实上,有两个设备是Linux API中的一个缺陷.
如果您担心熵,使用/ dev/random不会解决这个问题.但它会减慢你的应用程序,而不会产生比/ dev/urandom更随机的数字.如果你不关心熵,你为什么要使用/ dev/random？
这里有一个更好/深入的解释,为什么你应该总是使用/ dev/urandom:http://www.2uo.de/myths-about-urandom/
/dev/random和之间有什么区别/dev/urandom？
/dev/random并且/dev/urandom是内核的随机数生成器的接口:
说到差异,取决于操作系统:
/dev/random可能阻止读取,这限制了它在实践中的使用/dev/urandom只是一个象征性的链接/dev/random.我应该什么时候使用它们？我什么时候不应该使用它们？
这是很难找到的,你应该使用用例/dev/random以上/dev/urandom.
阻止的危险:
/dev/random.对于单个用途,ssh-keygen它应该可以等待几秒钟,但对于大多数其他情况,它将不是一个选项./dev/random,则应以非阻塞模式打开它,并在所需的熵不能立即可用时提供某种用户通知.安全:
/dev/urandom中几乎所有实际情况都被认为是安全的(例如,/ dev/urandom对于登录密钥是安全的吗？还有/ dev/urandom的神话).该
/dev/random接口被认为是传统接口,并且/dev/urandom在所有用例中都是首选和足够的,除了在早期启动时需要随机性的应用程序; 对于这些应用程序,必须使用getrandom(2),因为它将阻塞,直到初始化熵池.如果种子文件按照下面的建议在重新启动时保存(所有主要的Linux发行版至少从2000年开始执行此操作),输出在加密后一旦在引导序列中重新加载就没有本地root访问权限就是加密的,并且完全足够用于网络加密会话密钥.由于
/dev/random可能阻止读取,因此用户通常希望以非阻塞模式打开它(或执行带超时的读取),并在所需的熵不能立即可用时提供某种用户通知.
建议
作为一般规则,/dev/urandom应该用于除长期GPG/SSL/SSH密钥之外的所有内容.
/dev/urandom它们均由相同的加密安全伪随机数生成器 (CSPRNG) 提供。等待熵（或更具体地说，等待系统对其熵的估计达到适当的水平）这一事实/dev/random仅在您使用信息理论上安全的算法（而不是计算上安全的算法）时才会产生影响。前者包含您可能没有使用的算法，例如 Shamir 的秘密共享和一次性便笺本。后者包含您实际使用和关心的算法，例如 AES、RSA、Diffie-Hellman、OpenSSL、GnuTLS 等。
因此，如果您使用来自 CSPRNG 的数字并不重要/dev/random，而且“理论上有可能”破坏您可能使用它们的算法。
最后，“理论上可能”就是这个意思。在这种情况下，这意味着在宇宙存在的时间内使用世界上所有的计算能力来破解该应用程序。
因此，使用几乎没有意义/dev/random
所以使用/dev/urandom
| 归档时间： |
|
| 查看次数： |
18594 次 |
| 最近记录： |