0

我正在编写一个程序，该程序从用户那里获取密码，然后将一些加密数据写入文件。到目前为止，我想出的方法如下：

  • 通过散列文件名和系统时间生成一个 128 位的 IV，并将其写入文件的开头。
  • 使用 SHA256 从密码短语生成 256 位密钥。
  • 使用 AES 在 CBC 模式下使用此密钥加密数据（从 32 位静态签名开始），并将其写入文件。

解密时，会读取 IV，然后以相同方式生成用于生成密钥的密码，并将前 32 位与签名应该是什么进行比较，以判断密钥是否有效。

但是，我正在查看PolarSSL （我用来进行散列和加密的库）中提供的AES 示例，它们使用了一种更复杂的方法：

  • 通过散列文件名和文件大小生成一个 128 位 IV，并将其写入文件的开头。
  • 通过对密码短语和 IV 进行 8192 次散列 (SHA256) 生成 256 位密钥。
  • 使用此密钥初始化 HMAC。
  • 在 CBC 模式下使用 AES 使用此密钥加密数据，并将其写入文件，同时使用每个加密块更新 HMAC。
  • 将 HMAC 写入文件末尾。

我的印象是第二种方法更安全，但我没有足够的知识来支持它，除了它看起来更复杂。

  • 如果它更安全，这是什么原因？
  • 将 HMAC 附加到文件末尾是否比在加密数据的开头添加签名更安全？
  • 哈希 8192 次会增加安全性吗？

注意：这是一个开源项目，所以无论我使用什么方法，任何人都可以免费使用它。

4

1 回答 1

3

第二种选择更安全。

您的方法不提供任何消息完整性。这意味着攻击者可以修改部分密文并更改明文解密的内容。只要他们不修改任何会改变您的 32 位静态签名的东西，那么您就会信任它。第二种方法的 HMAC 提供消息完整性。

通过对密钥进行 8192 次散列运算，它增加了额外的计算步骤，让某人尝试暴力破解密钥。假设用户将选择基于字典的密码。使用您的方法，攻击者必须执行SHA256(someguess)然后尝试解密。但是，使用 PolarSSL 版本，他们将不得不计算SHA256(SHA256(SHA256...(SHA256(someguess)))8192 次。这只会减慢攻击者的速度，但可能就足够了（目前）。

对于它的价值，请使用现有的库。密码学很难并且容易出现细微的错误。

于 2013-11-07T20:51:34.673 回答