对称密钥与非对称密钥：原理、使用场景及优缺点
聊到加密，最核心的两个概念就是对称密钥和非对称密钥。说白了，它们解决的都是同一个问题——怎么让信息在别人眼皮底下安全地传递。但解决问题的思路，完全是两码事。
我刚开始接触KMS的时候，也搞混过。后来在一个项目中吃过亏，才真正把这两个家伙的区别刻在脑子里。今天我们就来把它们拆开，讲明白。
一、对称密钥：一把钥匙开一把锁
对称密钥的原理很简单：加密和解密用同一把密钥。就像你家大门，用一把钥匙锁上，再用同一把钥匙打开。
发送方用密钥K对明文加密，得到密文。接收方拿到密文后，用同样的密钥K解密，还原出明文。整个过程，密钥K是唯一的秘密。
1. 优点与缺点
对称密钥最大的优点是快。非常快。在加密大量数据时，它的性能甩非对称加密几条街。你想想看，一个视频文件几GB，如果都用非对称加密，服务器早就卡死了。
但缺点也明显：密钥分发是个大麻烦。
- 密钥分发问题：加密方和解密方必须同时持有相同的密钥。怎么把这个密钥安全地传给对方？如果你已经有安全通道，那还加密干嘛？这成了先有鸡还是先有蛋的问题。
- 密钥管理复杂：假设有n个人需要互相通信，每个人都要跟其他人共享一个不同的密钥。总共需要n*(n-1)/2个密钥。100个人的团队，需要4950个密钥。管理起来简直是灾难。
- 无法提供不可否认性：因为密钥是共享的，你无法证明某条消息一定是对方发的。对方也可以说“你也有我的密钥，可能是你自己伪造的”。
我在项目中的教训
我曾经接手过一个内部文档加密系统，项目初期用了对称加密。密钥直接硬编码在配置文件中。结果有一次服务器被拖库，所有加密文档等同于明文。后来我们把密钥管理接到了KMS上，用密钥轮换和访问控制才把坑填上。
2. 常见算法与参数对比
| 算法 | 密钥长度(位) | 分组大小(位) | 安全性 | 典型应用 |
|---|---|---|---|---|
| AES | 128 / 192 / 256 | 128 | 高（当前标准） | 文件加密、VPN、磁盘加密 |
| SM4 | 128 | 128 | 高（国密标准） | 国内合规场景、金融数据 |
| DES | 56 | 64 | 低（已被破解） | 历史遗留系统 |
| 3DES | 112 / 168 | 64 | 中（逐步淘汰） | 旧支付系统迁移中 |
我曾经见过有同学为了省性能，把AES的密钥长度从256降到128。说真的，在绝大多数场景下，128位已经足够安全，不需要为了“更安全”盲目追求256位。但千万别为了那点计算量去用DES，那是给自己挖坑。另外，不要用ECB模式，用CBC或GCM。
二、非对称密钥：公钥加密，私钥解密
非对称密钥的思路就巧妙多了。它使用一对密钥：一个公钥，一个私钥。公钥可以公开给任何人，私钥必须自己保管好，不能泄露。
加密时，用对方的公钥加密。解密时，只有对方用自己的私钥才能解开。这就解决了密钥分发的问题。你想想看，任何人都可以用你的公钥给你发加密消息，但只有你能用私钥读。
1. 优点与缺点
最大的优点是解决了密钥分发难题。公钥随便发，私钥自己留着。n个人通信，只需要n对密钥，管理复杂度直线下降。
另一个优势是提供不可否认性。用私钥签名，公钥验证，这就跟手写签名一样，抵赖不了。
但非对称加密的缺点也致命：慢。非常慢。一般来说比对称加密慢1000倍甚至更多。如果拿它去加密大文件，基本不现实。
- 性能瓶颈：非对称加密适合小数据量，比如加密一个对称密钥（128位或256位）。
- 密钥长度较长：RSA 2048位的密钥已经算短的了。相比AES 128位，长得多。
- 对随机数质量要求高：生成密钥对时，如果随机数源不够随机，私钥就有被猜出来的风险。
2. 常见算法对比
| 算法 | 密钥长度(位) | 安全强度 | 典型应用 |
|---|---|---|---|
| RSA | 2048 / 4096 | 高（广泛使用） | 数字签名、密钥交换、证书 |
| ECC（椭圆曲线） | 256（相当于RSA 3072） | 高（更高效） | 移动端、IoT、区块链 |
| SM2 | 256 | 高（国密标准） | 国内合规场景、电子政务 |
| DSA | 1024 / 2048 | 中（仅用于签名） | 历史协议，已被ECC取代 |
我个人的选择习惯
如果在KMS里新建密钥，我通常会选ECC P-256或者SM2。为什么？同样的安全强度，ECC密钥更短，计算更快。RSA 2048位虽然很稳，但性能开销肉眼可见，特别是在TLS握手场景下。除非是对老系统做兼容，否则我一般不主动推荐RSA。
三、混合加密系统：各取所长
既然对称加密快但密钥分发难，非对称加密解决了分发问题但很慢。那为什么不用非对称加密来传递对称密钥，再用对称密钥来加密实际数据呢？这就是混合加密系统的思路。
举个例子，HTTPS的TLS握手就是典型的混合加密：
- 客户端发起请求：告知服务器支持的加密套件。
- 服务器返回证书：证书里包含服务器的公钥。
- 客户端验证证书：确认服务器身份无误。
- 生成临时对称密钥：客户端随机生成一个会话密钥（比如AES 256位）。
- 用公钥加密会话密钥：客户端用服务器的公钥加密这个临时密钥。
- 服务器解密：服务器用私钥解密，拿到会话密钥。
- 对称加密通信：后续所有数据传输都用这个对称密钥进行加密。
这样，既用非对称加密解决了密钥分发的难题，又用对称加密保证了数据传输的性能。
核心结论
在实际的KMS集成方案中，你几乎不会只用一种加密方式。都是混合着用。KMS管理的是你最重要的根密钥，通常是非对称密钥对（用于签名和密钥协商），或者是对称主密钥（用于派生或包装其他密钥）。而业务数据加密，推荐走对称加密，密钥由KMS下发或派生。
混合加密中的临时对称密钥，必须是一次性的。每次会话结束都应丢弃。我曾经遇到过有项目把这个临时密钥缓存下来重复使用，结果会话重放攻击直接打穿。记住，会话密钥的生命周期只等于一次网络连接。
四、实际集成建议
在KMS集成方案里，我总结了几条简单的原则：
- 数据加密首选对称：所有业务数据的加密，就是用AES-256-GCM或者SM4-GCM。KMS负责生成和管理这些对称密钥。
- 密钥传输用非对称：当不同系统之间需要交换对称密钥时，使用非对称加密包装（RSA或SM2）。KMS里的密钥对就是干这个的。
- 身份认证与签名用非对称：JWT签名、代码签名、数字证书。这些场景下公钥可以公开验证，私钥由KMS严格保护。
- 密钥派生尽力而为：如果需要大量派生密钥，用一个主对称密钥搭配HKDF算法。不要每个业务都去生成独立密钥，那是浪费KMS性能和你的时间。
说到底，没有哪种加密方式是万能的。对称和非对称各有各的战场。理解它们背后的原理，知道它们各自的痛点和优势，你就能在做架构设计时，做出更稳妥的选择。