密钥管理基础：对称与非对称加密、哈希函数、密钥长度选择

说实话，密钥管理这玩意，是密码学里最容易被忽视的环节。很多人上来就研究算法复杂度，结果项目上线被一把钥匙就给捅穿了。我当年跟过一个项目，密钥硬编码在代码里，最后遭了，嗯，从那以后我对密钥管理就特别上心。

这一章，我们就来捋一捋最基础，也最核心的东西：对称加密、非对称加密、哈希函数，以及你该怎么选密钥长度。这些都是你搭密钥边界项目案的基石，绕不过去。

对称加密：又快又简单，但有个致命弱点

对称加密，说白了就是一把钥匙开一把锁。加密和解密，用的是同一个密钥。它的好处就是快，特别适合大量数据的加解密。你想想看，文件、数据库、网络流数据，通常都会用它。

• AES：全球公认的现代标准，128、192、256 位。
• DES：太老了，56 位的密钥，现在用暴力破解就能在几天内搞定。别用了。
• SM4：咱们国家的商用密码标准，如果你的项目有国密合规要求，这是必选项。

对称加密的问题在哪？密钥传输。你想想，双方必须有个安全通道去交换密钥，这不就成了“先有鸡还是先有蛋”的问题了？互联网上，你怎么把密钥安全地传出去？

避坑指南：我曾经接过一个案子，对方用对称加密，但密钥是通过邮件用明文发的。结果被中间人截获，数据全都白加密了。所以，对称加密要配合非对称加密的密钥交换机制一起用。

非对称加密：公钥随便发，私钥自己藏

非对称加密的思路就很巧妙。它有两把钥匙：公钥和私钥。公钥你可以公开，发给任何人；私钥必须自己保存，谁也不给。

工作原理其实不复杂：

1. 加密：用接收方的公钥加密数据。只有接收方的私钥能解开。
2. 数字签名：用自己的私钥签名数据。任何人用你的公钥都能验证签名是不是你本人。

这就是它厉害的地方——解决了密钥分发难题。我不需要事先跟对方协商任何秘密，我只要拿到他的公钥，就能加密消息传给他。

常见的非对称加密算法：

• RSA：经典，但密钥长度越来越大。现在至少2048位，我还是那句话，稳妥起见用4096位。
• ECC：椭圆曲线，以更短的密钥提供同等安全强度。我建议你用 P-256 或 X25519。
• SM2：国密标准，基于 ECC，性能很不错。

算法	安全强度对比	推荐密钥长度
AES	对称加密标准	256 位
RSA	中等（通常用于签名）	3072 / 4096 位
ECC (P-256)	高，等同 AES-128	256 位
SM2 / SM4	国密标准	256 位

哈希函数：不是加密，但比加密更重要

哈希函数跟加解密完全是两码事。它是个单向函数：你输入任意大小的数据，它输出固定长度的摘要。而且，你没办法从摘要反推出原始数据。

它在密钥管理里主要干这几件事：

• 数据完整性校验：传输完数据，比一下哈希值，就知道有没有被篡改。
• 密码存储：别存明文密码！存密码的哈希值。就算数据库被人拖了，攻击者也拿不到你的原始密码。
• 消息认证码（HMAC）：用哈希函数结合密钥，生成一个验证标签，确保消息是来自真正的发送方且未被篡改。

避坑指南：我曾经看过有人在密码验证里只做了一次 SHA-256。这不够。你要用 PBKDF2、bcrypt 或 argon2 这类慢速哈希，增加暴力破解的成本。

密钥长度选择：不是越长越好，但也不是越短越安全

很多人问我：钥匙越长是不是就越安全？从理论上讲，是的。256位密钥的暴力破解空间是128位的2的128次方倍，可以说是天文数字。

但是，你得考虑性能。RSA 4096位的加密，在移动设备上可能会慢得让人抓狂。而且，密钥越长，生成时间、签名时间、验证时间都在增加。

我个人在工程里的选择思路是这样的：

• 对称加密：AES-256。性能开销小，安全裕度大。128位也行，但我不冒这个险。
• 非对称加密（RSA）：你要是用非对称加密做密钥交换，建议上3072或4096位。如果只是签名，2048位目前还够用，但考虑到未来量子计算的威胁，我劝你直接上ECC。
• ECC：P-256 或 X25519。256位足够，性能非常好。
• 哈希：SHA-256。输出256位摘要，安全性足够。

下面是本章的整体知识结构图。你一看就能明白对称加密、非对称加密、哈希函数是如何在密钥管理里协作的。

你看这张图：对称加密和非对称加密，通过混合加密系统相结合，既解决了性能问题，也解决了密钥分发问题。而哈希函数，则撑起了数据完整性和认证的半边天。密钥长度的选择，是你最终落地时要权衡的实际问题。