密码、Salt 和 IV，我需要所有这些吗？
如果我使用 Rijndael CBC 模式，我不知道为什么我们需要盐。 我的理解是即使人们知道密码，但没有IV他也无法获取数据。 所以从我的角度来看，密码+IV似乎就足够安全了。
我有什么错吗？
If I am using Rijndael CBC mode, I have no idea why we would need salt.
My understanding is even if people know the password, but he cannot get the data without IV.
So from my perspective, password + IV seem to be sufficent secure.
Do I get anything wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，您需要所有这些东西。
Salt（和“迭代计数”）用于从密码中派生密钥。有关详细信息，请参阅 PKCS #5。用于密钥派生的盐和迭代计数不必是秘密的。然而，盐应该是不可预测的，并且最好随机选择。
CBC 模式需要一个初始化向量。这是由加密随机数生成器为每条消息生成的随机数据块。它充当密文的虚拟初始块。与密钥派生盐一样，它不必保密，通常与密文一起传输。
密码以及从中派生的密钥必须保密。即使攻击者拥有密钥导出和加密的参数以及密文，没有密钥他也无能为力。
更新：
密码不是随机选择的；有些密码比其他密码更有可能出现。因此，攻击者不是生成给定长度的所有可能的密码（穷举强力搜索），而是维护一个按概率递减排序的密码列表。
从密码派生加密密钥相对较慢（由于密钥派生算法的迭代）。获取几百万个密码的密钥可能需要几个月的时间。这将促使攻击者从最有可能的密码列表中导出密钥一次，并存储结果。有了这样的列表，他可以快速尝试使用列表中的每个密钥进行解密，而不是花费数月的计算时间来再次导出密钥。
然而，每一位盐都会使存储派生密钥所需的空间加倍，并且为每个可能的密码派生密钥所需的时间也会增加一倍。几个字节的盐，创建和存储这样的列表很快就变得不可行。
盐对于防止预计算攻击是必要的。
IV（或具有计数器模式的随机数）使相同的纯文本产生不同的密文。这可以防止攻击者利用纯文本中的模式从一组加密消息中获取信息。
需要初始化向量来隐藏消息中的模式。
一个用于增强密钥的安全性，另一个用于增强使用该密钥加密的每条消息的安全性。两者缺一不可。
Yes, you need all of these things.
Salt (and an "iteration count") is used to derive a key from the password. Refer to PKCS #5 for more information. The salt and iteration count used for key derivation do not have to be secret. The salt should be unpredictable, however, and is best chosen randomly.
CBC mode requires an initialization vector. This is a block of random data produced for each message by a cryptographic random number generator. It serves as the dummy initial block of ciphertext. Like the key-derivation salt, it doesn't have to be kept secret, and is usually transmitted along with the cipher text.
The password, and keys derived from it, must be kept secret. Even if an attacker has the parameters for key derivation and encryption, and the ciphertext, he can do nothing without the key.
Update:
Passwords aren't selected randomly; some passwords are much more likely than others. Therefore, rather than generating all possible passwords of a given length (exhaustive brute-force search), attackers maintain a list of passwords, ordered by decreasing probability.
Deriving an encryption key from a password is relatively slow (due to the iteration of the key derivation algorithm). Deriving keys for a few million passwords could take months. This would motivate an attacker to derive the keys from his most-likely-password list once, and store the results. With such a list, he can quickly try to decrypt with each key in his list, rather than spending months of compute time to derive keys again.
However, each bit of salt doubles the space required to store the derived key, and the time it takes to derive keys for each of his likely passwords. A few bytes of salt, and it quickly becomes infeasible to create and store such a list.
Salt is necessary to prevent pre-computation attacks.
An IV (or nonce with counter modes) makes the same plain text produce different cipher texts. The prevents an attacker from exploiting patterns in the plain text to garner information from a set of encrypted messages.
An initialization vector is necessary to hide patterns in messages.
One serves to enhance the security of the key, the other enhances the security of each message encrypted with that key. Both are necessary together.
首先，Rijndael 在 CBC 模式下没有“密码”。 CBC 模式下的 Rijndael 使用一个缓冲区来加密或解密、一个密钥和一个 IV。
“盐”通常用于加密密码。盐被添加到加密的密码中并与加密值一起存储。这可以防止有人构建所有密码如何加密的字典 - 您需要构建所有密码如何加密所有盐的字典。这实际上可以通过旧的 Unix 密码加密算法实现，该算法仅使用 12 位盐。 （它增加了 4096 的工作系数）。对于 128 位盐，这是不可能的。
当然，有人仍然可以对特定密码进行暴力攻击，前提是他们可以检索加密的密码。
然而，你有一个静脉注射，它的作用与盐的作用几乎相同。你不需要两者。或者更确切地说，静脉注射是您的盐。
顺便说一句，现在我们称之为“Rijndael”AES。
First things first: Rijndael does not have a "password" in CBC mode. Rijndael in CBC mode takes a buffer to encrypt or decrypt, a key, and an IV.
A "salt" is typically used for encrypting passwords. The salt is added to the password that is encrypted and stored with the encrypted value. This prevents someone from building a dictionary of how all passwords encrypt---you need to build a dictionary of how all passwords encrypt for all salts. That was actually possible with the old Unix password encryption algorithm, which only used a 12-bit salt. (It increased the work factor by 4096). With a 128-bit salt it is not possible.
Someone can still do a brute-force attack on a specific password, of course, provided that they can retrieve the encrypted password.
However, you have an IV, which does pretty much the same thing that a Salt does. You don't need both. Or, rather, the IV is your salt.
BTW, these days we call "Rijndael" AES.
salt 通常在使用 哈希算法。 Rijndael 不是哈希，而是一种双向加密算法。因此，加密数据不一定需要盐。话虽这么说，密码的加盐哈希可以用作加密数据的密钥。对于您正在寻找的内容，您可能希望查看混合密码系统。
密钥应被视为私有且不与您的加密数据一起传输，而 IV 可以与加密数据一起传输。
A salt is generally used when using a hash algorithm. Rijndael is not a hash, but a two-way encryption algorithm. Ergo, a salt is not necessarily needed for encrypting the data. That being said, a salted hash of a password may be used as the Key for encrypting data. For what you're looking for, you might wish to look at hybrid cryptosystems.
The Key should be considered private and not transmitted with your encrypted data while the IV may be transmitted with the encrypted data.