我还使用文件摘要（SHA-1）来检查数据是否正确解密（因此我需要将其与文件一起存储）。
使用此摘要作为AES的IV，并将其存储在文件的标头中？还是有安全性问题？
#1 楼
通过使用文件的哈希作为IV，您还可以泄露文件的哈希。这使攻击者可以对文件内容进行详尽的搜索。不难想象只有几百万或数十亿个可能的文件内容的情况（例如，文件内容是加密的SAN或密码），在这种情况下，显示数据哈希是无法忍受的泄漏。可以用作IV的是文件上HMAC的结果，使用与加密相同的密钥作为密钥（或者最好使用适当的PRF导出HMAC密钥和加密密钥）。无论如何，很难证明结果的安全性，因此请勿在生产中使用。但似乎是实现无上下文确定性加密的一种有前途的方法。
“无上下文”表示“没有任何内存”。一些加密模式需要随机的，不可预测的IV，而其他一些加密模式仅需要随机数（例如计数器）；您可以通过使用分组密码（使用特定的秘密密钥）对随机数进行加密来从后者中获得前者。计数器仍然需要一点存储空间，这取决于情况，可能会或可能不会很容易获得。某些嵌入式系统将难以更新存储的计数器（永久性存储更新会消耗一些电流，这是无源RFID系统上的稀缺资源）。由于嵌入式系统很少拥有可靠的随机性来源，因此需要确定性加密。因此，上下文无关的确定性加密是重要的利基功能。使用HMAC来计算用于加密的IV可能是一种方法（具有一个重要的缺点，即在获取需要开始对其进行加密的IV之前，需要对整个文件进行首次传递）。
#2 楼
使用确定性加密时，显然会失去语义安全性。这意味着攻击者可以判断两个文件是否相同。如果攻击者从其他地方知道哈希，则发布未加密的哈希也会泄漏您加密的文件。您最终会遇到类似于收敛加密的问题，但存在一些问题。检查问题融合加密真的安全吗？有关详细信息。仅当您需要融合加密的属性时，才建议使用此方案。否则，请使用随机IV。
我还建议使用标准MAC代替自制SHA-1结构。使用CBC时，必须首先验证MAC，然后再尝试解密消息，这一点很重要。否则，您可能会容易受padding-oracle攻击。
#3 楼
这取决于操作模式。在计数器模式下，可预测的IV很好。当然，文件哈希中的冲突将导致简单的纯文本恢复。从unix epoc开始，最好用微秒数填充高阶64位，用随机数填充其余64位，并使用低阶64位作为柜台。如果要在本地PC上加密内容，IV很难在该设置中发生冲突。
使用CBC确实需要随机选择它们。如BEAST所示，可预测的CBC IV可能导致攻击。
评论
$ \ begingroup $
我正在使用CBC，但是文件的哈希如何可预测？攻击者没有原始文件来生成哈希！
$ \ endgroup $
– RYN
2012年9月8日18:59
$ \ begingroup $
当攻击者可以进行选择的明文攻击（使明文适应IV）时，可预测的CBC模式IV主要是一个问题。在这种情况下，IV取决于（完整的）明文，因此选定的明文攻击者必须尝试一段时间才能获得“良好的”密文IV组合。 （但是我认为，选择的纯文本攻击对于文件加密方案并不是真正的问题。）
$ \ endgroup $
–PaŭloEbermann
2012年9月8日20:08
#4 楼
MS SQL服务器的“始终加密”功能使用AES-256 CBC，它们从HMAC-SHA256导出一些内容，该内容包括要加密的数据库单元以及加密密钥（以及一些固定值）。MS Doc-数据加密算法
When using deterministic encryption: IV = HMAC-SHA-256( iv_key, cell_data ) truncated to 128 bits
iv_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell IV key" + algorithm + CEK_length)
因此，至少有一些广泛部署的crytosystem采取这种方法。
评论
$ \ begingroup $
作为附带说明，如果您存储HMAC派生的IV并将其用作身份验证令牌，则实际上您确实具有可证明的安全确定性身份验证方案（DAE）：SIV。 （请参阅Rogaway和Shrimpton的DAE论文。）当然，除非有Thomas提到的限制，否则标准（非确定性）AE方案会更好。
$ \ endgroup $
–赛斯
2012年9月9日19:24
$ \ begingroup $
“似乎有希望的方式”是什么意思？无上下文确定性加密的当前最佳实践是什么？
$ \ endgroup $
– aggsol
17-10-19在7:16