問題描述

使用 Rfc2898DeriveBytes 和只使用 Encoding.ASCII.GetBytes(string object); 有什么區(qū)別?

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.

我能掌握的基本概念是可以將字符串密碼轉(zhuǎn)換成要用于例如對稱加密類 AesManaged 的字節(jié)數(shù)組.通過 RFC 類，但您可以在創(chuàng)建 rfc 對象時使用鹽值和密碼.我認(rèn)為它更安全，但充其量仍然是一個沒有受過教育的猜測！此外，它還允許您返回一定大小的字節(jié)數(shù)組，以及類似的東西.

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"對象現(xiàn)在可用于設(shè)置 .Key 或 .IV 屬性關(guān)于對稱加密算法類.

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

即.

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

'rj' 應(yīng)該準(zhǔn)備好了！

'rj' should be ready to go !

令人困惑的部分......所以我可以不只使用我的rfcKey"對象嗎?'myPassInBytes' 數(shù)組來幫助設(shè)置我的 '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 中執(zhí)行此操作，但立即回答是否定的.但是對于為什么使用 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 的實現(xiàn).它的作用是反復(fù)對用戶密碼和鹽進行哈希處理.這有很多好處:

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.

其次，添加鹽意味著您可以使用相同的密碼來生成多個不同的密鑰(假設(shè)鹽不是常數(shù)，就像在您的示例中那樣).這對于密鑰分離很重要；在不同的上下文中重復(fù)使用密鑰是密碼系統(tǒng)被破壞的最常見方式之一.

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.

多次迭代(默認(rèn)為 1000 次)減緩密碼猜測攻擊.考慮有人試圖猜測您的 AES 密鑰.如果您只是使用密碼，這將很簡單 - 只需嘗試每個可能的密碼作為密鑰.另一方面，對于 PBKDF2，攻擊者首先必須為 each 密碼猜測執(zhí)行 1000 次哈希迭代.因此，雖然它只會稍微減慢用戶的速度，但它對攻擊者的影響卻不成比例.(事實上??，使用更高的迭代次數(shù)是很常見的；通常建議使用 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).

這也意味著最終的輸出密鑰是均勻分布的.例如，如果您使用密碼，通常 128 位密鑰中的 16 位將為 0(高 ASCII 位).就在那里，即使忽略密碼猜測，keysearch 也會比它應(yīng)該的容易 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 具有與相關(guān)密鑰攻擊相關(guān)的特定漏洞.當(dāng)攻擊者知道一些用多個密鑰加密的數(shù)據(jù)，并且它們之間存在某種已知(或猜測)的關(guān)系時，相關(guān)密鑰攻擊是可能的.例如，如果您使用我的 AES 密鑰很爛"(對于 AES-128 為 16 個字節(jié))和我的 AES 密鑰很爛"的密碼密鑰加密數(shù)據(jù)，則可能會發(fā)生相關(guān)的密鑰攻擊.目前最知名的攻擊實際上不允許以這種方式破壞完整的 AES，但隨著時間的推移，它們已經(jīng)逐漸變得更好 - 就在上周發(fā)布了一種新的攻擊，它使用 AES-256 破壞了 13 輪(總共 14 輪)相關(guān)的密鑰攻擊.依靠這種攻擊不會隨著時間的推移變得更好是非常不明智的.

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.

這篇關(guān)于為什么我需要使用 Rfc2898DeriveBytes 類(在 .NET 中)而不是直接使用密碼作為密鑰或 IV?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！