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

AES全称高级加密标准Advanced Encryption Standard。简单说它是目前全球最主流的对称加密算法同一把钥匙负责加密和解密。HTTPS、手机文件加密、数据库、云存储……现代互联网里大量“数据保密”场景背后基本都有 AES 的身影。2001 年NIST 从全球算法中选中了比利时团队设计的 RijndaelAES 从此取代 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 协议层的加密时才加。❌ 几个让你前功尽弃的坑密钥硬编码很多人图方便直接把密钥写在配置文件里。代码一提交 GitHub密钥就全网公开了。生产环境用 Azure Key Vault、AWS KMS 或 HashiCorp Vault 管密钥别跟自己饭碗开玩笑。ECB 还活着年轻同事不知道模式有什么后果随手就CipherMode.ECB。代码审查碰到这个直接打回我老团队的 Reviewer 碰见 ECB 连原因都不写直接给 -1。用错算法有人到处搜教程抄回来一个DES或RC2——这些算法早就被破了现代计算机几小时暴力就能搞定。.NET 下直接用Aes.Create()它会给你当前平台最优的 AES 实例。IV 写死有人为了“不出错”把 IV 写了个常量。CBC 下相同密钥 相同 IV 相同明文 相同密文加密模式直接退化回 ECB。IV 不需要保密但必须每次加密随机生成。 总结AES 干了二十多年至今没被打趴下证明它的数学底子足够硬。但算法再硬也架不住用的人瞎搞——选 ECB 模式、IV 写死、密钥硬编码任何一个低级错误都能让 AES 变成玻璃窗。用 GCM选对密钥长度IV 每次随机生成管好你的密钥。这四条做到了AES 就是你系统里最硬的那块骨头。做不到它就是你自欺欺人的遮羞布。