[英]Bad Length Error in Rsa encryption decryption
請幫助我識別以下 RSA 加密代碼中的問題
public static void Test()
{
CspParameters cspParams = new CspParameters { ProviderType = 1 };
RSACryptoServiceProvider rsaProvider = new RSACryptoServiceProvider(1024, cspParams);
var PublicKey = Convert.ToBase64String(rsaProvider.ExportCspBlob(false)); //I have to save it as string in some json/app.config configuration file
var PrivateKey = Convert.ToBase64String(rsaProvider.ExportCspBlob(true)); //I have to save it as string in some json/app.config configuration file
var encrypt = EncryptText(PublicKey, Encoding.UTF8.GetBytes(FromSomeFile()));
var decrypt = DecryptData(PrivateKey, encrypt);
}
static byte[] EncryptText(string publicKey, byte[] dataToEncrypt)
{
byte[] encryptedData;
using (RSACryptoServiceProvider rsa = new RSACryptoServiceProvider())
{
rsa.ImportCspBlob(Convert.FromBase64String(publicKey));
encryptedData = rsa.Encrypt(dataToEncrypt, false);
}
return encryptedData;
}
// Method to decrypt the data withing a specific file using a RSA algorithm private key
static string DecryptData(string privateKey, byte[] dataToDecrypt)
{
// Create an array to store the decrypted data in it
byte[] decryptedData;
using (RSACryptoServiceProvider rsa = new RSACryptoServiceProvider())
{
rsa.ImportCspBlob(Convert.FromBase64String(privateKey));
decryptedData = rsa.Decrypt(dataToDecrypt, false);
}
return Encoding.UTF8.GetString(decryptedData, 0, decryptedData.Length); ;
}
RSA 只能用於加密長度小於模數的消息。 小多少取決於填充,例如在 PKCS#1 v1.5 的情況下為 11 個字節,s。 在這里。 在 OAEP 的情況下,填充要求的字節數取決於使用的摘要,s。 在這里。 詳細信息在 RFC8017、 RSAES-PKCS1-v1_5和RSAES-OAEP中進行了描述。
為了完整性:沒有填充的 RSA(教科書 RSA)允許將消息加密到模數的長度。 然而,在實踐中,出於安全原因,必須始終使用填充,因此教科書 RSA 並不是一個真正的選擇。
發布的代碼使用 1024 位的 RSA 密鑰和 PKCS#1 v1.5 填充。 因此,要加密的消息的最大大小為 117 個字節。 較大的消息會引發CryptographicException (Bad Length) 。 這就是你的問題的原因。
理論上,一個 8192 位(1024 字節)的密鑰將允許使用 PKCS#1 v1.5 填充對最長 1013 字節的消息進行加密。 但是,隨着密鑰大小 s 的增加,性能會急劇下降。 在這里。
對稱加密比非對稱加密性能更高。 因此,在實踐中,使用對稱加密(例如 AES)對較大的數據量進行加密。 然而,對稱加密存在通信伙伴必須交換對稱密鑰的問題。 非對稱加密,例如 RSA,通常用於此目的(混合加密),因為加密只需要公鑰(因此可以通過不安全的通道進行交換)。 但是,為了防止欺騙性地替換公鑰(中間人攻擊),通常需要復雜的公鑰基礎設施。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.