3、对称密钥与非对称密钥：场景选择与边界安全考量

密码改造做到一定深度，你会发现绕不开一个核心问题：什么时候用对称密钥，什么时候用非对称密钥？ 这俩东西在边界上到底怎么分工？我个人习惯是把它们看作「门锁」和「门禁系统」的关系——一个负责把门关上锁死，一个负责决定谁能拿到钥匙。

但现实中很多人会把它们混在一起用，或者干脆只认一种。我在项目中遇到过这样的案例：某系统全栈只用 RSA 加密传输数据，结果一条 1M 的消息要加密十几秒，性能直接崩了。反过来，也有团队全部用 AES，结果密钥分发搞成了一锅粥。

所以这一章我带着你把这俩家伙的脾气摸清楚，再看看它们怎么在边界上配合。

对称密钥：快，但共享是个麻烦

说实话，对称密钥在加解密效率上几乎无可匹敌。说白了，它的核心逻辑就是加解密用同一把钥匙。

它的优势非常明确。计算开销低，所以适合大量数据的「体量级」加密。你可以想想看：一个视频流每秒几兆的数据，如果每帧都用非对称加密来整，你的 CPU 扛不住的。

非对称密钥：方便，但千万别用它加密大块数据

非对称密钥的巧思在于公钥和私钥分离。你可以把公钥随便贴到墙上，私钥锁在自己保险柜里。这样一来，密钥分发的麻烦就大大降低了。

但代价也很明显——性能差。差到什么程度？我做过一次基准测试：RSA-2048 对 1KB 数据的加密耗时，大概是 AES-256 对 1MB 数据加密耗时的 20 倍以上。所以，用非对称密钥直接加密消息体是个馊主意。

边界安全考量：谁守门，谁看门？

密码改造里，边界安全的核心是通信隧道和数据存储。我建议这么分工：

1. 通信边界（TLS/IPSec）：用非对称密钥做握手和身份认证，用对称密钥加密流量。
2. 数据存储边界（数据库/文件）：直接用对称密钥加密整块数据，非对称只用来保护这个对称密钥。
3. 身份签名边界：非对称私钥签名，公钥验签；对称密钥在这块基本用不上。

为什么要这样分？你想想看：

• 通信链路上的数据是「流动的」，每次会话都需要建立信任——这个信任靠非对称完成。但一旦握手结束，大量的报文传输如果还用非对称，那通信就变成了龟速。
• 存储数据是「静止的」，它的加解密频率远低于通信，而且密钥可以长期持有。所以你完全可以用对称密钥一次性地把整个数据库表加密，再用非对称密钥保护这个对称密钥的备份。

混合加密系统的实战结构

在真实的密码改造项目中，我通常会用这样一套策略：

1. 使用 ECDH 或 SM2 密钥协商 在双方之间安全地产生一个临时对称密钥。
2. 使用 AES-256-GCM 或 SM4-GCM 对这个会话进行加密传输。
3. 使用 RSA-2048 或 SM2 签名 对传输的消息附加数字签名以保证完整性。
4. 对称密钥仅存在于内存中，不落盘；非对称私钥用 HSM 或 TEE 保护。

下面是两种密钥在边界上的核心分工图，我建议你保存起来，做架构设计时对着看：

边界实战建议：选择时的三个维度

每次做密码改造决策时，我习惯从三个维度来审视：

1. 数据体量：如果数据量超过几百 KB，优先选对称密钥加密数据体；非对称只用来加密对称密钥本身。
2. 身份验证需求：如果需要证明「你是谁」或者「数据有没有被篡改」，只能选非对称数字签名。对称密钥在这里无能为力。
3. 密钥生命周期：短期会话密钥可以用对称（临时生成用完就销毁）；长期根密钥必须用非对称并放到硬件安全模块里。