我觉得我对哈希函数及其所需的契约有很好的理解。
输入X上的SHA1将始终产生相同的输出。您可以使用Python库，Java库或笔和纸。它是一种功能，它是确定性的。我的SHA1与你的相同，还有爱丽丝和鲍勃。
据我了解，AES也是一种功能。你输入了一些值，它会吐出密文。
那么，为什么会有人担心Truecrypt（例如）被打破＆＃34;？他们并不是说AES被打破了，他们说的是实施它的程序可能是。从理论上讲，AES是可靠的。那么为什么你不能通过Truecrypt运行一个文件，通过一个＆＃34;参考AES＆＃34;功能，并验证结果是否相同？我知道它绝对不会那样，但我不知道为什么。
是什么让AES以这种方式与SHA1不同？为什么Truecrypt AES会发出与Schneier-Ifier * AES不同的文件，当它们都被赋予所有相同的输入时？
最后，我的问题归结为：
My_SHA1（X）== Bobs_SHA1（X）== ... etc
但是TrueCrypt_AES（X）！= HyperCrypt_AES（X）！= VeraCrypt_AES（X）等等。为什么会这样？所有这些程序都包装AES，但有不同的方法来确定初始化向量之类的东西吗？
*如果我写了一个
，这将是我的文件加密程序的名称答案 0 :(得分：4)
在你给出的SHA-1示例中，函数只有一个输入，当提供相同的输入数据时，任何正确的SHA-1实现应该产生与任何其他实现相同的输出。
对于AES而言，事情有点棘手，而且由于您没有明确指出“AES”的含义，这本身似乎可能是实现之间感知差异的根源。
首先，“AES”不是单一算法，而是一系列采用不同密钥大小（128,192或256位）的算法。 AES也是一个分组密码，它需要一个128位/ 16字节明文输入的单个块，并使用密钥对其进行加密，以产生一个16字节的输出块。
当然，在实践中我们经常希望一次加密超过16个字节的数据，因此我们必须找到一种方法来重复应用AES算法来加密所有数据。我们可以将它分成16个字节的块并依次加密每个块，但这种模式（描述为电子密码本或ECB）结果是horribly insecure。相反，通常使用各种其他更安全的 modes ，其中大多数需要初始化向量（IV），这有助于确保使用加密相同的数据相同的密钥不会产生相同的密文（否则会泄漏信息）。
这些模式中的大多数仍然在固定大小的数据块上运行，但我们仍然经常想要加密不是块大小的倍数的数据，所以我们必须使用某种形式的 {{3 }} ，对于我们如何将消息填充到块大小的倍数的长度，有各种不同的可能性。
因此，为了将所有这些放在一起，如果以下所有相同的话，两个不同的“AES”实现应该产生相同的输出：
答案 1 :(得分：1)
Iridium涵盖了TrueCrypt与其他程序之间使用名义上相同（AES）算法的不同输出的许多原因。如果您只是检查实际的初始化向量，这些往往是使用ECB完成的。这是使用ECB的唯一好时机 - 确保算法本身正确实施。这是因为欧洲央行虽然不安全，但在没有静脉注射的情况下确实有效，因此更容易检查“苹果与苹果”之间的关系。虽然铱星指出其他绊脚石仍然存在。
使用测试向量，密钥与纯文本一起指定。并且测试向量被指定为块大小的精确倍数。或者更具体地说，对于纯文本，它们的大小恰好是1个块。这样做是为了从可能的差异列表中删除填充和模式。因此，如果您在两个AES加密程序之间使用标准测试向量，则可以消除纯文本数据差异，键差异，IV，模式和填充的问题。
但请注意，你仍然可以有分歧。 AES与散列一样具有确定性，因此您每次使用AES都可以获得相同的结果，就像使用散列一样。它只是需要控制更多变量来获得相同的输出结果。一个项目铱星没有提到，但可能是一个问题是输入的字节顺序（键和纯文本）。在检查Serpent对TrueCrypt的参考实现时，我遇到了这个问题。如果我在它们之间反转键和纯文本，它们只向文本向量提供相同的输出
。详细说明一下，如果你有16个字节的纯文本为0，你的密钥是31个字节的0和一个字节的＆＃39; 33＆＃39; （在256位版本中），如果＆＃39; 33＆＃39; byte是在参考实现的字节字符串的左端，你必须提供TrueCrypt 31＆＃39; 00＆＃39;字节，然后是＆＃39; 33＆＃39;右侧的字节可以获得相同的输出。正如我所提到的，一个字节序问题。
至于TrueCrypt即使AES仍然不安全，这是绝对正确的。我不知道TrueCrypt所谓的弱点的具体细节，但让我介绍一些程序可以使AES正确并仍然不安全的几种方式。
一种方法是，在用户输入密码后，程序以不安全的方式将其存储在会话中。如果它没有在内存中加密，或者它使用自己的内部密钥加密你的密钥但是无法很好地保护该密钥，你可以让Windows在硬盘驱动器上写出来，如果它将内存交换到硬盘，所有人都可以阅读驾驶。或者因为这种交换不像以前那样普遍，除非TrueCrypt作者在会话期间保护你的密钥，否则恶意程序也可能会出现并调试＆＃34; TrueCrypt软件的关键。所有没有AES的都被打破了。
它可能被打破的另一种方式（理论上）将使定时攻击成为可能。举一个简单的例子，想象一个非常基本的加密，它将你的32位密钥分成两个16字节的块。然后它按字节查看第一个块。它将纯文本位旋转一定数量的位，这些位对应于键的字节0的值。然后它用你的密钥的右手16个字节对纯文本进行异或。然后它按键的每个字节1再次进行位旋转。等等，16班和16个XOR。好吧，如果一个＆＃34;坏人＆＃34;他们能够监控CPU的功耗，他们可以使用侧信道攻击来计算CPU的时间和/或在每个位的基础上测量其功耗。事实上，比特旋转121位需要更长的时间（通常，取决于处理位旋转的代码）比特旋转120比特。这种差异很小，但它确实存在，并且已被证明可以泄露关键信息。 XOR步骤可能不会泄漏密钥信息，但是基于上述攻击，攻击者可以很容易地知道一半密钥，即使执行了一个完整的算法，如果实现本身没有正确完成 - 非常难以做到的事。
所以我不知道TrueCrypt是以这些方式之一还是以其他方式完全破坏。但加密比它看起来要困难得多。如果内心的人说它被打破了，我很容易相信它们。