密钥边界：对称与非对称的博弈
这一章，咱们聊聊密钥类型的选择。说白了，就是搞清楚什么时候该用对称密钥，什么时候该用非对称密钥。我刚入行那会儿，总觉得非对称密钥更高级，什么场景都想用RSA——结果性能扛不住，还闹了好几次签名验证失败的笑话。后来才明白，每种密钥都有它最对味儿的战场。
对称加密：一把钥匙开一把锁
对称加密，顾名思义，加密和解密用的是同一把密钥。就像你家大门，进出门都用同一把钥匙。客户端和服务端得事先商量好这把钥匙，然后才能悄悄通信。
工作原理
加密过程很简单：
- 明文 + 密钥 → 加密算法 → 密文
- 密文 + 密钥 → 解密算法 → 明文
常见算法有AES（高级加密标准）、DES（已被淘汰）、SM4（国密）。我个人习惯用AES-256，安全性足够，性能也均衡。
核心要点：安全性完全依赖密钥的保密性。一旦密钥泄露，密文就裸奔了。
避坑指南：我曾经在项目中用AES-ECB模式，结果密文被统计分析出规律，差点被攻击者还原出原始图片。记住：永远不要用ECB模式，至少用CBC或GCM。
优势与劣势
| 方面 | 说明 |
|---|---|
| 性能 | 非常快，尤其适合大数据量加密（比如文件、视频流） |
| 密钥管理 | 致命短板——密钥分发困难。n个参与者两两通信需要n*(n-1)/2个密钥 |
| 使用场景 | TLS传输层加密、数据库透明加密、磁盘加密 |
非对称加密：公钥挂墙上，私钥藏兜里
非对称加密使用一对密钥：公钥和私钥。公钥可以公开，谁都能拿；私钥只有自己持有。它的核心价值在于：用公钥加密的数据，只有对应的私钥能解开；反过来，用私钥签名的数据，能用公钥验证身份。
工作原理
拿RSA举例：
- 选两个大质数p和q，计算n = p * q
- 计算欧拉函数 φ(n) = (p-1)*(q-1)
- 选一个与φ(n)互质的整数e作为公钥指数
- 计算私钥指数d，满足 e*d ≡ 1 (mod φ(n))
加密时：密文 = 明文^e mod n；解密时：明文 = 密文^d mod n。当然，实际实现还要考虑填充方案（OAEP等）。
注意：非对称加密的密钥长度（比如RSA-2048）远大于对称密钥（AES-256），但安全性级别却不一定更高。2048位RSA只能提供约112位对称安全强度。
常用算法对比
| 算法 | 密钥长度 | 安全强度（对称当量） | 性能 |
|---|---|---|---|
| RSA | 2048位 | ~112位 | 慢（指数运算） |
| ECC（椭圆曲线） | 256位 | ~128位 | 快（相同安全强度下密钥更短） |
| SM2（国密） | 256位 | ~128位 | 与ECC接近 |
如何选择密钥类型？
这里有个很实用的判断逻辑：先看业务，再看性能，最后看合规。
- 数据加解密：首选对称加密。比如你在云上存储用户文件，用AES-256加密即可，性能好，管理简单。
- 密钥分发：必须用非对称加密。比如TLS握手阶段，客户端用服务器公钥加密一个随机生成的对称密钥，只有服务器能用私钥解开，这样就安全地交换了会话密钥。
- 数字签名：只能用非对称加密（私钥签名，公钥验签）。比如代码签名、身份认证。
- 混合加密：实际推荐方案。想想你在HTTPS里是怎么工作的？客户端生成对称密钥，用服务器公钥加密它，然后用对称密钥加密后续数据。既解决了密钥分发问题，又获得了对称加密的高性能。
我建议：除非你明确需要非对称提供的签名或密钥交换能力，否则优先使用对称加密加KMS托管密钥。别自己折腾RSA，容易出性能壑沟。
实际选型清单
我把常见场景的密钥类型选择整理成了一张表，方便你直接参考：
| 场景 | 推荐算法 | 密钥类型 | 备注 |
|---|---|---|---|
| 文件/数据库加密 | AES-256-GCM | 对称 | 性能好，支持认证加密 |
| TLS握手 | ECDHE + AES-GCM | 混合 | 非对称交换临时对称密钥 |
| 数字签名 | ECDSA / RSA-PSS | 非对称 | 私钥签名，公钥验签 |
| 身份认证（SSH） | Ed25519 | 非对称 | 密钥短，安全强度高 |
| IoT设备数据加密 | ECC + AES | 混合 | 设备资源受限，用ECC做密钥协商 |
| 国密合规 | SM2 + SM4 | 混合 | SM2非对称，SM4对称 |
我的习惯：如果不是涉密项目，AES-256-GCM + ECDHE（临时密钥交换）基本能覆盖大部分场景。既不用管密钥分发，又能享受对称加密的速度。你想想看，HTTPS就是这条路，全球都在用，准没错。