4. 密码套件：对称/非对称加密、哈希算法、AEAD
说到密码套件，我经常会想起刚入行时的一个场景——那时候配置TLS，看到一串像 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这样的名字，真的是一头雾水。后来踩过几个坑才明白，这串字符其实就是整个握手过程中所有密码操作的“菜单”。
一个密码套件，说白了就是四个核心元件的组合：
- 密钥交换算法（用于安全地协商对称密钥）
- 身份认证算法（验证对方身份，通常是非对称算法）
- 对称加密算法与模式（加密实际数据）
- 哈希算法或MAC（保证完整性）
它们缺一不可。我个人的习惯是，在优化HSM性能时，首先盯的就是密码套件——因为HSM里面跑的最重的运算，全都在这些算法里。
4.1 非对称加密：握手中最重的活儿
非对称加密在TLS握手阶段主要干两件事：
- 身份认证——通过证书和签名验证服务器（或客户端）的身份
- 密钥交换——在建立共享对称密钥的过程中，保护秘密信息不被窃听
| 算法 | 特点 | HSM负载 |
|---|---|---|
| RSA（2048/4096位） | 广泛兼容，但私钥操作很重 | 签名/解密均为高负载 |
| ECDSA（P-256/384） | 签名速度快，密钥小 | 签名相对轻，验签更快 |
| Ed25519 | 现代椭圆曲线，更快更安全 | 运算量极低，适合高性能HSM |
| DHE（传统大质数群） | 前向安全性强，但计算量大 | 尤其服务器端运算重 |
| ECDHE | 椭圆曲线+临时密钥，前向安全 | 计算量远低于DHE |
我记得有一次客户抱怨HSM扛不住握手量，每秒只能处理几百次。我让他把RSA证书签名换成了ECDSA P-256，再把密钥交换从DHE改为ECDHE，结果HSM吞吐量直接翻了5倍。你想想看，一个选择就能省下好几个硬件升级的钱。
4.2 对称加密与AEAD：加密数据的主力
握手协商完密钥之后，真正的数据流加密用的是对称算法。这里面有几个关键点：
- AES——硬件加速支持最好，HSM大多有专门的AES引擎
- ChaCha20——没有AES硬件加速时反而更快，适合手机或边缘设备
- AEAD模式（GCM/ChaCha20-Poly1305）——加密同时验证完整性，一步到位
重点推荐：在TLS 1.3里，AEAD已经不是可选项，而是强制要求。老旧的CBC模式 + HMAC组合已经被淘汰。配置HSM时，优先选择带AEAD的密码套件，能省掉一次HMAC计算。
4.2.1 GCM vs CCM vs ChaCha20-Poly1305
| AEAD方案 | 加密核 | 典型场景 | HSM注意事项 |
|---|---|---|---|
| AES-128-GCM | AES-128 | TLS 1.2/1.3 主流 | 需要随机nonce，HSM需支持bulk加密 |
| AES-256-GCM | AES-256 | 高安全等级场景 | 计算量比128约大40% |
| AES-128-CCM | AES-128 | 物联网、资源受限环境 | 每个包需额外计算 |
| ChaCha20-Poly1305 | ChaCha20 | 移动端、无AES加速 | HSM若不支持，需软实现 |
我在调优一个金融系统的HSM时，发现它的AES-GCM引擎在并发多线程下性能下降严重。原因是不支持并行nonce生成。后来切到ChaCha20-Poly1305后，吞吐量稳定了——当然前提是HSM内置了ChaCha20硬件模块。
4.3 哈希与HMAC：完整性保证
哈希算法在TLS握手里到处出现——签名、密钥派生、Finished消息校验。现代TLS密码套件主要用：
- SHA-256——默认、安全、性能均衡
- SHA-384——更强的安全，但64位CPU上有额外开销
- SHA-1——已经禁用，别再用了
注意：在HSM性能优化时，SHA-256的哈希运算通常不是瓶颈——哈希本来就很快。但要注意，密钥派生（如HKDF）会反复调用哈希，一下子拉高HSM的占用。我曾经遇到过因为PRF里哈希被调用过多次，导致HSM负载飙升的案例。
4.4 密码套件与HSM性能的关联
为了让你更直观地理解，我从一个真实项目中抽取了一组对比数据：
| 密码套件 | 握手耗时（HSM端） | HSM CPU占用 | 备注 |
|---|---|---|---|
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | 2.3ms | 65% | RSA签名较重 |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 1.1ms | 28% | ECDSA更轻 |
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | 0.9ms | 20% | ChaCha20无AES开销 |
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA | 15.4ms | 95% | 过时套件，CBC+HMAC |
看到差距了吗？一个套件选错，HSM就像被压了块大石头。
4.5 如何选择密码套件来优化HSM性能
- 优先使用ECDHE进行密钥交换——计算量小，支持前向安全。避免DHE。
- 选择ECDSA代替RSA证书签名——只要客户端兼容性允许，果断上ECDSA。
- 对称加密锁定AEAD模式——AES-128-GCM或ChaCha20-Poly1305。
- 哈希用SHA-256——别超配到SHA-384，除非客户要求。
- 在TLS 1.3下，只用AEAD套件——TLS 1.3已经简化了密码套件列表，推荐你直接采纳。
避坑指南：我曾经为了兼容老设备，保留了RSA和CBC套件。结果HSM在混合负载下频繁超时。后来硬起心肠关了所有非AEAD套件，性能瞬间稳定了。兼容性和性能之间，很多时候得做取舍——我个人建议，如果你的HSM承受着高并发，直接砍掉历史包袱。
最后，我画了一张整个密码套件在TLS握手中的作用图，方便你对照：
理解了这张图，你就能清楚每个密码套件在HSM上消耗在哪里。下一步，我们可以针对具体的密码套件组合做基准测试——不过那就是后面要聊的内容了。