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