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