2.1 对称密钥加密

2.1 对称密钥加密

本节摘要：SOURCE 2.1：对称加密用同一密钥加解密，AES 为当前标准；TLS 记录层 bulk 加密依赖协商出的对称密钥。

故障场景：AES-GCM nonce 重用

开发者硬编码 IV，两次 GCM 加密重用 nonce，攻击者可恢复明文。AES-GCM 要求每个密钥下 nonce 唯一——TLS 1.3 在记录层规范 nonce 构造。

一、AES 要点（SOURCE 2.1）

二、与 TLS 的关系

握手阶段用 ECDHE 等协商 premaster/master secret，推导 traffic keys，之后 Application Data 全用 AES-128-GCM 等对称算法加密。

# 本地验证 AES（OpenSSL 命令行示例）
openssl enc -aes-256-gcm -salt -pbkdf2 -in plain.txt -out cipher.bin
​

⚠️ 常见坑：新系统仍选 AES128-SHA（CBC+MAC）而非 AEAD 套件。

💡 关键直觉：对称加密解决「快」；密钥从哪来交给握手与非对称算法。

重点提炼

• AES 是 TLS bulk 加密主力
• GCM 同时提供机密性与完整性
• 密钥必须保密且定期轮换（会话密钥）

深入讨论：AES 模式选择背后的安全考量

AES 本身只是一个分组密码原语，真正决定安全性的是使用模式。ECB 模式对相同明文产生相同密文，会泄漏结构信息，任何现代协议都不会使用；CBC 模式需要随机 IV，且对密文篡改缺乏内建检测，TLS 1.2 中它要配合 HMAC 使用，历史上 BEAST、Lucky13 等攻击都瞄准了这条链路；GCM 模式同时提供加密与认证，是 AEAD 的代表，TLS 1.3 默认使用。选模式就是选「加密、完整性与实现的权衡」。

nonce 管理是 GCM 最容易出错的地方。GCM 要求同一密钥下 nonce 唯一，nonce 重用会让密钥流重复，攻击者可以恢复出两个明文的异或，进而逐步还原明文。TLS 1.3 通过「密钥 + 序列号」构造 nonce，从协议层面保证了唯一性；但在应用层自己调用 GCM 时，开发者必须自己负起 nonce 管理的责任，硬编码 IV 是实际事故中最高频的错误之一。

# AES 模式速查与适用场景
模式      认证      使用要求                      典型场景
ECB      无        明文长度限制、泄漏结构          仅教学，禁用
CBC      MAC 配合  随机 IV、填充处理              TLS 1.2 遗留
GCM      AEAD      每个密钥下 nonce 唯一          TLS 1.3、VPN
CCM      AEAD      nonce 与长度关联               Wi-Fi WPA3
XTS      无（磁道） 扇区编号做 tweak               磁盘加密
​

对照这张表可以形成一条选型直觉：凡是网络传输场景，优先 AEAD（GCM/CCM）；凡是无认证需求的存储场景，考虑 XTS。同时记住一个红线——任何模式下，密钥都不能硬编码，IV/nonce 都不能重用。这两个红线是大量真实漏洞的共同根源，也是本节故障场景想要传达的核心。

附录速查：AES 模式、IV 规则与 OpenSSL 验证命令

# AES 常用模式速查
模式        认证方式    IV/nonce 要求             典型用途
ECB        无          不需要（不安全）           禁用
CBC        MAC 配合    随机且不可预测 IV          TLS 1.2 遗留
CFB/OFB    无          唯一且不可预测 IV          流式场景（少见）
CTR        无          唯一计数器                作为 GCM 内核
GCM        AEAD       nonce 唯一 + 校验标签       TLS 1.3、VPN
CCM        AEAD       nonce 唯一，长度受限        Wi-Fi WPA3
XTS        无          每扇区唯一 tweak           磁盘卷加密

# nonce/IV 硬编码的典型危害
同一密钥 + 同一 nonce 两次 GCM 加密
  -> 两个明文异或 = 两个密文异或，可恢复明文
同一密钥 + 顺序递增 nonce 且无防回放
  -> 攻击者可重放旧密文

# OpenSSL 本地验证命令
openssl enc -aes-256-gcm -pbkdf2 -salt -in plain.txt -out cipher.bin
  # GCM 模式加密，标签自动追加
openssl enc -aes-256-cbc -pbkdf2 -salt -in plain.txt -out cipher_cbc.bin
  # CBC 模式加密（对比用）
openssl dgst -sha256 plain.txt
  # 计算 SHA-256 摘要用于完整性参考

# 工程红线清单
1. 密钥不得硬编码、不得写入版本库
2. nonce/IV 生成必须用 CSPRNG 或受控计数器
3. 同一密钥生命周期内 nonce 绝对唯一
4. 网络传输一律 AEAD，禁止裸 CBC
5. 密钥按用途分离：加密密钥 / MAC 密钥 / 派生密钥分开
​

命令与红线清单可直接放进团队规范。对称加密的坑集中在「模式选错」与「nonce 管理失败」两处，这两条在真实事故中占比最高，提前形成规范能挡掉大部分回归问题。

再补充一个运维视角的细节：对称加密的性能会直接影响协议吞吐，AES-NI 指令可以把 AES 加密加速到远超软件实现的速度，这也是为什么现代 TLS 在移动端与服务器端都默认走 AES-GCM。当遇到「带宽没满但加解密成瓶颈」的现象时，优先检查是否用了非硬件加速的算法或模式，再考虑升级硬件。理解「算法性能受指令集影响」这一层，能避免把加密瓶颈误判成网络问题。

同时要注意，性能优化不能以牺牲安全为代价：不要在能支持 AEAD 的环境里为了省 CPU 退回 CBC 或 RC4。先保证模式与密钥管理的正确性，再谈性能调优，这条顺序在任何加密工程里都适用。