当前位置：首页 > news >正文

.NET AES 讲透：从 ECB 到 GCM，到底差在哪？

news 2026/5/15 16:06:15

AES，全称高级加密标准（Advanced Encryption Standard）。简单说，它是目前全球最主流的对称加密算法：同一把钥匙负责加密和解密。

HTTPS、手机文件加密、数据库、云存储……现代互联网里大量“数据保密”场景，背后基本都有 AES 的身影。

2001 年，NIST 从全球算法中选中了比利时团队设计的 Rijndael，AES 从此取代 DES，成为国际标准。二十多年过去，它依然是金融、政府、云计算领域最核心的加密方案之一。

那它和 JWT 有什么关系？

JWT 主要解决“你是谁、数据有没有被篡改”；AES 主要解决“别人能不能看到内容”。大部分 JWT 默认只是签名（JWS），并不是加密，Payload 通常可以直接 Base64 解码查看。

一个偏身份验证，一个偏数据保密，属于两条不同的技术线。

🔗 NIST AES 标准文档：

https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines

🔗 .NET 官方 AES 文档：

https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.aes

🔍 AES 的内核：切块、上锁、选模式

AES 是一个块加密算法。它的工作方式很粗暴：把明文切成每段 16 字节（128 位）的小块，然后用同一把密钥对每个块进行多次搅乱。根据密钥长度的不同，搅乱的轮数也不同：

128 位密钥 → 10 轮
192 位密钥 → 12 轮
256 位密钥 → 14 轮

实际使用中，AES 总要搭配一个“工作模式”。这个模式决定了数据块之间怎么关联，也直接决定了你这加密到底安不安全。四种最常见的模式：

ECB（千万别用）：每个块独立加密，相同明文产生相同密文。你用 ECB 给图片加密，轮廓还能看得一清二楚。这个模式存在的唯一价值是教科书上当反面教材。

CBC（老牌选手）：每个块先和前一个密文块做 XOR 运算再加密，需要一个 16 字节的随机 IV。CBC 的问题是只能保证机密性，不提供完整性验证——

CBC 无法验证数据是否被篡改，攻击者修改密文后，解密可能得到错误数据，也可能触发 Padding 异常，但无法可靠判断数据完整性。

GCM（目前首选）：会生成认证标签（Tag），加密的同时生成一个认证标签。解密时如果数据在传输中被篡改过哪怕一个比特，标签立刻对不上，

CryptographicException直接甩你脸上。加密 + 防篡改，一步到位。.NET Core 3 起原生支持。

CTR（流加密）：把计数器加密后的结果和明文异或，适合实时流数据，不需要填充。同样不带认证，需要搭配 HMAC 使用。

⚡ .NET 里怎么用？

如果你的项目是 .NET Core 3 及以上，直接用 GCM，别回头看 CBC。

using System.Security.Cryptography; // GCM 模式——目前推荐的做法 var key = RandomNumberGenerator.GetBytes(32); // 256 位密钥 var nonce = RandomNumberGenerator.GetBytes(12); // GCM 推荐 12 字节随机数 byte[] ciphertext; byte[] tag; using var aes = new AesGcm(key, 16); // 认证标签 16 字节 var plaintext = Encoding.UTF8.GetBytes("要加密的内容"); ciphertext = new byte[plaintext.Length]; tag = new byte[16]; // 加密：输出密文 + 认证标签 aes.Encrypt(nonce, plaintext, ciphertext, tag); // 解密：认证标签不匹配直接抛异常 try { var decrypted = new byte[ciphertext.Length]; aes.Decrypt(nonce, ciphertext, tag, decrypted); var result = Encoding.UTF8.GetString(decrypted); Console.WriteLine($"解密成功：{result}"); } catch (CryptographicException) { Console.WriteLine("数据被篡改过，别用！"); }

如果你的项目还在跑 .NET Framework 4.x，只能用 CBC 模式。这种情况下三个硬规则：IV 必须随机、和密文一起存、一次一密。

// CBC 模式——老项目用这个 using var aes = Aes.Create(); aes.Mode = CipherMode.CBC; aes.KeySize = 256; aes.GenerateKey(); // 生产环境密钥放 Key Vault aes.GenerateIV(); // IV 必须每次随机生成 using var encryptor = aes.CreateEncryptor(); var plaintext = Encoding.UTF8.GetBytes("要加密的内容"); var ciphertext = encryptor.TransformFinalBlock(plaintext, 0, plaintext.Length); // IV 需要和密文一起存，解密时拿出来用 var result = aes.IV.Concat(ciphertext).ToArray();

🎯 实际开发中到底用在哪儿？

数据库敏感字段加密：用户的手机号、身份证号、银行卡号入库前用 AES 加密。别直接对密文做 LIKE 模糊查询——密文不按套路出牌。推荐做法是敏感字段加密存储完整值，查询用哈希值建索引，或者直接用数据库自带的 Always Encrypted 功能。

配置文件保护：数据库连接字符串、第三方 API Key 别明文躺在appsettings.json里。ASP.NET Core 的 Data Protection API 内置了自动密钥轮换和 AES 算法封装。容器化部署需要额外配置密钥持久化路径，不然每次重启换个密钥，上次密文全解密不了。

文件落盘加密：用户上传的身份证照片、合同 PDF 存到 OSS 或本地磁盘前先过一层 AES。大文件别一次性加载进内存——用CryptoStream流式处理，分块读写。GCM 适合静态文件整体加密；CTR 模式适合流式传输，但需要额外补 HMAC 做认证。

数据在外部传输：已经有 HTTPS 了，应用层再套一层 AES 多数属于画蛇添足——双重加密不仅浪费 CPU，还可能引入额外的密钥分发问题。只有在端到端需要独立于 TLS 协议层的加密时才加。