URL 和 salt 中的加密数据
当在 URL 中传递对称加密数据或可能在 cookie 中存储加密数据时，在同一 URL 中传递对称加密 IV（盐）是否合理和/或必要和/或可能？ 在网络等无状态环境中使用 Salt 的想法是否有效？
（我了解盐在给定名称或帐户等列表的数据库中如何工作。但鉴于我们在无状态环境中传递数据，我们无法保存盐。
假设用于加密数据的服务器端密码，然后解密数据，如何使用Salt？我想可以在查询字符串中传递一个单独的IV，但可以公开暴露salt吗？
或者可以从“密码”的哈希值生成密钥和IV？密钥来自哈希的非重叠区域，这样可以吗？（我意识到对于给定的密码，盐/密钥将始终相同。）
编辑：通常使用 AES。
When passing symetrically encrypted data in a URL or possibly storing encrypted data in a cookie, is it resonable and/or nessassary and/or possible to also pass the Symetric Encryption IV (Salt) in the same URL? Is the idea of using Salt even valid in a stateless environment such as the web?
(I understand how salt works in a database given a list of names or accounts etc. but we can't save the salt given that we are passing data in a stateless environment.
Assuming a server side password that is used to encrypt data and then decrypt data, how can Salt be used? I guess a separate IV could be passed in the query string but is publicly exposing the salt ok?
Or can one generate a key and IV from the hash of a "password". Assuming the IV and Key come from non-overlapping areas of the hash, is this ok? (I realize that the salt / key will always be the same for a given password.)
EDIT: Typically using AES.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
鼓励为每个加密例程生成随机 IV，并且它们可以与密文一起安全地传递。
编辑：
我可能应该问一下您要存储什么类型的信息以及为什么要使用带有 AES 加密的盐，因为盐通常用于散列，而不是对称加密。 如果盐是公开可用的，那就违背了拥有它的目的。
你真正需要做的是确保密钥的强度，因为如果攻击者拥有盐、IV 和密文，则可以轻松地对较弱的密钥进行暴力攻击。
It is encouraged to generate random IVs for each encryption routine, and they can be passed along safely with the cipher text.
Edit:
I should probably ask what type of information you're storing and why you're using a salt with AES encryption, since salts are typically used for hashing, not symmetric encryption. If the salt is publicly available, it defeats the purpose of having it.
What you really need to do is ensure the strength of your key, because if an attacker has the salt, IV, and cipher text, a brute-force attack can easily be done on weaker keys.
您不应该从密钥生成初始化向量。 对于给定的消息，初始化向量应该是不可预测的； 如果您从密钥（或用于生成密钥的密码）生成它，则 IV 将始终相同，这违背了其目的。
然而，IV 不需要保密。 与未受保护的密文一起发送是很常见的。 将 IV 合并到 URL 中比尝试在某些服务器端状态下跟踪给定链接的 IV 容易得多。
盐和静脉注射有不同的应用，但它们的作用方式确实相似。
加密“盐”用于基于密码的密钥派生算法； 存储用于身份验证的散列密码是此函数的一个特例。 盐会导致相同的密码产生不同的哈希值，并阻止“字典攻击”，即黑客预先计算常用密码的哈希值，并构建“反向查找”索引，以便他们可以快速发现给定的密码哈希。 与静脉注射一样，所用的盐也不是秘密。
初始化向量与 DES 和 AES 等分组密码一起以 CBC 等反馈模式使用。 每个块在加密时都会与下一个块组合。 例如，在CBC下，前一个分组的密文在加密之前与当前分组的明文进行异或运算。 IV 是随机生成的，作为引导进程的虚拟初始块。
由于为每条消息选择（或至少应该）不同的IV，因此当使用相同的密钥对同一消息进行加密时，得到的密文是不同的。 从这个意义上说，静脉注射与盐非常相似。 加密随机生成器通常是盐或 IV 的最简单且最安全的来源，因此它们也具有这种相似性。
密码学很容易搞砸。 如果您对自己所做的事情没有信心，您应该考虑您所保护的信息的价值，并相应地制定预算以获得所需的培训或咨询。
You should not generate an initialization vector from the secret key. The initialization vector should be unpredictable for a given message; if you generated it from the key (or a password used to generate a key), the IV will always be the same, which defeats its purpose.
The IV doesn't need to be secret, however. It's quite common to send it with the ciphertext, unprotected. Incorporating the IV in the URL is a lot easier than trying to keep track of the IV for a given link in some server-side state.
Salt and IVs have distinct applications, but they do act in similar ways.
Cryptographic "salt" is used in password-based key derivation algorithms; storing a hashed password for authentication is a special case of this function. Salt causes the same password to yield different hashes, and thwarts "dictionary attacks", where a hacker has pre-computed hash values for common passwords, and built a "reverse-lookup" index so that they can quickly discover a password for a given hash. Like an IV, the salt used is not a secret.
An initialization vector is used with block ciphers like DES and AES in a feedback mode like CBC. Each block is combined with the next block when it is encrypted. For example, under CBC, the previous block cipher text is XOR-ed with the plain text of the current block before encryption. The IV is randomly generated to serve as a dummy initial block to bootstrap the process.
Because a different IV is (or should be, at least) chosen for each message, when the same message is encrypted with the same key, the resulting cipher text is different. In that sense, an IV is very similar to a salt. A cryptographic random generator is usually the easiest and most secure source for a salt or an IV, so they have that similarity too.
Cryptography is very easy to mess up. If you are not confident about what you are doing, you should consider the value of the information you are protecting, and budget accordingly to get the training or consultation you need.