为什么普通的哈希然后加密不是安全的MAC？

#1 楼

$ \ operatorname {Encrypt}（m \ | H（m））$不是提供身份验证的操作模式；在某些非常真实的场景中可能会伪造。根据所使用的加密，可以假定仅是已知的纯文本。这是一个简单示例，其中$ \ operatorname {Encrypt} $流密码，包括CTR或OFB模式下的任何块密码。 Mallory希望为自己选择的某些消息$ m $伪造一个身份验证器。


Mallory截取了其中的密码$ \ operatorname {Encrypt}（m_0 \ | H（m_0））$格式$ IV \ | C_0 $，已知$ m_0 $，大小至少为$ m $； $ C_0 $的大小为$ m_0 \ | H（m_0）$，后者的eXclusive-OR为$ IV $的键流$ K $函数。
Mallory将$ K $计算为$ C_0 \ oplus（ m_0 \ | H（m_0））$，如果$ m $短于$ m_0 $，则将其截断为$ m \ | H（m）$。
Mallory计算$ C =（m \ | H（ m））\ oplus K $。
Mallory将密码替换为$ IV \ | C $，它将通过接收者的身份验证检查，并解密为$ m $。


另一个例子：假设$ \ operatorname {Encrypt} $是CBC，CFB或OFB模式下的AES，且具有随机的$ IV $； $ H $是SHA-256。 Mallory希望为自己选择的某些消息$ m $伪造一个身份验证器，该消息的大小$ s $个块为16字节（AES的块大小）。


Mallory计算$ m_1 = m \ | H（m）$，$ s + 2 $个块。
Mallory设法将$ m_1 $插入到AES密钥的合法持有者发送的某些消息$ m_0 \ | m_1 \ | m_2 $中，他们选择$ m_0 $和$ m_2 $，其中$ m_0 $是非空的，其大小是Mallory知道的块大小的倍数。
Mallory截取密码$ IV \ | C $。
从$ C $ Mallory比$ m_0 $少了一个街区；保留下一个区块，形成$ \ widetilde {IV} $；然后下一个$ s + 2 $块形成$ \ widetilde {C} $。
Mallory用$ \ widetilde {IV} \ | \\ widetilde {C} $替换密码，这将通过对接收者，并解密为$ m $。

这种情况并非遥不可及：如果Mallory可以在CD-ROM映像中选择某些文件，比如他假装成电影，那么他就可以制作一个经过加密和认证的假CD-ROM映像，

如果$ m_0 $可以为空（不太现实），则可以使用更简单的攻击方式：$ \ widetilde { IV} $是$ IV $，$ \ widetilde {C} $是$ C $的前$ s + 2 $块。


问题的标题询问$ \ operatorname {Encrypt}（m \ | H（m））$是安全的MAC，对于Vulcan而言，$ \ operatorname {Encrypt}（m \ | H（m））$会附加到以明文形式发送的$ m $后面。这也不提供身份验证，并且屈服于上述琐碎的变体。

#2 楼

两件事加在一起可能会使原始哈希然后加密变得不安全。

首先，安全MAC和哈希之间的区别是哈希函数可以允许您导出$ H（m $ H（m）$中的'）$，即使您只知道$ m'$和$ m $有何不同。对SHA-1和SHA-2的长度扩展攻击是一种可能发生的实用方法，但是如果哈希函数不能特别保证没有这种攻击，则可能还会有其他攻击。

第二，流密码使您可以对明文进行确定性更改。具体来说，您可以翻转密文中喜欢的任何位，也将它们翻转到解密后的明文中（假设密码大多数情况下使用XOR）。

将它们放在一起，可以可能例如翻转最后一个消息位，确定哪些位将翻转哈希，然后翻转那些位。

另外，即使您选择安全MAC作为$ H $，在加密中包含哈希也意味着您需要在确定密文是否已损坏之前进行解密和散列，从而与加密然后散列相比增加了在嘈杂信道上的重传延迟。

#3 楼

…使用类似于HMAC的东西，而不是普通的哈希。


HMAC是带密钥的哈希……这意味着它还提供了不可伪造性。

A “普通散列”（我认为其中包括加密哈希）仅提供抗冲突性，而HMAC既提供抗冲突性又具有不可伪造性……因为攻击者无法计算出经过修改/伪造的消息的新有效HMAC（$ m $ ），除非该攻击者还具有生成新的，有效的和可验证的HMAC所需的密钥。

如果您使用（简称为“ unkeyed”）哈希，则攻击者能够（例如）猜测（例如）该消息（$ m $）或拦截了您的加密密钥，或者该攻击者是否能够以任何方式破坏您的加密。这种情况下的问题（更好的是：安全问题）是，您可能正在从攻击者而不是预期的发送者那里接受和解密密文，并且您永远不会得知消息$ m $被弄乱了。简单的哈希将毫无用处，因为它提供的只是抗冲突性。

使用HMAC时，相同的攻击者还必须成功猜测/拦截HMAC的密钥（也就是说，除非您对加密和HMAC使用相同的密钥……当然并不是最明智的主意，因为这会使攻击者更容易伪造所有东西。因此，使用键控哈希不仅可以像无键哈希一样提供抗冲突性，还可以让您验证$ m $是否真实（不可伪造）。

简而言之：创建一些明文的“简单哈希”对于攻击者而言可是小菜一碟；但是尝试创建有效且可验证的“密钥哈希”是完全不同且更加复杂的野兽。因此，与使用常规哈希函数相比，HMAC实际上增加了额外的安全层。这是首选使用HMAC而不是“无密钥”哈希的主要原因之一。和关键选择）。我要说明的是为什么在逻辑上优先使用MAC而不是简单的哈希，而如果加密失败/失败，那么简单的哈希将不会给您带来任何好处。


…不是满足理想MAC的近似值？


否。


…似乎没有安全协议使用它。为什么？


如果可以免费获得经过严格审查的附加安全层，为什么要避免或忽略它？

您曾经说过“ HMAC似乎有点复杂”，但是如果您看一看，您会发现它也为您带来了很大的“不可伪造性”。有时候，由于某种原因，事情变得“有点复杂”……人们正是出于这个原因而喜欢使用它。在这种情况下，要获得不可伪造性。

#4 楼

为什么？


我们希望能够构建更多基本的加密方案。


假设我们使用一些流密码;那么为什么我们不能使用Encrypt（m | H（m））作为消息的MAC加密形式呢？


对于“传统”未经身份验证的加密方案，加密长度相同的明文总是会产生长度相同的密文，并且对于所有消息$ m_0 $，可以轻松找到字符串$ p $，这样对于所有消息
$ m_1 \ hspace {-0.0 in} $，将$ Encrypt（m_0 | H（m_0）| p | m_1 | H（m_0 | H（m_0）| p | m_1））$截短为适当的长度将产生$ m_0 | H（m_0）$的加密。 />

假设$ Encrypt $和$ H $之间没有不良关系，可能的弱点是什么？


可能的弱点是对手的选择能力一个将解密为高度非随机的“明文”的“密文”。安全;这不是理想MAC的近似值吗？

是；正如我在此答案的前面所解释的那样，这不能满足理想MAC的近似要求。


这在某种程度上很糟糕，因为似乎没有安全协议使用它。为什么？


仅当基础加密方案已经对主动攻击具有一定抵抗力时，它才起作用。