在 URL 中传递对称加密数据或可能将加密数据存储在 cookie 中时，是否合理和/或必要和/或也可以在同一 URL 中传递对称加密 IV (Salt)？在网络等无状态环境中使用 Salt 的想法是否有效？
（我了解 salt 在给定名称或帐户等列表的数据库中是如何工作的，但鉴于我们在无状态环境中传递数据，我们无法保存 salt。
假设一个服务器端密码是用来加密数据然后解密数据的，Salt怎么用呢？我猜可以在查询字符串中传递一个单独的 IV，但公开暴露盐好吗？
或者可以从“密码”的散列中生成密钥和 IV。假设 IV 和 Key 来自哈希的非重叠区域，这可以吗？ （我意识到给定密码的盐/密钥将始终相同。）
编辑：通常使用 AES。
【问题讨论】：
标签： encryption platform-agnostic
鼓励为每个加密例程生成随机 IV，它们可以与密文一起安全地传递。
编辑：
我可能应该问一下您要存储什么类型的信息以及为什么要使用带有 AES 加密的盐，因为盐通常用于散列，而不是对称加密。如果盐是公开的，它就违背了拥有它的目的。
您真正需要做的是确保密钥的强度，因为如果攻击者拥有盐、IV 和密文，则很容易对较弱的密钥进行暴力攻击。
【讨论】：
您不应从密钥生成初始化向量。对于给定的消息，初始化向量应该是不可预测的；如果您从密钥（或用于生成密钥的密码）生成它，IV 将始终相同，这违背了它的目的。
但是，IV 不需要保密。用密文发送它是很常见的，不受保护。在 URL 中加入 IV 比尝试在某些服务器端状态下尝试跟踪给定链接的 IV 要容易得多。
Salt 和 IV 有不同的应用，但它们的作用方式相似。
加密“盐”用于基于密码的密钥派生算法；存储用于身份验证的散列密码是此功能的特例。 Salt 使相同的密码产生不同的哈希值，并阻止“字典攻击”，在这种攻击中，黑客预先计算了常见密码的哈希值，并建立了一个“反向查找”索引，以便他们可以快速发现给定密码的密码哈希。和静脉注射一样，使用的盐也不是秘密。
初始化向量与 DES 和 AES 等分组密码一起用于 CBC 等反馈模式。每个块在加密时与下一个块组合。例如，在 CBC 下，前一个块密文在加密之前与当前块的纯文本进行异或运算。 IV 是随机生成的，用作引导进程的虚拟初始块。
因为（或至少应该）为每条消息选择不同的 IV，所以当使用相同的密钥对相同的消息进行加密时，生成的密文是不同的。从这个意义上说，静脉注射与盐非常相似。加密随机生成器通常是盐或 IV 的最简单和最安全的来源，因此它们也具有相似性。
密码学很容易搞砸。如果您对自己的工作没有信心，则应考虑所保护信息的价值，并相应地进行预算以获得所需的培训或咨询。
【讨论】：