AesCryptoServiceProvider嘗試使用錯誤的密鑰進行解密時的行爲

我使用AesCryptoServiceProvider和CryptoStream來加密某些數據，並且當我使用相同的密鑰進行解密時，似乎工作正常。但是，如果我試圖用錯誤的密鑰解密它，我不會得到一個例外，只是垃圾數據。我找不到.NET文檔在任何它說什麼是應該發生的，但是根據這樣的：AesCryptoServiceProvider嘗試使用錯誤的密鑰進行解密時的行爲

http://books.google.co.uk/books?id=_Y0rWd-Q2xkC&pg=PA631

這：

Why does a bad password cause "Padding is invalid and cannot be removed"?

我應該得到一個CryptographicException 。我做錯了嗎？我的功能是這樣的：

public static byte[] Encrypt(byte[] data, string password, string salt, bool decrypt) 
{ 
    SymmetricAlgorithm aes = new AesCryptoServiceProvider(); 
    Rfc2898DeriveBytes rfc2898 = new Rfc2898DeriveBytes(password, Encoding.UTF8.GetBytes(salt)); 
    aes.IV = rfc2898.GetBytes(aes.BlockSize/8); 
    aes.Key = rfc2898.GetBytes(256/8); 
    ICryptoTransform enc; 
    if (decrypt) { 
     enc = aes.CreateDecryptor(); 
    } else { 
     enc = aes.CreateEncryptor(); 
    } 
    using (enc) { 
     using (MemoryStream ms = new MemoryStream()) { 
      using (CryptoStream cs = new CryptoStream(ms, enc, CryptoStreamMode.Write)) { 
       cs.Write(data, 0, data.Length); 
      return ms.ToArray(); 
     } 
    } 
}

來源

2013-02-01 Andy

依靠填充錯誤不是確定密鑰是否正確的好方法。你應該考慮使用Authenticated Encryption來達到這個目的。

我有一個公共領域snip-it，它在C＃中爲此Modern Examples of Symmetric Authenticated Encryption of a string.工作，我試圖保持最新和審查。

P.S.此外，還不清楚您的salt是否來自您的樣本的每個域，每個用戶或每個密文，但是如果它不是代碼中的每個密文，那麼IV將是可預測的，而且對於AES-CBC不好的許多密文是相同的。實施加密非常困難。

我也曾在一個高級加密庫，C# port of Google Keyczar。但是這對你來說可能不是很好，它只支持隨機生成密鑰和密鑰集，然後這些密鑰集可以進行密碼加密，但只能使用密鑰集。高級加密框架是加密的最佳實踐。

來源

2013-02-01 13:37:08 jbtule

如果在解密時沒有設置填充，那麼解密方法將無法識別垃圾。將加密和PKCS＃7設置爲加密和加密，解密方法可能會識別垃圾。

爲了充分保證，您需要驗證，正如jbtule所說。要在一個數據傳遞中包含身份驗證和加密，請使用GCM mode。對於單獨的認證使用HMAC。

來源

2013-02-01 13:55:21 rossum

我不是想在這種情況下防止被修改的文檔，我只是想給當用戶輸入錯誤的密碼而不是崩潰時，用戶大部分時間都會收到明顯的錯誤消息。因此，似乎PKCS7填充應該是足夠的，但我已經檢查，它已經使用PKCS7作爲默認，所以我仍然不知道爲什麼我的程序不會給出例外 – Andy

PKCS填充將無法檢測到垃圾約1/256分之一的時間。不要依靠違約，明確表示。您似乎也正在生成一個用於解密的新密碼（字節）。在aes.Key中打印出確切字節的檢查 - 您需要檢查* byte-for-byte *中的解密密碼與加密密碼相同，而不是character-for-character。 – rossum

我將不得不把我的手放在這裏，說假報警。

我不知道星期五發生了什麼，但現在我得到了我所期望的 - 大部分時間CryptographicException都按預期發生。我不知道我是否對測試數據非常不安，或者測試工具中是否存在一個我無意中修復的錯誤，但現在所有的表現都如預期。

順便提一下，我做了一個快速的經驗性測試，驗證了rossum的1/256數字，但這對我的目的是可以接受的。在一般情況下，我完全接受這裏有關HMAC等的其他評論，但我正在做的是一個測試工具

來源

2013-02-04 11:51:57 Andy

AesCryptoServiceProvider嘗試使用錯誤的密鑰進行解密時的行爲

回答

相關問題