密钥管理基础：对称与非对称加密

从一把钥匙说起

做密码学项目这么多年，我越来越觉得密钥管理就像管一把瑞士军刀。对称加密和非对称加密，说白了就是两套完全不同的锁具。你想想看，一个家里锁门，是只用一把钥匙，还是用两把——一把开锁一把关锁？这就是两者的核心区别。

我在好几个GDPR合规项目里都踩过加密选型的坑。有一次客户说“我们用AES-256就够了吧”，结果到最后发现密钥分发根本没法在跨国团队里安全进行。嗯，这里要讲清楚——对称加密快，但密钥管理难；非对称加密慢，但密钥分发简单。

对称加密：又快又脆

对称加密就是加密和解密用同一把密钥。好处是性能好，适合大规模数据加密。但问题也很明显——你该怎么把这把密钥安全地交给对方？

我个人习惯用一张表来对比常见的对称加密算法：

曾经有个项目，团队用AES-256加密了客户数据库，然后把密钥明文硬编码在配置文件里。你说这加密还有什么意义？所以对称加密真正的难点不在算法，而在密钥的生成、存储和分发。

非对称加密：慢但可靠

非对称加密就是公钥加密、私钥解密，或者私钥签名、公钥验签。它解决了密钥分发的难题——公钥可以随便给，私钥自己保管好就行。但代价就是速度慢，不适合加密大块数据。

为什么非对称加密能解决分发问题？你想想看，你去注册一个网站，网站把它的公钥发给你，你用这个公钥加密你的密码。即使中间有人窃听，他没有私钥也解不开。这个特性在GDPR要求的数据传输保护中非常关键。

我见过的实际项目中，非对称加密通常这么用：

• TLS握手：用非对称交换会话密钥，后续用对称加密传输数据。
• 数字签名：用私钥签名数据，公钥验签，确保数据完整性和来源可信。
• 密钥封装：用接收方公钥加密对称密钥，再传输。

常用的非对称算法对比如下：

混合加密：取长补短

你猜怎么着？实际工程里没人只用一种加密。我们通常搞一个混合方案：

1. 用密钥生成器产生一个随机对称密钥（比如AES-256）。
2. 用接收方的公钥加密这个对称密钥。
3. 用对称密钥加密实际数据。
4. 把加密后的数据和加密后的对称密钥一起发送给对方。

接收方用自己的私钥解密出对称密钥，再用对称密钥解密数据。这个过程在TLS里每天都在跑。

下面是这个流程的SVG示意图，我把它画成了清晰的分步图——从数据源到接收端，每一步的操作和密钥角色都标出来了。

GDPR 合规的关键点

欧盟对个人数据的保护，核心就是“数据加密”和“密钥分离”。不管用对称还是非对称，以下几点你必须做到：

• 密钥必须与数据分开存储——这是最基本的边界。
• 密钥的生命周期必须记录——生成、激活、过期、销毁，每个步骤都要审计。
• 密钥必须轮换——我建议最长12个月必须换一次。
• 私钥的备份必须加密——用多把密钥拆分开，或者用秘密共享方案。

还有一个容易被忽视的点——密钥长度选择。在GDPR框架下，加密强度必须符合行业标准。目前欧洲网络安全局（ENISA）推荐至少128位对称等效安全，也就是AES-128或者RSA-3072以上。我建议直接用AES-256 + ECDSA P-384，留点冗余量应对未来量子计算威胁。

嗯，这一章的内容就这些。对称与非对称的边界掌握好了，后面的密钥治理方案才能搭得稳。希望你在自己项目里也能避开那些坑。