发布于2026-07-18 阅读(0)
扫一扫,手机访问
RSA 这个算法有个硬伤——它根本没法直接加密长字符串。明文长度受密钥位数严格限制,比如 2048 位的 RSA,最多只能啃下 245 字节(PKCS#1 v1.5 填充)或 190 字节(OAEP 填充),一旦超限就会抛出 CryptographicException。相比之下,AES 才是处理大块数据的正经选手。所以工业界的标准做法一直是:用 RSA 加密 AES 的密钥,再用 AES 加密实际数据——也就是所谓的“混合加密”。

一句话总结:AES 和 RSA 不能混着用同一个场景直接加密数据;AES 适合加密大量内容,RSA 只能加密很短的字节(比如 AES 密钥),否则你会撞上 CryptographicException: Bad Data 或 KeySize too small 这类错误。
RSA 是非对称算法,它的加密长度受密钥长度死死卡住。举个例子:2048 位的 RSA,最多只能加密 245 字节(PKCS#1 v1.5)或 190 字节(OAEP)的明文。超出这个范围?直接炸,CryptographicException 伺候。现实业务中,你要传输的 JSON、XML 或者用户输入,随随便便就几百上千字节,硬塞进去只会让解密端一脸懵。
RSACryptoServiceProvider 或 RSA.Create() 加密前,务必先检查明文字节数:Encoding.UTF8.GetBytes(input).LengthRSA.Encrypt(),结果运行时解密端直接报错同一个 Aes 实例,调用 CreateEncryptor() 和 CreateDecryptor() 才能保证 IV 和 Key 内部状态完全一致。跨实例、跨方法、甚至跨线程复用,解密时会报 CryptographicException: The input data is not a complete block,或者给你一堆乱码。
Aes.GenerateIV()),千万别复用或硬编码[IV][AES ciphertext],解密时先取前 16 字节作 IV,再用剩余部分解密AesManaged(已过时),改用 Aes.Create() —— 它默认启用硬件加速,而且更安全标准流程是这样的:先用 AES 加密原始数据,再用 RSA 公钥加密 AES 的 Key(注意不是 IV),最后把加密后的 AES 密钥 + IV + AES 密文打包发送。接收方先用 RSA 私钥解出 AES Key,再用这个 Key 加上 IV 去解 AES 密文。
Aes.Key 自动生成X509KeyStorageFlags.Exportable),否则 ExportParameters(true) 会抛出 Key not valid for use in specified statebyte[] aesKey = aes.Key; // 随机生成
byte[] encryptedAesKey = rsa.Encrypt(aesKey, RSAEncryptionPadding.OaepSHA256);
答案很明确:不能再用于安全敏感场景。MD5 已经被证明可以碰撞,DES 密钥太短(56 位),DES 和 TripleDES 在 .NET 6+ 中已经被标记为 [Obsolete],运行时会出现警告;MD5CryptoServiceProvider 同样过时。
Rfc2898DeriveBytes(即 PBKDF2)+ 盐值,而不是 MD5 哈希SHA256 或 SHA512,别再用 MD5.ComputeHash()TripleDES 并确保模式为 CBC、填充为 PKCS7,但强烈建议推动升级到 AES最容易被忽略的细节是:AES 的 Mode 和 Padding 必须在两端完全一致(比如都设为 CipherMode.CBC 和 PaddingMode.PKCS7),哪怕只差一个枚举值,解密就会静默失败或者抛异常。别依赖默认值,显式设置才是王道。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8