前段时间给一台用C#写的上位机做通信加密改造第一件事就是把原来那套AES-CBC加自定义校验的代码直接从代码库里删掉。AES-GCM这种带认证的加密模式哪怕只是原地替换也能把“防篡改”这个最容易被人忽略的问题一次性解决。身边不少搞C#的老哥还在用ECB/CBC要么是习惯了要么是真不知道GCM的存在。这篇就从头到尾讲清楚在C#里怎么把AES/GCM用明白不光是调一个AesGcm类还包括nonce和tag的存放、密钥管理、跨语言互操作、多线程使用等一堆工程细节。适合正在做上位机、API接口加密、客户端与服务端双向通信的C#开发者参考。1. 为什么我直接把AES-CBC的方案扔掉了1.1 CBC的“最后一米”问题CBC加密模式在C#里太常见了Aes.Create()加上CipherMode.CBC再补一个PKCS7填充看起来已经很完整。但这里有个致命盲区CBC只能保证机密性不能保证完整性。攻击者不需要知道密钥也能通过翻转密文分组里的某些bit让解密后的明文产生可预测的改动这就是常说的bit-flipping攻击。比如一段协议报文里某个字节是“是否放行”的控制位攻击者翻转对应密文的bit解密端读出来的可能就从0变成了1而整个过程完全不需要破解密钥。有人会说那我加密之后再加个CRC或者MD5不就能发现被改了吗CRC是线性校验攻击者改完密文完全可以重算CRC一起替换防御力为零。MD5验签这种方案稍微好一点但如果校验的是解密后的明文等于把校验逻辑暴露在外部而且很多自研协议根本就没做这一步。真正的问题在于加密和认证是两件独立的事CBC没有内置认证能力就必须在协议层面额外设计一套机制而绝大多数C#项目里的这套机制都做得不完整。1.2 GCM靠两个输出解决“防篡改”AES-GCM的工作方式不是先加密再另算一个摘要那么“拼装”而是从算法结构上就把认证绑定进来。GCM内部是CTR模式加密输出密文同时用GHASH做一次多项式运算输出一个认证标签tag。加密完你会得到两段东西密文ciphertext和认证标签tag。解密的时候算法先用密钥、nonce、AAD和收到的密文重新计算一次tag跟传入的tag做比对不一致直接抛异常一条明文都不会吐出来。这带来一个非常实际的好处密文里任何一位被改动、被截断、被重排tag校验都会失败。相当于把“加密”和“防篡改”合成一个原子操作不需要你再去设计一套HMAC方案或者自定义校验字段。GCM也支持关联数据AADAssociated Data意思是有些明文信息你不想加密但希望防篡改比如协议头、设备ID、时间戳把它们作为AAD传进去解密时只要AAD变了tag照样对不上。这个特性在通信协议里特别值钱。1.3 GCM与ChaCha20-Poly1305怎么选很多人在选型时也会纠结GCM和ChaCha20-Poly1305。两者都是AEAD安全性都经过业界广泛验证主要区别在硬件平台。现代x86 CPU和大多数手机SoC都有AES-NI指令集AES-GCM跑起来非常快在C#里用内置的AesGcm类就够了。如果目标设备是很低成本的MCU、物联网模块没有AES硬件加速那ChaCha20-Poly1305通常更友好软件实现效率更高C#这边可以用BouncyCastle里的ChaCha20Poly1305。我的原则是跑在PC/服务器上的C#程序无脑选AES-GCM跑在资源受限的嵌入式Linux或者单片机上再考虑ChaCha20-Poly1305。2. .NET里AesGcm的可用范围以及版本差异2.1 在哪个框架版本能用AesGcm这是第一个容易踩坑的地方。System.Security.Cryptography.AesGcm不是所有.NET版本都有的。它在.NET Core 3.0 / .NET 5及之后的内置运行时里才提供如果你的项目还在.NET Framework 4.x上直接using System.Security.Cryptography是找不到这个类的。目标框架AesGcm是否可用.NET Framework 4.x不可用.NET Core 2.x不可用.NET Core 3.0可用.NET 5 / 6 / 7 / 8可用API逐步完善.NET Standard 2.1理论可用实际取决于运行时很多老上位机项目还停留在.NET Framework 4.7.2这种情况下如果非要用GCM建议引入BouncyCastle包底下会讲怎么用它替代。如果项目已经从.NET Framework迁到.NET 6/8那直接用内置的AesGcm性能和API都更舒服。2.2 构造参数密钥、Tag长度和Nonce长度AesGcm的构造函数有两种用法new AesGcm(key)和new AesGcm(key, tagSizeInBytes)。第一种默认tag是16字节第二种可以自己指定tag长度。密钥长度支持16字节AES-128、24字节AES-192、32字节AES-256按业务安全要求选通信场景我一般直接上32字节。nonce必须传12字节96位。GCM标准本身允许其他长度的nonce但NIST特别推荐96位.NET实现也直接把它固定成了12字节传16字节会直接抛ArgumentException。这个和很多其他语言库的默认行为一致所以互操作时反而省心。tag长度支持12到16字节虽然13、14、15也允许但实际项目里建议固定16字节安全强度和通用性都最好。2.3 旧版.NET Framework怎么办如果你的项目还在.NET Framework 4.x上最靠谱的方案就是BouncyCastle。它的GcmBlockCipher封装了AES-GCM核心用法大概是这样的using Org.BouncyCastle.Crypto.Engines; using Org.BouncyCastle.Crypto.Modes; using Org.BouncyCastle.Crypto.Parameters; var cipher new GcmBlockCipher(new AesEngine()); var parameters new AeadParameters(new KeyParameter(key), 128, nonce, associatedData); cipher.Init(true, parameters); // true为加密false为解密 var output new byte[cipher.GetOutputSize(plaintext.Length)]; var len cipher.ProcessBytes(plaintext, 0, plaintext.Length, output, 0); cipher.DoFinal(output, len); // output就是密文tag的拼接结果注意这里AeadParameters构造函数的第二个参数是tag的bit数128对应16字节。解密时用GetOutputSize拿到的输出长度会自动去掉tag大小DoFinal之后拿到的就是纯明文。这套流程跟内置AesGcm的差异主要是BouncyCastle的加密结果默认把tag拼在密文后面而内置AesGcm是密文和tag分开输出拼接时需要自己处理。2.4 平台差异与底层库内置AesGcm在不同操作系统上的底层实现不一样Windows上走BCryptLinux上用OpenSSLmacOS上用CryptoKit。这意味着你在Windows上写代码、部署到Linux服务器上跑加解密结果在相同参数下是一致的都是标准算法不会有平台兼容问题。但有一点要注意某些精简版Linux容器镜像可能缺少OpenSSL依赖导致首次调用时报找不到实现。遇到这种问题检查一下容器的OpenSSL库是否完整别一上来就怀疑代码。平时开发最好在目标部署环境里做一轮完整的加解密冒烟测试。3. 手写一个能直接上生产的AesGcmHelper3.1 加密返回值的数据布局内置AesGcm.Encrypt接受nonce、plaintext输出ciphertext和tag。问题是它把密文和tag分开返回你直接拿去传输还得自己定一个存放格式。我建议的布局是[nonce 12字节][ciphertext字节][tag 16字节]把nonce放最前面解密时先读noncetag放最后读取时方便直接从末尾取不用额外记长度。整个payload再转成Base64或者Hex往外发既方便日志又方便调试。为什么不把nonce单独存一个字段因为加解密必须用同一个nonce如果nonce丢了或者错位tag校验必挂。把它和密文放一起保证两者永远是一套的省去很多协议设计上的烦恼。3.2 解密时的顺序和异常处理解密流程和加密相反先从payload里切出nonce再从末尾切出tag中间剩下的是ciphertext然后调用AesGcm.Decrypt。这里有个关键点先做长度校验再切分避免恶意数据把数组越界搞出来。解密失败时Decrypt会抛CryptographicException一定要在调用方捕获。我见过很多新手直接让异常往上抛最后UI弹一个“解密失败”的红色错误框用户一脸懵。正确的做法是捕获异常记录日志然后返回一个友好的业务错误。3.3 完整源码下面这个工具类我直接放在生产项目里用过API设计很简单传明文返回密文payload传payload返回明文支持可选的AAD参数。代码基于.NET 6/8用内置AesGcm。using System; using System.Security.Cryptography; public sealed class AesGcmHelper { private readonly byte[] _key; private const int NonceSize 12; private const int TagSize 16; public AesGcmHelper(byte[] key) { // AES-128 / AES-192 / AES-256 分别对应 16 / 24 / 32 字节密钥 if (key is not { Length: 16 or 24 or 32 }) throw new ArgumentException(密钥长度必须是16、24或32字节, nameof(key)); _key (byte[])key.Clone(); } public byte[] Encrypt(byte[] plaintext, byte[]? associatedData null) { if (plaintext null) throw new ArgumentNullException(nameof(plaintext)); byte[] nonce RandomNumberGenerator.GetBytes(NonceSize); byte[] ciphertext new byte[plaintext.Length]; byte[] tag new byte[TagSize]; using (var aes new AesGcm(_key, TagSize)) { aes.Encrypt(nonce, plaintext, ciphertext, tag, associatedData); } byte[] result new byte[NonceSize ciphertext.Length TagSize]; Buffer.BlockCopy(nonce, 0, result, 0, NonceSize); Buffer.BlockCopy(ciphertext, 0, result, NonceSize, ciphertext.Length); Buffer.BlockCopy(tag, 0, result, NonceSize ciphertext.Length, TagSize); return result; } public byte[] Decrypt(byte[] payload, byte[]? associatedData null) { if (payload null) throw new ArgumentNullException(nameof(payload)); if (payload.Length NonceSize TagSize) throw new CryptographicException(密文长度异常); byte[] nonce new byte[NonceSize]; byte[] tag new byte[TagSize]; byte[] ciphertext new byte[payload.Length - NonceSize - TagSize]; Buffer.BlockCopy(payload, 0, nonce, 0, NonceSize); Buffer.BlockCopy(payload, NonceSize, ciphertext, 0, ciphertext.Length); Buffer.BlockCopy(payload, payload.Length - TagSize, tag, 0, TagSize); byte[] plaintext new byte[ciphertext.Length]; using (var aes new AesGcm(_key, TagSize)) { aes.Decrypt(nonce, ciphertext, tag, plaintext, associatedData); } return plaintext; } public string EncryptToBase64(string plaintext, byte[]? associatedData null) { byte[] data System.Text.Encoding.UTF8.GetBytes(plaintext ?? string.Empty); return Convert.ToBase64String(Encrypt(data, associatedData)); } public string DecryptFromBase64(string payload, byte[]? associatedData null) { return System.Text.Encoding.UTF8.GetString(Decrypt(Convert.FromBase64String(payload), associatedData)); } }提一句RandomNumberGenerator.GetBytes在.NET 6及以上是静态方法省去了手动创建RNG实例的麻烦。如果你还在老版本上得用RandomNumberGenerator.Create()的实例方法写法不一样。3.4 使用示例字符串、文件、AAD场景字符串加解密最简单直接调用封装好的两个方法var helper new AesGcmHelper(Convert.FromBase64String(your-base64-32-byte-key)); string payload helper.EncryptToBase64(你好上位机); string plaintext helper.DecryptFromBase64(payload); Console.WriteLine(plaintext);文件加密也同理读文件的字节数组调用Encrypt把结果写出去。注意文件比较大时别一次性把整个文件读进内存GCM本身的特性决定了你最好把整个文件作为一个整体来加密因为tag是针对全量数据算的。如果文件几个GB一次性ReadAllBytes可能会把内存吃爆那种场景建议分块加密并给每个块单独加nonce或者干脆换成AES-CBC加HMAC的分块方案。小文件和大文件的处理策略完全不一样这个是很多人没注意到的工程细节。AAD的用法更体现GCM的价值。比如上位机给服务端发消息可以把设备ID和消息序号拼成字节数组作为associatedData传进去。这样即使有人把A设备的数据包原封不动重放到B设备解密也会因为AAD不匹配而失败。AAD是明文传输的不要放敏感信息只放需要绑定身份的上下文就够了。4. 从上位机改造看AES-GCM的工程落地4.1 原方案的现场我接手的那台设备上位机通过TCP把采集到的数据上传到服务器原方案是AES-CBC加密密钥写死在代码里加了个MD5校验字段没有nonce概念IV也是固定写死的。这个方案至少有四个问题密钥硬编码、IV复用、没有防篡改、校验可绕过。很多人觉得“只要破解者不知道密钥就安全”但固定IV在CBC模式下的攻击面非常大加上MD5本身就不该承担认证职责整个方案基本等于裸奔。4.2 数据帧设计nonce、密文、tag怎么排改造后的帧格式我定义成[1字节版本][4字节消息长度][payload]其中payload就是上面说过的[nonce 12][ciphertext][tag 16]结构。同时把[版本消息长度]这两个字段作为AAD传入加解密。为什么要这么做因为长度字段如果不做认证中间人可以把长度改大改小让接收端在切分payload时直接越界或者产生错误解读。一旦把头部作为AAD绑定任何一位被篡改tag校验都会失败协议头部就变成了“只读防篡改”字段。4.3 密钥管理和会话密钥密钥管理比加解密本身更容易出问题。我的经验是不要硬编码在源码里。非常不可控编译进exe的字符串很容易被反编译工具翻出来。稍微好一点的做法是把密钥放到环境变量或独立配置文件里设置好文件权限只有运行账户能读。安全要求再高的场景可以用ProtectedData做DPAPI加密或者采用ECDH密钥协商通信双方先交换公钥各自派生出一个临时会话密钥再把这个会话密钥用于AES-GCM。这样即使某一次会话密钥泄露也不会影响历史数据还能天然避免“一个密钥用一辈子”的问题。用.NET实现ECDH其实不难核心就是ECDiffieHellman.Create(ECCurve.NamedCurves.nistP256)双方交换公钥后调用DeriveKeyMaterial得到会话密钥。这部分代码不难但要注意公钥交换时的编码格式最好统一用Base64字符串。4.4 与其他语言互操作的注意点GCM最大的优点是标准化做得好C#和Java、Go、Python、C之间互操作基本没有障碍前提是参数对齐。Java那边用Cipher.getInstance(AES/GCM/NoPadding)默认tag就是16字节nonce默认12字节跟C#对得上。Go那边用cipher.NewGCM(block)默认也是12字节nonce、16字节tag。Python的cryptography库的AESGCM接口需要自己传nonce长度也是12字节。最容易翻车的不是tag长度而是“密文和tag的拼接顺序”。很多语言的库把tag直接拼在密文后面C#内置AesGcm是分开输出所以C#这边加密后要手动把tag拼到密文尾部解密时也要记得先把尾部16字节拆出来当tag别把整个payload一股脑丢给Decrypt。如果对接的是C的Crypto库它的GCM模式下密文输出默认也是带tag的拼接顺序是“密文tag”跟上面说的一致。把这些约定写进接口文档里会省掉大量扯皮时间。5. 踩坑记录这五个问题我排查了很久5.1 Tag长度的“15字节陷阱”AES-GCM的tag可以选12到16字节但我不建议为了省两个字节改小。踩坑的地方在于如果你加密时用了16字节tag解密时却用12字节tag去构造AesGcm会把前12字节当作tag去校验结果必然失败。反过来也一样。如果同一个系统里有多个调用方有人传16字节tag的数据有人传12字节tag的数据你就会看到时好时坏、完全没规律的解密失败。解决办法就是项目里统一固定tag为16字节并且在数据帧的版本字段里预留一个标志位万一以后要扩展tag长度不至于全链路炸掉。5.2 nonce复用比密钥泄露更可怕GCM有一个众所周知的禁忌同一个密钥下nonce绝对不能复用。一旦两组明文使用了同一个nonce和同一个密钥攻击者把两个密文异或就能推导出明文的XOR配合已知明文真实内容直接就暴露了。所以不要用时间戳做nonce不要用自增数字裸奔更不要图省事写个固定nonce。推荐做法有两种其一每条消息用RandomNumberGenerator.GetBytes(12)生成随机nonce12字节随机数在单密钥加密量不夸张时碰撞概率可以接受其二每个会话生成唯一密钥消息序号从0开始递增作为nonce序号塞不满12字节就在前面补0。第二种更可控但要注意程序重启后序号必须重新从0开始同时会话密钥也要重新协商。5.3 多线程复用AesGcm会翻车AesGcm实例本身不是线程安全的。多个线程同时调用同一个实例的Encrypt或Decrypt轻则结果错乱重则直接抛异常。我在高并发服务里就遇到过明明密钥和参数都对偶尔就是解密报错最后定位到是多个请求线程共用了同一个AesGcm对象。解决办法有几种最简单的每次调用都new AesGcm(key)这个类很轻量普通吞吐下性能损失可忽略追求极致性能的话用ThreadLocalAesGcm或者自己搞对象池。但千万别图省事加一把大锁把所有加解密串行化那等于把并发能力扔掉了。5.4 UI线程直接加解密导致卡顿这个坑在C#上位机里特别典型。很多人的项目里有一个高频数据采集循环每采一组数据就同步调用一次加密加密结果直接更新到UI控件上。单看一次加密几十KB的数据在普通PC上只有几十微秒但采集频率一高加上UI线程本身还要处理绘图、刷新、事件连起来卡顿就明显了。我见过最夸张的情况是上位机每秒采集上百次数据每次都在UI线程里做几百毫秒的文件加密界面直接假死。建议把加解密丢到后台线程或者Task.Run里UI线程只负责展示结果。这个道理不仅仅适用于加密任何涉及IO和CPU密集操作的通通不要放在UI线程里跑。5.5 AAD看起来没用实际上非常关键很多人刚接触GCM时会忽略AAD觉得“我又不想公开任何额外信息AAD没用”。实战下来AAD是协议防篡改的利器。举一个真实场景上位机给服务端发指令指令本身加密了但指令里带有“设备编号”和“时间戳”如果这两个字段只是明文放在头部中间人可以把你的指令改成发给另一台设备或者把旧指令重放一遍。把设备编号和时间戳作为AAD传入之后服务端解密时用当前请求里的头部字段重新计算AAD只要头被改解密直接失败。AAD不是用来加密的它是用来建立“上下文绑定”的能防重放、防错乱、防跨设备伪装。我自己在实际项目中习惯在测试工程里固定一个互操作用例固定密钥、固定nonce、固定明文和AAD期望输出一个固定的Base64密文。每次改了代码或者Java/Go/C端对接时跑一遍这个用例就能确认两边的参数完全一致。这个习惯让我躲过了好几次“算法没问题、参数没对齐”的隐形事故算是GCM落地过程中最值得保留的一个测试手段。
