为什么在 OpenSSL 的随机数生成器中使用未初始化的内存是安全的? [英] Why is uninitialized memory safe to use in OpenSSL's random number generator?

查看:111
本文介绍了为什么在 OpenSSL 的随机数生成器中使用未初始化的内存是安全的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

因此,自从 Debian 维护者臭名昭著地导致 RNG 种子被 注释掉未初始化数据的用法.

So, it's been just over eleven years since a Debian maintainer infamously caused RNG seeds to become predictable by commenting out a usage of uninitialized data.

这个问题在网上引起了很多热烈讨论,大部分焦点似乎都集中在批评审查过程或攻击有问题的开发者上.

The issue generated a lot of heated discussion in online circles, with most of the focus seemingly being on criticizing the review process or attacking the developers in question.

但是,我无法找到有关该段背后的实际思考过程的任何信息.许多用户认为最坏的情况下,它不会受到伤害" - 然而,这对我来说似乎完全违反直觉.

However, I haven't been able to find any information on the actual thought process behind the segment being there in the first place. A lot of users argue that "worst case, it can't hurt" - however, that seems utterly counter-intuitive to me.

毕竟,从未初始化的内存中读取会调用未定义的行为,臭名昭著的是,这会导致鼻恶魔、运行 nethack 或格式化硬盘驱动器.因此,在我看来,将这种逻辑引入任何程序 - 更不用说加密库 - 可以让您进行积极的编译器优化,远离彻底的灾难.

After all, reading from uninitialized memory invokes undefined behavior which, infamously, can cause nasal demons, run nethack or format your hard drive. Thus, it seems to me that introducing this sort of logic into any program - let alone a crypto library - puts you one aggressive compiler optimization away from utter disaster.

因此,我的问题:

  • 我是不是误会了什么?这实际上不是在调用 UB,而是在标准下进行了明确定义,这是否有任何原因?
  • 如果它确实调用了 UB,为什么这种行为最初包含在 OpenSSL 中?

推荐答案

Debian修复"是 完全不正确.ssleay_rand_add 是向池中添加熵的唯一函数.真正的罪魁祸首是调用的网站,它应该在那里得到修复——因为函数本身没有任何问题.

The Debian "fix" was completely incorrect. ssleay_rand_add was the only function adding entropy to the pool. The real culprit was in the site of invocation, and it should have been fixed there - as there was nothing wrong with the function itself.

所以基本上是这样的:

void add_entropy(void *buf, size_t length) {
    actually_add_entropy(buf, length);
}

int main(void) {
    char buf[256];

    // uninitialized local variable
    add_entropy(buf, length);

    // calculate more entropy to buf
    // ...
    add_entropy(buf, length);
}

如果您查看代码,问题在于第一个调用中传入的参数是真正的罪魁祸首,第二种情况是可以的,因为 buf 现在已初始化.正确的修复是不是修复"add_entropy,如下所示:

If you look at the code, the problem is that the argument passed in in the first invocation is the real culprit, the second case is OK, as the buf was now initialized. The proper fix is not to "fix" add_entropy as follows:

void add_entropy(void *buf, size_t length) {
    // valgrind complains about buf being uninitialized so
    // actually_add_entropy(buf, length);
}

<小时>

然而,他们正确尝试删除未初始化数组的使用 - 除了 UB 和 USB,它可能已经掩盖了代码中的严重问题 - 很可能熵被从未初始化的数据初始化,因此可能仍然是可猜测或可控的 - 但只是这次更难注意到.


However they were right in attempting to remove the use of uninitialized array - UB and USB aside, it might have been masking serious problems in the code - it might have very well been that the entropy been initialized only from the uninitialized data and therefore possibly still guessable or controllable - but only this time harder to notice.

这篇关于为什么在 OpenSSL 的随机数生成器中使用未初始化的内存是安全的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆