（我只是想找出我错过了什么……）
假设 John 有一个 clear 文本消息，他可以创建一个常规的 hash（如 md5 或 sha256）并然后加密 消息时间>。
John 现在可以向 Paul 发送消息 + 其（明文）哈希，并且 Paul 可以知道消息是否被更改。 （解密然后比较哈希）。
即使如果攻击者可以更改加密数据（无需解密） - 当保罗打开消息 - 并重新计算哈希 - 它不会生成与约翰发送给他的哈希相同的哈希。
那么为什么我们需要按键哈希？
【问题讨论】：
标签： .net security encryption hash
看起来您不必必须这样做是个好主意，因为通过将密钥包含在哈希中，它表明数据确实是用原始密钥加密的——几乎是无限期的。显然你上面的例子可以工作，但我会说你不能 100% 确定消息没有被智能操纵，或者暴力试错，在另一端产生一个看起来正确但没有的解密'不触发哈希检查失败。
消息发送方使用 HMAC 函数生成一个值（MAC），该值由密钥和消息输入压缩而成。 MAC 通常与消息一起发送到消息接收方。接收方使用与发送方相同的密钥和 HMAC 函数计算接收到的消息的 MAC，并将计算的结果与接收到的 MAC 进行比较。如果这两个值匹配，则消息已被正确接收，并且接收者确信发送者是共享密钥的用户社区的成员。
FIPS PUB 198
联邦信息处理标准发布
“密钥哈希消息验证码 (HMAC)”
使用上述方法意味着您有额外的安全检查。解密消息后，将原始密钥附加到消息并运行散列函数。然后，您将新哈希与发送的哈希进行比较。这是一个更好的检查，因为您知道攻击者必须知道密钥（或者非常幸运）才能生成通过哈希检查的内容。这基本上是试图避免那些可能非常了解哈希函数的攻击者，并限制他们可以进行的更改。
【讨论】：
如果您问为什么对密钥进行哈希处理，它允许数据库或操作系统以更安全的格式存储密码。系统可以通过将密钥的哈希值与存储的密钥哈希值进行比较来检查密钥的有效性。
此外，安全系统不仅对密钥进行哈希处理，而且对密钥+已知随机模式 (=salt) 进行哈希处理，这可以防止人们生成最常用密码的哈希值字典。即使使用密码=密码，系统首先将其附加到“passwordAK(43mafk2;”并计算散列。该散列不再匹配任何其他人的预计算字典，但攻击者必须将他自己的密码字典连接到“AK (43mafk2;" 并为系统中的每个密码重新计算哈希值。
【讨论】：
WHY DO WE NEED TO CALC HASH ALSO BY THE KEY？
对原始未加密文本进行哈希处理的原因是为了增加安全性。这里的问题不在于是否有人操纵了加密数据 - 该操作很少会解密为有意义的内容，而是阻止拥有密钥的人解密文本、更改文本并使用相同的密钥重新加密。
所以基本上，即使有人有办法解密您的文本，如果他们这样做，更改您的文本，重新加密并将加密数据传递到最终目的地，您也可以验证数据是否被操纵。
示例： 我有文件 #1，其中包含文本“Samuel”——这是我们组织中间谍鼹鼠的名字。假设我用文本“qwerty”将它加密到文件#2 中。我将文件 #2 传递给 Peter，以便交付给 Adam。然而，彼得是一个狡猾的卑鄙小人，是苏联的间谍。他之前窃取了我的加密/解密协议，他想通过将“Samuel”更改为“Justin”来误导我们。因此，他将“qwerty”解密回“Samuel”，将“Samuel”更改为“Justin”，使用相同的规则将其加密为“asdfg”，并将此文件传递给 Adam。亚当成功解密文件#2，并假设“贾斯汀”是苏联间谍......如果他没有散列“贾斯汀”并打电话给我确认我们的散列是否匹配。惊喜！他们不！因此，我们知道有人操纵了数据，并且有人知道解密/加密协议！保存数据完整性！
【讨论】：