URL和salt中的加密数据

Question

当在URL中传递对称加密的数据或者可能将加密的数据存储在cookie中时，它是否合理和/或必要和/或可能同时在同一URL中传递Symetric Encryption IV（Salt）？使用Salt的想法是否在无状态环境（例如网络）中有效？

（我理解盐如何在给定名单或帐户等的数据库中工作，但鉴于我们在无状态环境中传递数据，我们无法保存盐。

假设服务器端密码用于加密数据然后解密数据，那么如何使用Salt？我猜一个单独的IV可以在查询字符串中传递但是公开暴露盐好吗？

或者可以从“密码”的散列中生成密钥和IV。假设IV和Key来自哈希的非重叠区域，这可以吗？ （我意识到给定密码的salt / key总是相同的。）

编辑：通常使用AES。

Answer 1

鼓励为每个加密例程生成随机IV，并且可以使用密文安全地传递它们。

修改

我应该问一下你要存储什么类型的信息以及为什么你使用带有AES加密的盐，因为盐通常用于散列，而不是对称加密。如果盐是公开的，它就会失去获得它的目的。

您真正需要做的是确保密钥的强度，因为如果攻击者拥有salt，IV和密文，则可以轻松地对较弱的密钥进行暴力攻击。

Answer 2

您不应该从密钥生成初始化向量。对于给定的消息，初始化向量应该是不可预测的;如果你从密钥（或用于生成密钥的密码）生成它，则IV将始终相同，这将失去其目的。

然而，IV并不需要保密。用密文发送它是很常见的，没有保护。将URL合并到URL比在某些服务器端状态下尝试跟踪给定链接的IV要容易得多。

---

盐和静脉注射具有不同的应用，但它们确实以相似的方式起作用。

加密“salt”用于基于密码的密钥派生算法;存储用于身份验证的哈希密码是此功能的特例。 Salt导致相同的密码产生不同的哈希值，并阻止“字典攻击”，黑客已经为常见密码预先计算了哈希值，并构建了一个“反向查找”索引，以便他们可以快速发现给定的密码哈希值。像IV一样，使用的盐不是秘密。

初始化向量与像CBC这样的反馈模式中的块密码（如DES和AES）一起使用。加密时，每个块与下一个块组合。例如，在CBC下，先前的块密文与加密前的当前块的纯文本进行异或。随机生成IV以用作虚拟初始块以引导该过程。

因为为每条消息选择了（或者应该至少）不同的IV，所以当使用相同的密钥加密相同的消息时，生成的密文不同。从这个意义上讲，IV与盐非常相似。加密随机生成器通常是盐或IV的最简单和最安全的来源，因此它们也具有相似性。

---

密码学非常容易搞砸。如果您对自己所做的事情没有信心，那么您应该考虑您所保护的信息的价值，并相应地预算以获得您需要的培训或咨询。