使用Rfc2898DeriveBytes進行AES 256位加密

我遇到了Rfc2898DeriveBytes與AES混淆的使用。下面是我發現的代碼....使用Rfc2898DeriveBytes進行AES 256位加密

public static string Decrypt(string encryptionKey, string cipherValue) 
    { 
     byte[] cipherBytes = Convert.FromBase64String(cipherValue); 
     using (var encryptor = Aes.Create()) 
     { 
      var pdb = new Rfc2898DeriveBytes(encryptionKey, new byte[] { (13 element byte array) }); 
      if (encryptor != null) 
      { 
       encryptor.Key = pdb.GetBytes(32); 
       encryptor.IV = pdb.GetBytes(16); 
       using (var ms = new MemoryStream()) 
       { 
        using (var cs = new CryptoStream(ms, encryptor.CreateDecryptor(), CryptoStreamMode.Write)) 
        { 
         cs.Write(cipherBytes, 0, cipherBytes.Length); 
         cs.Close(); 
        } 
        cipherValue = Encoding.Unicode.GetString(ms.ToArray()); 
       } 
      } 
     } 
     return cipherValue; 
    }

所以，「的CipherValue」被加密的字符串，同樣也適合「的encryptionKey」。如何使用AES和Rfc2898Derive字節的其他示例似乎不適合此代碼。我見過的其他例子有一些非常純文本代替上面的「encryptionKey」參數，但這些例子通常是演示加密而不是解密。

此代碼正用於解密我的應用程序的配置文件中的密碼。加密已經完成，我沒有資源可以告訴我它是如何完成的。我假設密碼是使用指定的「encryptionKey」和salt值加密的，以及默認的1000次迭代和最大大小的Key和IV。

我很好奇主要是關於「encryptionKey」參數如何計算的東西。「cipherValue」是什麼被解密，並給我正確的輸出。在這裏工作的方法是什麼，以及我看過的其他例子有什麼優點？

加密和安全性並不是我的強項西裝......讓我知道是否遺漏了任何重要的東西，這可能會爲我們提供更多的信息。提前致謝！

來源

2017-04-25 Crash5998

鹽必須隨機選擇（第二個參數爲Rfc2898DeriveBytes）。不要使用靜態鹽，因爲這會使密碼具有確定性，因此不會在語義上安全。觀察密文的攻擊者可以確定何時之前發送了相同的消息前綴。鹽不是祕密的，所以你可以把它和密文一起發送。通常，它只是在密文前面加上，然後在解密之前切掉。 –

RFC2898DeriveBytes是一個很差的命名落實PBKDF2，在RFC 2898.定義（爲什麼它的命名不佳部分是RFC 2898也描述了PBKDF1算法，這是PasswordDeriveBytes使用）

你可以閱讀鏈接的RFC部分中的完整算法，但它的作用是將密碼用作密鑰，然後取出鹽的HMAC和一些狀態數據，然後取出HMAC，然後取出HMAC，最大爲iterations。

其目的是獲取輸入密碼（低熵）並以可預測的方式將其轉換爲密碼密鑰（具有高熵），從而難以弄清楚原始密碼是什麼。

只要所有輸入相同，它就會產生相同的答案。但只是稍微改變任何輸入就會產生截然不同的答案。

如果你看到的其他方法通過使用Encoding.UTF8.GetBytes（）（或類似的）將密碼變爲密鑰，那麼是的：這是一個更好的方法（它更難以破解，並且它不會不管你的密碼多長時間）。

來源

2017-04-25 15:25:22 bartonjs

使用Rfc2898DeriveBytes進行AES 256位加密

回答

相關問題