2、密码学基础（上）：对称加密算法（AES、SM4）的原理与工作模式（ECB、CBC、GCM），在票务数据加密中的应用场景
好，咱们进入正题。密码学这东西，听起来高大上，其实说白了就是两件事：藏起来和验真身。今天聊的对称加密，就是「藏起来」最经典的手段。
我刚开始做票务系统那会儿，对加密的理解就是「把数据搞乱」。后来踩过坑才明白，选错算法、用错模式，比不加密还危险。你想想看，一张地铁票里存着余额、进出站时间、甚至用户ID，要是被中间人篡改或者窃取，那可不是闹着玩的。
2.1 对称加密的核心思想：一把钥匙开一把锁
对称加密，顾名思义，加密和解密用的是同一把密钥。就像你家大门钥匙，锁门用它，开门也用它。
在票务场景里，发卡系统把票务数据（比如余额、有效期）用密钥加密，写入票卡。闸机读取时，再用同一把密钥解密。整个过程，密钥绝对不能泄露。
核心公式：
- 加密：C = E(K, P) —— 用密钥K加密明文P，得到密文C
- 解密：P = D(K, C) —— 用密钥K解密密文C，还原明文P
嗯，这里要注意：密钥管理才是真正的难点。算法本身是公开的，密钥一旦泄露，整个系统就形同虚设。我在项目中见过有人把密钥硬编码在代码里，结果代码被反编译……那画面太美我不敢看。
2.2 两大主流算法：AES 与 SM4
目前票务系统里，最常用的对称加密算法就两个：AES（国际标准）和 SM4（国密标准）。
| 特性 | AES | SM4 |
|---|---|---|
| 分组长度 | 128 bit | 128 bit |
| 密钥长度 | 128 / 192 / 256 bit | 128 bit |
| 轮数 | 10 / 12 / 14 轮 | 32 轮 |
| 算法结构 | SPN（替换-置换网络） | Feistel 网络（类似 DES） |
| 国内合规性 | 非国密，部分场景受限 | 国密标准，金融/交通强制要求 |
AES 是国际通用的老大哥，性能好、生态成熟。我早期做海外项目时，基本无脑选 AES-256。
SM4 是咱们国家的标准，2012年发布。现在国内轨道交通票务系统，尤其是新线建设，基本强制要求使用 SM4。为什么？合规啊！等保2.0、密评都盯着呢。
我的建议：
如果你做国内项目，直接上 SM4，省得后面被审计追着改。如果是海外项目，AES-256 是稳妥选择。别问我为什么知道——我曾经在一个项目里用了 AES，结果客户要求过国密认证，硬生生把整个加密模块重写了一遍……
2.3 工作模式：ECB、CBC、GCM
算法本身只负责加密一个「数据块」（128 bit）。但实际数据往往很长，比如一张票卡里存了 1KB 的数据。这时候就需要工作模式来决定怎么切分和关联这些数据块。
2.3.1 ECB 模式（电子密码本模式）—— 千万别用！
ECB 是最简单的模式：把数据切成 16 字节一块，每块独立加密。
问题在哪？ 相同的明文块，加密后得到相同的密文块。你想想看，如果一张票卡里余额字段是固定的几个值（比如 0 元、10 元、20 元），攻击者只要收集密文，就能猜出余额对应的密文模式。
避坑指南：
我曾经在一个老旧票务系统里看到过 ECB 模式。结果呢？攻击者通过对比不同票卡的密文，直接伪造了一张高余额的票卡。从那以后，我见到 ECB 就条件反射地摇头。记住：票务数据绝不能用 ECB。
2.3.2 CBC 模式（密码分组链接模式）—— 常用但需注意
CBC 模式解决了 ECB 的问题：每个明文块在加密前，先与前一个密文块做异或运算。这样，即使明文相同，密文也不同。
关键点： 第一个块没有前一个密文，所以需要一个初始向量（IV）。IV 必须随机生成，且每次加密都要不同。
// 伪代码示例：CBC 加密
C0 = E(K, P0 XOR IV)
C1 = E(K, P1 XOR C0)
C2 = E(K, P2 XOR C1)
// ... 以此类推CBC 在票务系统里用得挺多，尤其是静态数据加密，比如后台数据库里存储的票卡密钥。但要注意：CBC 是串行的，不能并行加密，性能上会差一些。
2.3.3 GCM 模式（伽罗瓦/计数器模式）—— 我推荐的首选
GCM 是「加密 + 认证」二合一模式。它不仅能加密数据，还能生成一个认证标签（MAC），用来验证数据有没有被篡改。
为什么我推荐 GCM？因为票务数据最怕两件事：泄露和篡改。
- 泄露：加密解决。
- 篡改：认证标签解决。
GCM 的认证标签是 128 bit 的，攻击者想伪造一个合法的密文，概率是 1/2^128，基本不可能。
GCM 的核心优势：
- 支持并行计算，性能好
- 自带认证，防篡改
- 不需要填充（CBC 需要 PKCS#7 填充）
我在做票卡与闸机之间的在线交易时，一律用 GCM。比如乘客刷卡进站，闸机需要验证票卡里的余额和有效期，同时要确保数据在传输过程中没被改过。GCM 一把梭，省心。
2.4 票务数据加密的应用场景
说了这么多理论，咱们落地到实际场景看看。
| 场景 | 推荐算法 | 推荐模式 | 说明 |
|---|---|---|---|
| 票卡（CPU卡）数据写入 | SM4 | CBC 或 GCM | 卡内数据需防篡改，GCM 更优 |
| 闸机与后台通信 | AES-256 / SM4 | GCM | 在线交易，需认证和加密 |
| 数据库存储密钥 | AES-256 / SM4 | CBC | 静态数据，CBC 足够 |
| 票卡个人化（发卡） | SM4 | GCM | 发卡过程需防伪造 |
一个小技巧：
在票卡个人化阶段，我习惯用 GCM 模式，并且把认证标签也写入卡内。这样每次交易时，闸机可以同时验证「数据对不对」和「数据是谁发的」。相当于给票卡加了个数字签名，虽然简单，但非常有效。
2.5 小结与避坑
对称加密是票务安全的基石。选对算法、用对模式，能挡住 90% 的常见攻击。
- 算法选择：国内用 SM4，海外用 AES-256。
- 模式选择：别碰 ECB，CBC 用于静态数据，GCM 用于在线交易。
- 密钥管理：密钥不能硬编码，不能明文传输，建议用 HSM（硬件安全模块）或 KMS（密钥管理系统）。
我曾经见过一个项目，密钥直接写在配置文件里，还上传到了 Git 仓库……嗯，那哥们后来被安全审计约谈了。你想想看，算法再强，密钥泄露了，一切归零。
下一节，咱们聊非对称加密和数字签名，那又是另一番天地了。