盐和 IV 不是一回事。salts 用于密码散列，IV 用于启动某些加密模式。不过，两者都不是秘密的。否则我们会称它们为“钥匙”。将 IV 和/或 salt 放在文件头中是安全的。

您添加“一些随机数据（256位，只是为了混水）”相当于牺牲一只鸡来祭祀上帝。如果需要这样的仪式才能让你感觉良好，那为什么不呢？但是相信它会改变您的实际安全性会有些天真。

CBC模式需要一个随机的、不可预测的IV；这是一个硬性要求。使用 UUID 在几个方面是危险的：

• 只有“v4”UUID 使用 PRNG。
• 没有人保证用于 UUID v4 的 PRNG 具有加密强度。
• 即使它很强大，UUID 中仍然有六个固定位（那些说“这是一个 v4 UUID”的位）；只有 122 位是随机的。

CBC 不再是课堂上最好的模式；我们发现更好。特别是：

• CBC 对 IV 生成有严格的要求（Chosen-Plaintext Attacks已被证明对较差的 IV 生成特别有效）。
• CBC 需要填充，并且填充处理已被证明是微妙的（如果操作不当，解密可能会变成“填充预言” ）。
• CBC 不确保完整性。通常，当您需要加密（出于机密性）时，您还需要可靠地检测恶意更改。为此，您需要一个MAC。组装 MAC 和加密是很棘手的。

较新的模式通过容忍简单的 IV（非重复计数器就足够了）、不需要填充以及在集成已充分完成的情况下具有集成 MAC 来解决这些问题。特别参见GCM和EAX。

回答你的问题：是的，在密文的开头写 IV 是完全安全的。

不过，当您在这里谈论“盐”时，我不确定您指的是什么：理论上，“盐”是一个随机值，它在通过单向哈希函数之前与明文值混合. 它存在的原因是为了确保相同的输入不会导致相同的输出，以防御生日攻击以及针对每个计算的哈希表。

在加密的情况下，您的操作模式的 IV 应该提供相同的功能。

至于选择哪种模式，很大程度上取决于您的要求：查看此答案和此页面，其中列出了几种操作模式及其优缺点。

如果您不知道最终数据的确切要求，您应该选择功能最多的模式（可能是 CWC 或 OCM）

一个未加密的、密码安全的散列理论上不应该提供任何关于消息内容的提示，只要消息是唯一的。但是，当窃听者怀疑该消息是有限数量的已知消息之一时，他们可以将散列与这些已知消息的散列进行比较，并找出它是其中之一。

示例：假设我将获得版权电影的非法副本，现在我想将其重新分发给您。版权所有者怀疑我是盗版电影，因此正在窃听我们的联系。他们知道互联网上流传的所有非法副本，并自己获取它们来计算它们的哈希值。

当我使用您的加密方案时，他们可以看到我发送的文件的哈希值，并将它们与他们拥有副本的文件的哈希值进行比较。当他们发现我的一条消息与他们的哈希值匹配时，他们以极高的确定性证明了我分发了他们受版权保护的内容，即使没有破解加密。

添加盐并没有多大帮助，因为当盐未加密时，他们可以使用每条消息的盐重新计算文件的哈希值。

在散列之前添加无意义的数据到“浑水”不会增加任何安全性，因为它只是默默无闻的安全性。密码分析师很快就会注意到数据可以被忽略。

结论：更好地加密散列和内容。