密码学基础：对称加密与非对称加密

好，咱们直接开干。BYOK 后面所有的坑，其实都踩在加密算法上。你想想看，你要把自己的密钥交给云端的 KMS，那这个密钥在传输过程中怎么保护？到了 KMS 里怎么安全地存？这些问题的答案，全藏在「对称加密」和「非对称加密」这两个基础概念里。

我个人习惯，每次开始讲新项目前，先带着组里同学捋一遍这两者的区别。原因很简单——选错算法，后面的架构全得重来。我记得有一次线上事故，就是因为团队用了对称密钥去加密一个需要多人协作管理的配置项，结果密钥分发搞得一塌糊涂，回滚都回滚不了。嗯，从那以后我要求所有人必须先画清楚「谁加密、谁解密、密钥在哪」这张图。

对称加密：一把钥匙开一把锁

对称加密，说白了就是加密和解密用同一个密钥。发信人用密钥把明文变成密文，收信人拿到同样这把密钥，把密文变回明文。

它的核心优势是什么？快。非常快。硬件加速做得好，吞吐量能跑到几十 Gbps。你在生产环境里做大量数据传输加密，比如 HTTPS 里的数据部分、数据库 TDE、磁盘加密，清一色都是对称加密。

常见的对称算法有：

• AES（Advanced Encryption Standard）—— 目前全世界最通用的对称分组密码，密钥长度 128/192/256 位。我项目里绝大多数场景都选 AES-256-GCM，既能加密又能做完整性校验。
• SM4 —— 国密标准里的对称分组密码，分组 128 位，密钥 128 位。国内政企项目必须支持。
• ChaCha20 —— 面向软件优化，没有硬件加速的老旧设备上表现比 AES 好。移动端场景我偶尔见到。

那它的问题在哪？密钥分发。你想想看，通信双方怎么安全地拿到同一个密钥？如果通过不安全的网络直接传密钥，那谁拦截了谁就能解密。这就是「密钥配送问题」——对称加密自己解决不了自己的密钥分发。

非对称加密：公钥加密，私钥解密

非对称加密的出现，就是为了解决上面那个配送问题。它使用一对密钥：公钥（公开给所有人）和私钥（只有自己知道）。用公钥加密的数据，只能用对应的私钥解密。反过来，用私钥签名的数据，可以用公钥验签。

你可以把公钥想象成一把锁，私钥就是唯一能打开这把锁的钥匙。锁可以随便发，钥匙必须自己看管好。

常见非对称算法：

• RSA —— 基于大整数分解难题。密钥长度至少 2048 位，2048 位以下已经不安全。加密速度比对称加密慢三个数量级。
• ECC（Elliptic Curve Cryptography） —— 基于椭圆曲线离散对数难题。256 位 ECC 等价于 3072 位 RSA 的安全强度，且计算效率和带宽都好很多。我个人偏好 ECC，尤其是在移动端和 IoT 设备上。
• SM2 —— 国密椭圆曲线公钥密码算法。国内甲方要求「全栈国密」时必用。

对比表：对称 vs 非对称

对比维度	对称加密	非对称加密
密钥数量	1 个密钥（共享密钥）	2 个密钥（公钥 + 私钥）
速度	极快（硬件加速可达 Gbps 级）	慢（比对称慢 100~1000 倍）
密钥分发	困难，需要安全信道	容易，公钥可公开分发
适用场景	批量数据加密、存储加密	密钥协商、数字签名、身份认证
算法示例	AES, SM4, ChaCha20	RSA, ECDSA, SM2
安全基础	密钥的保密性	数学难题（大整数分解/离散对数）

混合加密：为什么实战里永远不只用一种？

你猜猜看，TLS 的握手阶段，客户端和服务端是怎么交换会话密钥的？

答案是：先用非对称加密（比如 ECDHE 密钥交换）协商出一个临时对称密钥，然后后续的数据传输全部用这个对称密钥做 AES 加密。这就是「非对称负责握手，对称负责数据」——各自发挥优势。

BYOK 的整个流程也是这个逻辑。你在本地生成自己的主密钥（对称的？非对称的？都有可能），然后用云 KMS 提供的 RSA 公钥加密这个主密钥，把密文上传。KMS 用自己的私钥解密后，把你的主密钥安全落地。这里你看：非对称加密解决了传输通道的安全问题，对称加密（或后续的密钥包装）负责实际数据的保护。

核心逻辑一图流

下面这张 SVG 把对称加密、非对称加密以及它们在 BYOK 中的协作关系画清楚了。你可以收藏起来，以后跟别人对齐设计思路时直接用。

小结：选型前先问三个问题

讲到这里，你应该清楚了两者的核心差异。我每次做 BYOK 设计时，会先问自己三个问题：

1. 数据量有多大？ 如果是一次性加密几百 MB 的密钥材料，别用非对称，必须用对称加密封装。
2. 密钥怎么传？ 如果传输通道本身不安全（比如公网），那就得用非对称加密（或 KMS 的 RSA 公钥）来保护对称密钥。
3. 谁需要拿到解密权限？ 如果只有一个人/设备能解密，对称加密就够了；如果需要多个实体都能加密、仅一个私钥持有者能解密，那必须上非对称。