对称加密与非对称加密：算法对比、优缺点
对称加密：又快又稳，但密钥怎么传？
对称加密，说白了就是加密和解密用同一把钥匙。早期我做嵌入式系统时，就直接拿DES加密串口通信数据。那时候还没意识到56位密钥有多脆弱，后来换了AES才踏实。
常见的对称加密算法就这几个：
- DES：56位密钥，现在基本当反面教材。我考察过一些老旧设备的协议，居然还在用DES，这基本等于没锁门。
- 3DES：拿DES套了三层。安全是上去了，但性能掉得厉害。我记得有次压测，3DES的吞吐量直接比AES低了好几倍，果断放弃了。
- AES：128、192、256位可选，硬件加速普遍支持。我个人习惯对称加密首选AES-256，除非项目有特殊的兼容性限制。
对称加密的核心优势：速度快、实现简单、适合加密海量数据。问题是，通信双方怎么安全地共享这把钥匙？你想想看，如果密钥在传输过程中被别人截获，那加密就形同虚设。
非对称加密：密钥管理省心，但死穴在性能
非对称加密用一对钥匙——公钥加密、私钥解密。公钥可以满大街发，私钥自己偷偷藏好。这个思路在密钥分发环节确实优雅。
主流算法有这些：
- RSA：基于大整数因数分解难题，密钥长度通常2048位起。最早我在做CA系统时对接过RSA，算法成熟度高，但加解密速度很慢。
- ECC：基于椭圆曲线离散对数难题，256位ECC就能达到与3072位RSA相当的安全级别。密钥短、速度快、非常香。我现在做移动端密钥管理，基本首选ECC。
- DSA：专用于数字签名，不能加密。早期政府部门项目里见到过，现在逐步被ECC和RSA签名替代。
踩坑警告：我曾经直接用RSA加密一个几兆的文件，结果接口直接超时——为什么？RSA每次加密的数据块不能超过密钥长度（比如2048位只能加密245字节左右）。大文件必须分段，但性能灾难会让你怀疑人生。记住，非对称加密只适合加密少量数据，比如对称密钥、数字摘要、证书签名等。
对称 vs 非对称：核心对比
| 维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 双方共享同一密钥 | 公钥+私钥，成对出现 |
| 密钥分发 | 难，需要安全通道 | 容易，公钥可公开 |
| 加密性能 | 快（硬件加速常见，AES-256可达GB级） | 慢（RSA-2048每秒仅几千次操作） |
| 算法复杂度 | 低，资源开销小 | 高，占用CPU更高 |
| 典型应用 | 数据加密、文件加密、磁盘加密 | 密钥交换、数字签名、身份认证 |
| 安全性 | 高（密钥保护好时） | 高（基于数学难题，但量子计算威胁大） |
实战中的混合加密：取长补短
一个项目里到底用对称还是非对称？我见过的真实系统几乎无一例外都在用混合加密。原理很简单：
- 用非对称加密（如RSA或ECC）安全传输一个临时对称密钥
- 双方拿到这个对称密钥后，再用AES等对称算法加密后续所有数据
这样既解决了密钥分发难题，又享受了对称加密的高性能。
我的习惯：在设计API接口认证时，我会用ECC P-256生成密钥对，然后客户端用公钥加密一个随机AES-256密钥发给服务器，服务器解密后用这个AES密钥加密后续请求的body数据。服务器返回时也会用新的随机AES密钥。这样的会话级密钥即使被截获，也不会影响其他会话。
选型决策：别只看算法本身
最终选哪种，光看技术指标不够。我整理了几点实战中容易忽略的：
- 性能需求：如果每秒需要加密上万个请求，用RSA直接撑死，必须上AES+临时密钥
- 密钥存储：对称密钥怎么存？如果放在客户端硬编码里，算法再强也没用。非对称方案里私钥可以放在HSM（硬件安全模块）或密钥托管服务里
- 算法淘汰速度：RSA和ECC短期内不会有问题，但DES和3DES已被IETF标记为不安全。我建议新项目至少支持AES-256、ECC P-256、RSA-2048
- 量子威胁：别忽视。RSA在量子计算机面前基本崩溃。如果做五年以上的系统，建议逐步了解格子加密、超奇异同源等后量子密码方案
踩坑提醒：我见过一个团队在IoT设备上用了RSA-4096，结果密钥生成耗时十几秒，设备直接死机。低算力场景下，ECC明显更实用。千万别迷信“密钥越长越好”，要结合实际硬件算力评估。