📚 课程目录第2章对称加密与非对称加密基础

2. 对称加密与非对称加密基础归纳总结

说实话，加密这事，很多人觉得离自己很远。但你在云上存个数据库、调个 API，背后全是这些东西在撑。我以前也觉得「知道个概念就行」，直到有一次客户的数据泄露事件复盘，才发现问题就出在「密钥怎么安全地交给对方」上。嗯，从那以后，我对对称和非对称的理解就不再只是课本上的定义了。

这一章，我们来把这俩基础扎扎实实拎一遍。你先别急着看算法细节，重点是搞懂「它们各自解决什么问题」。

对称加密，说白了就是用同一把钥匙，既锁箱子又开箱子。加密和解密都是同一个密钥。速度快，硬件友好，适合大数据量。

我个人的习惯是，只要不是必须用非对称的场景，优先选对称。为什么？因为 CPU 跑 AES 比跑 RSA 快两三个数量级。在云上，你每毫秒的花费都是钱。

我记得早期有个项目，还在用 3DES 做支付流水加密。审计一来，直接被要求整改。后来我们切到 AES-256-GCM，顺便把 MAC 校验也搞定了。

光选算法还不够，模式更重要。我用过最坑的就是 ECB 模式——同样的明文块加密后一模一样，照片里能看到轮廓。你想想看，这种模式在云上做数据分区加密根本不行。

我曾经在这上面栽过坑：在云对象存储（比如 S3）里用 CBC 加密大文件，解密时忘了 IV 是怎么存的。最后所有数据都得重新上传。建议你把 IV 和密文拼在一起存储，或者用 KMS 的自动派生方案。

非对称加密，也叫公钥加密。一对儿钥匙：公钥公开，私钥自己藏好。公钥加密的数据只有私钥能解开；反过来，私钥签名，公钥验证。

它慢，很慢。RSA-2048 的速度大概是 AES-128 的千分之一。所以你不可能用它加密整个文件。但它的价值在于「不用事先共享密钥」。举个例子，你给对方发一条加密消息，不需要像对称加密那样先把密钥传过去——公钥是公开的。

算法	典型密钥长度	用途	我的评价
RSA	2048 / 4096 位	加密、签名	最成熟，但密钥大，签名慢
ECC (ECDH, ECDSA)	256 位（等效 RSA-3072）	密钥交换、签名	小钥匙高安全，云上首选
SM2	256 位	加密、签名、密钥交换	国密，与 ECC 类似
DSA / EdDSA	2048+ / 256 位	仅签名	EdDSA 更现代，性能好

为什么云上越来越倾向 ECC？你想想，一个证书里 RSA-2048 的公钥占 256 字节，而 ECC P-256 只有 32 字节。握手速度、存储成本都差很多。AWS 的 KMS 现在默认就用 ECC 做密钥交换。

说白了，没有谁好。我常用的策略是：用对称加密保护数据，用非对称加密保护对称密钥。这就是下一章要讲的信封加密。

下面这张图把对称与非对称的定位、关系以及常见算法串起来了，你可以先当个索引用。

我做了这么多年云安全，总结了几条核心原则，你可以直接抄作业：

永远别自己发明加密协议。哪怕你觉得自己懂 AES、懂 RSA，组合在一起就可能出现中间人攻击。用现成的 TLS、JWT、AWS KMS 或者阿里云 KMS。
非对称加密不适合加密大数据。记得有一次，有同事直接用 RSA 加密一个 10MB 的文件，结果一次加密要 3 秒，而且密钥长度不够还爆出异常。后来改成信封加密，速度直接提升 50 倍。
对称密钥的分发要用非对称来保护。这是最经典的组合，也是本课程接下来要讲的信封加密的核心。
国密算法并非必须，但如果合规要求，就提前支持。我在政务云项目里吃过亏——开发到一半才被告知必须用 SM4+SM2，结果重构了很久。建议架构设计时就预留算法切换接口。

一个小技巧：在云上做密钥轮换时，对称加密的密钥可以通过 KMS 自动生成主密钥（CMK），然后你用数据密钥（DEK）去实际加密。轮换时只更新 DEK，CMK 可以长期不变。这样既安全又省管理成本。

对称加密快，但密钥分发是死穴。非对称加密解决了信任问题，但慢得让你肉疼。两者不是竞争关系，而是完美搭档。你在云上做数据保护时，脑子里一定要有「分层」的概念：数据用对称，对称密钥用非对称。

下一阶段，我们会把这两个家伙如何结婚讲清楚——信封加密。