一、密钥管理基础概念：对称密钥、非对称密钥、哈希函数、数字签名
聊密钥管理之前，咱们得先把地基打牢。我记得刚入行那会儿，觉得加密就是给数据加把锁，简单得很。结果第一次设计密钥轮换方案时，被对称和非对称混用搞得焦头烂额。说白了，这四种基础概念就像工具箱里的扳手、螺丝刀、锤子和卷尺——各有各的用处，用错了地方，工程就要出问题。
你想想看，一份敏感数据要安全地在网络上传递，光靠一种技术是不够的。我习惯把这四个概念看作一套组合拳：对称密钥负责高效加密，非对称密钥解决密钥分发难题，哈希函数保证数据完整性，数字签名验证身份与来源。嗯，下面咱们一个一个拆开看。
1. 对称密钥：一个钥匙开一把锁
对称密钥加密，说白了就是加密和解密用同一把钥匙。你和我各拿一份相同的密钥，你加密发给我，我拿这把钥匙解密就能看到原文。这就像我们用同一个密码锁——你锁上箱子寄给我，我用同样的密码打开。
常见对称加密算法：
- AES（Advanced Encryption Standard）——目前最主流，密钥长度128/192/256位。我习惯用AES-256-GCM，带认证加密，省事又安全。
- DES/3DES——DES已过时，56位密钥太短。3DES虽然安全，但效率低。我项目中遇到过遗留系统还在用3DES，我们迁移到AES费了不少劲。
- SM4——国密标准，国内合规场景必选。嗯，对，在政府项目里经常用。
优点很明显：快，非常快。适合加密大块数据，比如文件、数据库字段、网络流媒体。但缺点也致命——密钥怎么安全地交给对方？你想想看，如果密钥在传输中被截获，加密就形同虚设。
我的一点经验：对称密钥一定要定期轮换。我曾经在维护一个老系统时发现一组AES密钥用了两年没换过，当时冷汗都下来了。现在我的原则是：密钥有效期不超过90天，高风险场景缩短到30天。
2. 非对称密钥：公钥锁，私钥开
非对称密钥引入了一对钥匙：公钥可以公开给任何人，私钥只有你自己知道。别人用你的公钥加密一段消息，只有持有私钥的你才能解密。这解决了分发难题——你只管把公钥贴到网上，我用它加密发给你，谁拦截了公钥也没用，因为解密必须用你手中的私钥。
常见的非对称算法有：
- RSA——最经典，密钥长度通常2048或4096位。但注意，RSA随着密钥增长，速度会显著下降。
- ECC（椭圆曲线加密）——比RSA更高效，256位ECC相当于3072位RSA的安全强度。我目前在移动端项目里推荐用ECC，省电又省带宽。
- SM2——国密标准，基于ECC的算法，国内合规场景首选。
不过非对称加密有个硬伤：慢。加密一段小消息还行，要是拿它加密几GB的视频文件，CPU受不了。所以实际工程中，我们通常用它来加密对称密钥——这叫混合加密。具体流程：你生成一个随机的AES密钥，用我的RSA公钥加密后传过来，我用私钥解开拿到AES密钥，之后咱们就用这个AES密钥做对称通信。
注意！私钥泄露意味着一切归零。我见过一个案例：开发人员把私钥硬编码在代码里，然后代码被上传到了公开Git仓库。后果？整个系统都得推倒重来。私钥必须存放在硬件安全模块（HSM）或密钥管理服务（KMS）中。
3. 哈希函数：数据的指纹
哈希函数不是加密，它是个单向函数。输入任意长度的数据，输出固定长度的哈希值。而且它不可逆——你不能从哈希值反推出原始数据。你想想看，这像不像指纹？每个人指纹不同，但你不能从指纹画出完整的人脸。
哈希函数有三个核心特性：
- 抗碰撞性：找不到两个不同输入产生相同哈希值。理论上可能存在，但实际计算上不可行。
- 单向性：给定哈希值，无法反推原始输入。
- 雪崩效应：输入微变，哈希值巨变。
| 算法 | 输出长度 | 安全状态 | 典型用途 |
|---|---|---|---|
| MD5 | 128位 | 已破解，不推荐 | 仅用于校验非安全场景（如文件完整性） |
| SHA-1 | 160位 | 有理论攻击，应弃用 | 遗留系统，新系统不要用 |
| SHA-256 | 256位 | 安全，推荐 | 数字签名、证书、密码哈希 |
| SHA-3 | 可配置 | 安全，新一代标准 | 未来兼容性更好的选择 |
| SM3 | 256位 | 国密标准，安全 | 国内合规场景 |
哈希最常见的用途是存储密码。我从来不建议存明文密码，哪怕数据库被拖库，哈希后的密码也能拖住攻击者的脚步。但记住，光哈希还不够——要加盐（salt）。我曾经用彩虹表还原过一批没加盐的MD5密码，那速度……嗯，不提了。
避坑指南：密码哈希不要直接用SHA-256，应该用bcrypt、scrypt或Argon2这类慢哈希函数。它们故意设计得计算慢，能让暴力破解成本高好几个数量级。我曾经在项目里规定：新系统一律用Argon2id，这是目前最推荐的选择。
4. 数字签名：我证明这是我发的
数字签名是非对称密钥和哈希函数的组合。你想证明一份文件确实是你发的，而且没有被篡改。流程是这样的：你给文件算个哈希，然后用你的私钥加密这个哈希——这就生成了签名。别人拿到文件、签名和你的公钥后，可以验证：用公钥解密签名得到哈希值，再自己算一遍文件的哈希——如果两个哈希相同，说明文件是你签发的，且没被改过。
数字签名提供了三个安全服务：
- 身份验证：只有持有私钥的你能生成可被公钥验证的签名。
- 完整性：文件一旦被改，哈希就不匹配，验证失败。
- 不可否认性：你不能事后否认自己签过名——除非私钥泄露，但那又是另一个问题了。
常见的数字签名算法：
- RSA-PSS——RSA的签名方案，兼容性好。
- ECDSA——基于ECC，效率高，适合移动和IoT设备。
- Ed25519——我个人很推荐，性能极佳且实现不容易出错。我在几个性能敏感的项目里都用它。
- SM2——国密标准，支持签名，国内必选。
实际应用小技巧：在微服务架构中，可以用JWT（JSON Web ）来做服务间身份认证。JWT本质上就是一段JSON数据加上数字签名。我通常建议用RS256（RSA with SHA-256）或ES256（ECDSA with SHA-256）算法签发JWT，注意密钥要定期轮换。
讲到这里，四个基础概念都覆盖了。但我想强调一点：它们不是孤立的。你现在看到的任何一个现代安全保障系统，几乎都是这四种技术的有机组合。TLS协议用非对称密钥交换对称密钥，用哈希校验握手完整性，用数字签名验证服务器身份。嗯，这就是所谓的“组合拳”。