它是确定派生自密码字符串加密密钥和IV时使用的密码的SHA1哈希作为盐？ [英] Is it ok to use SHA1 hash of password as a salt when deriving encryption key and IV from password string?
问题描述
我用 Rfc2898DeriveBytes 来安全地生成，从用户提供的字符串密码加密密钥和初始化向量，用对称加密（例如AesManaged）使用。
I'm using Rfc2898DeriveBytes to securely generate encryption key and initialization vector from user-supplied string password, to use with symmetric encryption (e.g. AesManaged).
我要带密码作为盐参数的SHA1哈希 Rfc2898DeriveBytes 。这可以吗？如果没有，那么我应该在哪里得到的盐？解密，权当我需要的相同的盐？所以，我必须存储在某个地方未加密的 - 无抵押。如果非要存放安全，那么它只是成为另一个密码，不是吗？
I'm taking the SHA1 hash of password as a salt parameter to Rfc2898DeriveBytes. Is that ok? If not, then where should I get the salt from? I will need the same salt when decrypting, right? So I have to store it somewhere unencrypted - unsecured. If I have to store it securely, then it just becomes another "password", isn't it?
void SecureDeriveKeyAndIvFromPassword(string password, int iterations,
int keySize, int ivSize, out byte[] key, out byte[] iv)
{
// Generate the salt from password:
byte[] salt = (new SHA1Managed()).ComputeHash(Encoding.UTF8.GetBytes(password));
// Derive key and IV bytes from password:
Rfc2898DeriveBytes derivedBytes = new Rfc2898DeriveBytes(password, salt, iterations);
key = derivedBytes.GetBytes(keySize);
iv = derivedBytes.GetBytes(ivSize);
}
我已经使用常量（硬codeD）盐看出，和我见过的人抱怨它。我以为衍生盐的密码会是更好的主意，但我不知道这是一个最佳的解决方案。
I've seen using the constant (hard-coded) salt, and I've seen people complaining about it. I thought deriving salt from password would be the better idea, but I'm not sure this is an optimal solution.
不久，我有一个需要加密的文件，并通过用户密码字符串输入。我该如何正确使用 Rfc2898DeriveBytes 来获得安全加密密钥和IV？
Shortly, I have a file that needs to be encrypted, and password string input by user. How do I properly use Rfc2898DeriveBytes to derive secure encryption key and IV?
感谢。
编辑：
谢谢您的回答。我现在明白了，主要的（也许只？）盐的目的是使代彩虹表不可能的 - 你不能pre-产生的P @ $$ w0rd的哈希，因为这将有一个不同的hash对于每个可能的盐值。我明白这完美，但......这真的是相关的对称加密？我不是存储哈希的任何地方吗？因此，即使攻击者具有对所有可能的密码组合的彩虹表，他也做不了什么，对吧？
Thanks for your answers. I now understand that the main (maybe only?) purpose of salt is to make generation of rainbow tables impossible - you can't pre-generate the hash of "P@$$w0rd" because it will have a different hash for each possible salt value. I understand this perfectly, BUT... Is this really relevant to symmetric encryption? I'm not storing the hash anywhere right? So even if the attacker has the rainbow table for all possible password combinations, he can't do much, right?
所以，我现在的问题是：有没有使用随机盐中的每个加密操作，比使用密码衍生的（甚至是硬codeD）盐的任何好处，对称加密时，算法（如.NET的AesManaged）？
So, my question now is: Is there any advantage of using the random salt in each encryption operation, compared to using password-derived (or even hard-coded) salt, when used with symmetric encryption algorithms (like AesManaged of .NET)?
推荐答案
的盐应该是唯一的每个密码，这意味着创建一个随机密码，你想每一个哈希密码。盐是不可以秘密，并且可以存储纯文本的计算哈希值。
A salt should be unique for each password, that means create a random password for every password you want to hash. The salt is not a secret and can be stored plain text with your calculated hash-value.
盐的想法是，攻击者不能用一个prebuilt rainbowtable，以获得密码。他必须单独建立这样一个rainbowtable每一个密码，这是没有意义的。它更容易暴力破解，直到找到一个匹配。
The idea of the salt is, that an attacker cannot use a prebuilt rainbowtable, to get the passwords. He would have to build such a rainbowtable for every password separately, and this doesn't make sense. It's easier to brute-force, until you found a match.
有一个在<一个例子href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx">MSDN其中，盐是从操作系统的随机源得到。这是最好的，你可以做，以获得一个安全的盐，不从你的密码derrive吧。
There is an example in MSDN where the salt is gotten from the random source of the operating system. This is the best you can do, to get a safe salt, do not derrive it from your password.
这篇关于它是确定派生自密码字符串加密密钥和IV时使用的密码的SHA1哈希作为盐？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
