密钥管理基础：对称与非对称密钥、哈希算法、密钥长度与安全级别

坦率讲，密钥管理是整个数据安全体系的基石。我见过太多项目，算法选得花里胡哨，结果密钥管理一塌糊涂，最后还是被攻破。这一章我们就把最基础的概念理清楚——搞懂这些，后面的建模才不会走偏。

对称加密：又快又简单，但有个大麻烦

对称加密，说白了就是加密和解密用同一把密钥。你想想看，AES-256这种算法，加密一个1GB的文件只要几秒钟，性能非常好。

我在项目中遇到过这么个坑。有一次帮客户审计他们的文件加密系统，用的AES-256-GCM，算法本身没问题。但他们的密钥分发方式是——直接把密钥写在配置文件里，用Base64编码了一下。我当时就笑了，这跟把家门钥匙放在门口脚垫底下有什么区别？

对称加密还有个细节要注意——工作模式。ECB模式不要用，CTR和GCM是更安全的选择。我习惯用GCM，因为它自带认证功能，能检测数据是否被篡改。

非对称加密：解决了分发问题，但慢

非对称加密用一对密钥：公钥加密，私钥解密。这解决了对称加密的密钥分发痛点。你想想看，公钥可以随便公开，私钥自己保管好就行。

我最近在审计一个金融系统，他们用RSA-2048做交易签名。算法没问题，但他们的私钥存储方式让我捏了把冷汗——明文放在服务器磁盘上。这相当于把保险柜钥匙挂在保险柜外面。

算法	密钥长度	安全级别	典型场景
RSA	2048位	112位等效对称安全	数字签名、密钥交换
ECC	256位	128位等效对称安全	移动端、IoT设备
SM2	256位	128位等效对称安全	国密标准
Ed25519	256位	128位等效对称安全	现代签名方案

你可能会问：为什么RSA要2048位，而ECC只要256位？因为是底层数学原理不同。RSA依赖大整数分解，ECC依赖椭圆曲线离散对数。同等安全强度下，ECC的密钥长度要短得多。我建议新项目优先考虑ECC，特别是资源受限的场景。

哈希算法：不是加密，但必不可少

哈希算法很多人会搞混，以为也是加密。其实不是。哈希是单向的，你从哈希值永远推不出原始数据。我经常跟团队说：哈希算法是数据完整性的守门人。

我在审计中见过最典型的问题是：有人拿MD5做密码哈希。MD5的碰撞攻击早在2005年就被攻破了，现在用彩虹表几秒钟就能还原弱密码。SHA-256是目前最低门槛，密码存储推荐用bcrypt或Argon2。

密钥长度与安全级别：不是越长越好

很多人觉得密钥越长越安全。理论上没错，但实际上要权衡。AES-128已经足够抵抗国家级攻击了，你非要用AES-256，性能损耗30%以上，安全性只提升了一丁点。

你看这张表就明白了：

安全强度	对称密钥长度	RSA密钥长度	ECC密钥长度	建议使用年限
80位	80	1024	160	已废弃
112位	112	2048	224	2020-2030
128位	128	3072	256	2030年后
256位	256	15360	521	长期

我个人习惯：通用场景选AES-128-GCM + ECC-256。金融或政府级选AES-256-GCM + ECC-384。记住，你的系统最薄弱的环节往往不是算法强度，而是密钥管理流程。

其实还有一个容易被忽视的点——密钥的使用次数。我审计过一个云端存储系统，他们用同一把AES密钥加密了上亿个文件。我算过一笔账：如果每天有10万次解密操作，破解者通过侧信道攻击分析功耗模式，可能一年就能提取出密钥。所以，定期轮换密钥非常重要。

总结一下我个人的密钥选型习惯：

• 数据加密用AES-128-GCM，性能和安全的最佳平衡
• 数字签名用Ed25519，密钥短、签名快、实现安全
• 密码存储用bcrypt，cost factor=12，再加随机盐
• 数据完整性校验用SHA-256或SHA-3

密钥管理没有万能方案，得根据你的业务场景来选。但基础概念搞扎实了，后面遇到复杂场景才不会慌。