RDRAND（英特尔）会损害熵吗？

#1 楼

首先，写入/dev/random和/或/dev/urandom与增加内核中维护的熵计数之间是有区别的。

这就是为什么默认情况下/dev/random是世界可写的-任何原因输入只会增加而不是取代RNG的内部状态；如果您编写完全可预测的数据，则对您没有好处，但也没有害处。

如果另一方面，您使用特殊的ioctl写入/ dev / random（这确实需要超级用户特权），则实际上可以增加熵估计。关于/dev/random的行为：通常，应该将对/dev/notsorandom的读取阻塞，直到至少已将熵比特写入内部池之前，而不是将其重新装入熵，而/dev/random返回所需的“随机性”。）

如果您设法将可预测的位写入池中，但告诉内核将其记为不可预测的数据，则/ dev / random的下一个读取器将接收仅确定性地取决于当前内部状态的随机数的熵池，而不是“真正随机”事件，例如磁盘搜索时间和键盘d输入。

但是，除非您能够从操作系统的安装中进行这种攻击，否则您实际上并不知道这种内部状态！从/dev/urandom输出进行预测至少与反转SHA-1一样困难（这被认为非常困难）。这也是为什么可以推理的原因，除了在全新安装操作系统之后直接进行检查外，random对于所有目的（无论是否加密）都可以被视为“足够随机”。

现在让我们来在drivers / char / random.c中查看RdRand的实际实现：

曾经使用过可能有害的RdRand指令的唯一位置是在随机设备的输出功能中。它与“经典” Linux RNG的“实际”输出在返回给调用者之前进行异或。

由于信息论告诉我们，当我们对选定字符串与未知字符串进行异或时，我们无法预测转换后结果字符串的外观，颠覆RdRand指令（至少在Linux当前使用它的方式）没有任何好处。

更新：
有人建议，一个非常聪明的CPU可能会将对RdRand的调用解释为后台的触发，例如，将后继的XOR替换为MOV。

从理论上讲，可能，但是比直接偏斜RdRand的输出更难实现，例如通过在仅被对手称为“随机数”的密钥下返回AES-CTR的密钥流。

必须检查内核中使用的特定代码序列；如果这种情况发生了变化（例如，通过使用一些虚拟的XOR操作包围RdRand调用），则必须广泛部署用于适应启发式的微代码更新，否则人们很快就会开始怀疑。

处理RdRand指令（或在不同体系结构上的等效指令）作为另一个熵输入（为了安全起见，不增加估计的熵），可能会使RNG更加难以颠覆。

第二次更新：
该问题已在内核邮件列表中进行了两次讨论：一次是在2011年，首先是由英特尔工程师提交的补丁，然后是关于安全性的大量讨论，最后一次是在2012年，最终导致了实施当前补丁的补丁方法。甚至已经提到过有关触发后门改变某些指令（例如XOR或MOV）行为的担忧。就XOR构造而言：Linux专家声称，XOR方法应该比将RdRand输出散列到熵池中更安全，尽管我们当中有些人对此并没有真正的说服力。

#2 楼

是的，它可以：请参见http://people.umass.edu/gbecker/BeckerChes13.pdf [已存档]，以了解如何在没有裸露金属的情况下通过光学显微镜对其进行后门检测。

通常，将Intel RDRAND输出添加到不是唯一熵源的池中通常是安全的（如果不能控制输出，则始终是安全的）。目前，这就是针对Linux的讨论。

作为用户空间应用程序，您永远不要直接使用RDRAND，至少不要混用，例如来自/dev/urandom或类似内容的流密码的输出。

#3 楼

我认为操纵xor指令和其他指令可能不会像lxgr所建议的那样困难。

如果我是硬件设计师，该怎么办： />在RDRAND的输出寄存器中添加一个额外的位。该位表示类似“不可观察”。在用户“打开盒子”之前，寄存器中可能没有任何东西。 （想想薛定'的猫：-））
更新XOR，ADD，可能还有其他指令来检查是否观察到该值。如果不是，请根据需要进行更改。

该解决方案的成本将是在十亿个晶体管芯片中增加30个左右的晶体管。

如果使用RDRAND输出，可能会一个好的想法是将输出稍微移动一点并进行一些计算，以便“它的波动函数会崩溃”，然后使用它

#4 楼

将RDRAND的输出混合到/ dev / random输出缓冲区的方式

    linux drivers/char/random.c, extract_buf()

    /* ... compute a hash.l[i] PRNG ... */
    /*
     * If we have a architectural hardware random number
     * generator, mix that in, too.
     */
    for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
            unsigned long v;
            if (!arch_get_random_long(&v))
                    break;
            hash.l[i] ^= v;
    }
    /* ... pass hash.l to userspace ... */

似乎容易受到基于微代码的欺骗的影响，从而抑制了XOR混合，而替代了易受攻击的数据。我们永远不会知道它的存在，因为微代码是开源的，并且只要英特尔愿意就可以更新。

更新：另请参见http://www.metzdowd.com/pipermail/cryptography/2013年12月/ 019065.html

#5 楼

XOR B可以以（（NOT A）AND B）或（A和（NOT B））的多个指令来复制。这可以用来验证XOR的结果，并且可以放心地确定，有目标的后门程序将越来越难以在多条指令上实现。