为什么我需要使用Rfc2898DeriveBytes类（在.NET），而不是直接使用密码作为密钥或IV？ [英] Why do I need to use the Rfc2898DeriveBytes class (in .NET) instead of directly using the password as a key or IV?

问题描述

有什么用Rfc2898DeriveBytes，只是使用 Encoding.ASCII.GetBytes（string对象）之间的区别;

What is the difference between using Rfc2898DeriveBytes and just using Encoding.ASCII.GetBytes(string object);?

我曾与两种方法相对成功，前者是一个比较长缠绕方法，即，因为后者是简单到如此地步。似乎都让你做同样的事情，但最终我奋力看到使用前者优于后者的地步。

I have had relative success with either approach, the former is a more long winded approach where as the latter is simple and to the point. Both seem to allow you to do the same thing eventually but I am struggling to the see the point in using the former over the latter.

的基本概念，我已经能够把握的是，你可以串密码转换成
用于例如字节数组对称加密类， AesManaged 。通过RFC类，但你创建RFC对象时使用盐值和密码。我认为它更安全，但最好还是那一个没有受过教育的猜测！此外，它可以让你恢复了一定规模的字节数组，以及类似的东西。

The basic concept I have been able to grasp is that you can convert string passwords into byte arrays to be used for e.g a symmetric encryption class, AesManaged. Via the RFC class but you get to use salt values and password when creating your rfc object. I assume its more secure but still thats an uneducated guess at best! Also that it allows you to return byte arrays of a certain size, well something like that.

下面是几个例子来告诉你在哪里我来自哪里：

Here are a few examples to show you where I am coming from:

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password");

或

string password = "P@%5w0r]>";
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt");
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray);

在'rfcKey'对象现在可以对建立的。重点还是.IV特性使用
在对称加密算法类。

The 'rfcKey' object can now be used towards setting up the the .Key or .IV properties on a symmetric encryption algorithm class.

IE浏览器。

RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);

RJ应该是准备去！

'rj' should be ready to go !

混乱的一部分......所以，而不是使用rfcKey对象可我不只是用我的
myPassInBytes的服务，帮助建立我的RJ的对象？

The confusing part ... so rather than using the 'rfcKey' object can I not just use my 'myPassInBytes' array to help set-up my 'rj' object?

我试图在VS2008这样做的，最直接的答案是否定的。但你们有一个受过良好教育的答案，为什么RFC类是用来在我上面提到的其他选择？

I have tried doing this in VS2008 and the immediate answer is NO. But have you guys got a better educated answer as to why the RFC class is used over the other alternative I have mentioned above?

推荐答案

您真的，真的不希望直接使用用户密码作为加密密钥，尤其的使用AES。

You really, really do not want to use a user password directly as a crypto key, especially with AES.

Rfc2898DeriveBytes是PBKDF2的实现。它所做的是与盐一起反复哈希的用户密码。这有多方面的好处：

Rfc2898DeriveBytes is an implementation of PBKDF2. What it does is repeatedly hash the user password along with the salt. This has multiple benefits:

首先，你可以使用任意大小的密码 - AES只支持特定的按键尺寸

Firstly, you can use arbitrarily sized passwords - AES only supports specific key sizes.

其次，在加入盐的装置，可以使用相同的密码来生成多个不同的密钥（假设该盐不是恒定的，因为它是在你的例子）。这是为密钥分离重要;在不同的上下文中重新使用的键是最常见的方式的加密系统被破坏之一。

Secondly, the addition of the salt means that you can use the same passphrase to generate multiple different keys (assuming the salt is not a constant, as it is in your example). This is important for key separation; reusing keys in different contexts is one of the most common ways cryptographic systems are broken.

在多次迭代（1000默认值）减缓密码猜测攻击。考虑别人谁是试图猜测你的AES密钥。如果你只是使用的密码，这将是简单 - 只是尝试每一个可能的密码作为密钥。另一方面，与PBKDF2，攻击者首先要执行1000散列迭代的每个的密码猜测。因此，尽管它减慢用户仅稍微，它有上的攻击者不成比例的效果。 （其实这是相当普遍的是使用高得多的迭代次数10000通常推荐）。

The multiple iterations (1000 by default) slow down password guessing attacks. Consider someone who is trying to guess your AES key. If you just used the password, this would be straightforward - just try each possible password as the key. On the other hand, with PBKDF2, the attacker first has to perform 1000 hash iterations for each password guess. So while it slows down a user only slightly, it has a disproportionate effect on an attacker. (In fact it's quite common to use much higher iteration counts; 10000 is commonly recommended).

这也意味着最终输出键是均匀分布的。如果使用的密码，例如，通常为16出来的密钥的128位是0（高ASCII位）。这一权利立即使得更容易keysearch 65536倍，比它应该是，即使忽略了密码猜测。

It also means the final output key is uniformly distributed. If you used the password, for instance, typically 16 out of 128 bits of the key would be 0 (the high ASCII bit). That right there immediately makes keysearch 65536 times easier than it should be, even ignoring the password guessing.

最后，AES与相关密钥攻击特定漏洞。当攻击者知道有几个密钥加密一些数据，并有一些已知（或猜测的），它们之间的关系相关密钥攻击是可能的。举例来说，如果你的我的AES密钥吸既是一个密码密钥加密的数据（16个字节，对于AES-128），并以我的AES密钥SUCKS，相关密钥攻击是可能的。目前最有名的攻击并没有真正让破满AES这样，但他们已随着时间的推移逐渐好起来 - 就在上周，一个新的攻击发表的AES-256使用，打破了13轮（14组共）一个相关密钥攻击。这将是不明智的深刻依靠这样的攻击不会随着时间的推移越来​​越好。

Finally, AES has specific vulnerabilities with related key attacks. Related key attacks are possible when an attacker knows some data encrypted with several keys, and there is some known (or guessed) relation between them. For instance, if you encrypted data with both a password-key of "My AES key sucks" (16 bytes, for AES-128) and with "MY AES KEY SUCKS", a related key attack might be possible. The currently best known attacks do not actually allow breaking the full AES in this way, but they have been getting progressively better over time - just last week a new attack was published that breaks 13 rounds (out of 14 total) of AES-256 using a related key attack. It would be profoundly unwise to rely on such attacks not getting better over time.

这篇关于为什么我需要使用Rfc2898DeriveBytes类（在.NET），而不是直接使用密码作为密钥或IV？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！