这些都是用C＃编码的，但我不认为这对这个问题有很大影响。
目前，我正在镜像Key / IV / Salt生成和放置的OpenSSL功能。我只是想知道，我应该坚持哪个标准？
目前我从前16个字节中获取盐（减去“Salted__”指定）。然后我使用salt和密码生成密钥和IV。在加密端，我正在做同样的事情，随机生成Salt。
这是行业标准吗？或者，如果我将此信息发送给使用其他产品的人，他们是否可能无法解密我的文件（即使我们从中获得的密码可能相同）？
另外作为旁注，这是一种生成iv的安全方式吗？还有其他安全问题吗？
这个问题是与外部实体交谈的结果，它给了我一个密钥而不是密码。这不会使盐变得多余，因为密钥没有变化吗？
答案 0 :(得分：2)
目前，我正在镜像Key / IV / Salt生成和放置的OpenSSL功能。我只是想知道，我应该坚持哪个标准？
有多种标准，但OpenSSL是专有的。已知的标准是CMS和OpenPGP，这两个标准都是免费且易于查找的。
这是行业标准吗？或者，如果我将此信息发送给使用其他产品的人，他们是否可能无法解密我的文件。
嗯，他们当然可以随时下载openssl。您现在也有可能使用OpenSSL的专有密钥EVP_BytesToKey派生。它可以实现，但严重不标准 - 也应该有OpenSSL实现的PBKDF2。
另外作为旁注，这是一种生成iv的安全方式吗？还有其他安全问题吗？
只要盐（以及生成的数据密钥）总是不同，它就是安全的。最大的安全问题是缺少完整性/身份验证。您应该始终为通信协议添加MAC。
这个问题是与外部实体交谈的结果，它给了我一个密钥而不是密码。这不会使盐变得多余，因为密钥没有变化吗？
只要为每次加密创建一个随机IV，就没有密钥变化。
答案 1 :(得分：0)
盐和/或IV通常在密文之前。接收器知道它们在那里以及它们的大小，因此可以很容易地将它们移除。在您的情况下，您正在生成IV，因此您只需在加密时添加固定长度的盐。