HMAC与加密哈希

Question

使用对称密钥加密消息时，最佳做法似乎是首先加密消息，然后通过HMAC运行密码文本和密钥，并将结果附加到密码文本中。接收机可以去掉哈希，HMAC密码文本和密钥，并验证哈希匹配。这告诉接收者，制造HMAC的人拥有秘密密钥，并且消息没有被篡改。

但是为什么发送者不能将密码文本散列，然后用秘密密钥加密哈希呢？接收方将用相同的密钥解密哈希，散列密码文本，并验证散列是否匹配。这不是给了接收者同样的保证吗，当发送者想要签署密码文本的时候，这不是在公钥密码学中所做的吗？

Answer 1

根据加密算法和哈希函数的不同，这在最坏的情况下可能是浪费的，最好是在低级别上高效地实现是很难的。无论如何，必须非常小心才能正确地做到这一点。你不能认为这是特例"AES+CBC+SHA256“。您必须考虑cipher+mode和加密散列的每个组合是否正确(特别是考虑到哈希大小不是块大小的倍数的情况)。对于特定情况，这可能很好，但通常使用的是为此目的而设计和分析的系统：(H)MAC。

简单地讲一下，假设您要用AES和SHA-224实现这一点。所以SHA-224有28个字节长，AES有一个16字节的块.所以我们需要两个街区。所以我们需要一个模式。因为这可能是我们用来加密信息的方法？但我可以不受欧洲央行的影响，因为这种投入“实际上是随机的”。好吧，也许我吓唬了人们，选择了欧洲央行(因为这通常很危险，但我向他们解释)，但我仍然需要一个填充的解决方案。PKCS7 --我猜这就是我们用来处理消息的东西，但是现在我在每条消息中浪费了4个字节(一个HMAC是28个字节，但是密码文本是32个字节)。或者我可以切换到XEX模式，这样就可以在不浪费字节的情况下使用任何长度的散列。我在那里的任何地方都犯了错误，不小心把保安弄坏了吗？

看看我在这里做了多少选择？我正在做的是用手重新发明一个MAC。没有简单的操作称为“加密”。这个词掩盖了大量的选择和实现细节。然后我需要确保我选择的方式不会造成问题。许多加密系统在一组假设下都是优秀的，而在另一组假设下则完全崩溃。将两个独立安全的东西组合在一起可以破坏整个系统(长度扩展攻击是这种攻击的一个最受欢迎的版本)。没有什么简单的东西叫做“加密”，它总是既安全又高效。

那么我们该怎么办呢？我们使用的方案(不仅仅是算法，而是我们如何将算法组合在一起)已经被精心设计、审查和攻击了很长一段时间。我们强烈避免发明新的方案，即使它们看起来很好(即使它们实际上很好)。一个非常流行和分析良好的MAC解决方案是HMAC。所以我们用那个。

顺便说一次，我去找过一次关于使用与HMAC相同的加密密钥是否安全的指导。据我所知，答案是没有人知道。这可能会使这两个系统纠缠过多，泄露信息，或者不会。我不认为它已经研究得足够好，无法确定。所以我在我的系统里使用不同的钥匙。我们的默认位置应该是“在被广泛研究之前它是不安全的，然后它可能暂时被信任”，而不是“在有人证明了攻击之前它是安全的。”