在 AES 加密文件中是否有 Salt 和 IV 的标准位置答案

【问题标题】：Is there a standard place for the Salt and IV in an AES encrypted file在 AES 加密文件中是否有 Salt 和 IV 的标准位置
【发布时间】：2013-11-21 23:30:21
【问题描述】：

这都是用 C# 编码的，但我认为这对这个问题没有太大影响。

目前，我正在为 Key/IV/Salt 生成和放置镜像 OpenSSL 功能。我只是想知道，有没有我应该遵守的标准？

目前我从前 16 个字节中获取盐（减去“Salted__”名称）。然后我使用盐和密码生成密钥和 IV。在加密端，我也在做同样的事情，使用随机生成的 Salt。

这是行业标准吗？或者，如果我将其发送给使用不同产品的人，他们是否可能无法解密我的文件（即使我们从中获取所有内容的密码可能相同）？

另外作为旁注，这是生成 iv 的安全方式吗？还有其他安全问题吗？

这个问题是与给我密钥而不是密码的外部实体对话的结果。这不会使盐变得多余，因为键不会发生变化吗？

【问题讨论】：

我想你会在security.blogoverflow.com得到更好的回应
@Marko blogoverflow？ :P
复制粘贴错误我的意思是security.stackexchange.com

标签： c# encryption aes

【解决方案1】：

目前，我正在为 Key/IV/Salt 生成和放置镜像 OpenSSL 功能。我只是想知道，有没有我应该遵守的标准？

有多种标准，但 OpenSSL 是专有的。已知的标准是 CMS 和 OpenPGP，这两个标准都是免费的并且很容易找到。

这是行业标准吗？或者，如果我将其发送给使用不同产品的人，他们可能无法解密我的文件。

当然，他们总是可以下载 openssl。您现在也有可能使用 OpenSSL 的专有密钥 EVP_BytesToKey 派生。可以实现，但是严重不标准——OpenSSL应该也实现了PBKDF2。

另外作为旁注，这是生成 iv 的安全方式吗？还有其他安全问题吗？

只要盐（以及生成的数据密钥）始终不同，它就是安全的。最大的安全问题是缺少完整性/身份验证。您应该始终为通信协议添加 MAC。

这个问题是与给我密钥而不是密码的外部实体对话的结果。这不会使盐变得多余，因为键不会发生变化吗？

只要您为每次加密创建一个随机 IV，密钥就不必改变。

【讨论】：

感谢您的回复。不过，OpenSSL 不是专有的，它是开源的。您能否对您引用的两个标准提供一些解释？例如，CMS 对 Salt/IV 的位置有何评价？我查看了 rfc，但没有看到对它的引用
这些标准的问题在于它们相当复杂，而且它们大多与非对称加密一起使用。如果您使用混合加密，那么您每次都可以使用不同的对称密钥，因此无需存储 IV。我对 OpenSSL 的意思是它的对称加密方法不符合书面/商定的标准。所以它是 OpenSSL 专有的，即使 OpenSSL 不是任何人的财产。

【解决方案2】：

Salt 和/或 IV 通常预先添加到密文中。接收器知道它们在那里以及它们的大小，因此可以轻松地将它们移除。在您的情况下，您正在生成 IV，因此您只需要在加密时添加固定长度的盐。

【讨论】：