加密基础回顾：对称加密与非对称加密，密钥长度与安全强度，哈希与签名
聊 KMS 密钥分层之前，咱们得先把加密底子捋一遍。这东西你天天在用，但如果不理清楚，后面分层设计就容易踩坑。我个人的习惯是，每次接手新项目，都会先画一个简单的加密技术栈图——看看用到了哪些算法，密钥长度是多少，签名和加密是不是混为一谈了。
先看一张核心逻辑图，咱们今天讲的四个模块，以及它们之间的关系：
对称加密与非对称加密——两种加密模式
对称加密，说白了就是加密和解密用同一把密钥。你想想看，两个人在隧道两端，各拿一把一样的钥匙开门。常见的有 AES-256、SM4。特点是速度快，硬件加速友好，适合大数据量加解密。我项目里有一次要做 5GB 日志加密归档，用的就是 AES-256-GCM，几分钟跑完。嗯，对称加密的关键在于——密钥怎么安全传给对方？
核心事实：对称加密的密钥长度，直接决定了暴力破解的难度。AES-128 预计安全到 2040 年，AES-256 保守估计可以顶到量子计算成熟之前。
非对称加密，则是公钥加密、私钥解密，或者反过来。公钥公开，私钥自己保管。常见的是 RSA-2048 和 ECC（椭圆曲线密码）。速度比对称慢两个数量级，不适合直接加密大文件。举个例子，你在网上购物（HTTPS），服务器先用 RSA 协商出对称密钥，之后全程用 AES 加密通讯。为什么要绕一圈？因为非对称解决了密钥分发难题。
我在项目中遇到过一种典型场景：两个异地数据中心之间需要加密同步数据。直接配对称密钥的话，轮换、传递、存储都是麻烦事。后来改用 ECC 密钥交换 + AES 混合模式，安全性和运维方便程度都上了一个台阶。
| 对比项 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数 | 1 个共享密钥 | 公钥 + 私钥一对 |
| 速度 | 快（硬件加速可达几十 Gbps） | 慢（RSA 2048 每秒几百次签名） |
| 典型算法 | AES-256, SM4, ChaCha20 | RSA-2048, ECC-256, SM2 |
| 适用场景 | 数据加密、文件加密、通讯加密 | 密钥交换、数字签名、身份认证 |
| 密钥分发难度 | 高（需要安全通道） | 低（公钥随意传播） |
避坑：我曾经见过一个项目，把 RSA-1024 作为主算法用了五年。后来安全审核一查，发现 1024 位 RSA 已经被 NIST 明确弃用了。我建议各位，2025 年之后，RSA 至少用 3072 位，或者直接上 ECC-256。
密钥长度与安全强度——不是越长越好
很多人有个误解：密钥越长就越安全。嗯，原则上没错，但具体得看算法和实际场景。为什么？我给你一个对比：AES-128 有 2^128 种可能性，宇宙中的原子数大约是 2^266，但你可以说 128 位密钥在经典计算下已经足够安全了。RSA-2048 虽然密钥长度是 2048 位，但它的安全强度大约只相当于对称加密的 112 位——因为 RSA 依赖大整数分解，不是完全平铺搜索。
你想想看，选择一个密钥长度，其实是平衡安全、性能和兼容性。我之前帮一家金融客户做密钥方案时，他们想给所有接口都上 RSA-4096。但我看了一下业务量，每天几十亿次签名验证，4096 位会直接撑爆证书验证服务的 CPU。最后折中方案：核心签名用 ECC-384，非核心 API 用 RSA-3072。性能下降不到 5%，但生命周期管理轻松了很多。
- AES-128：足够用于绝大多数商业场景，预计安全 30 年以上
- AES-256：面向未来的选择，抗量子计算能力比 128 更强
- RSA-3072：目前推荐的最低 RSA 长度，对应对称 128 位安全强度
- ECC-256：与 AES-128 安全强度相当，密钥和签名更短
- SM2-256：国密算法，256 位 ECC，安全强度对标 ECC-256
实践建议：在 KMS 设计里，我通常把对称密钥的生命周期定为 2 年，非对称密钥的私钥可以延长到 5 年。但如果你使用 HSM 硬件保护根密钥（Root Key），它的轮换周期可以放宽到 10 年甚至更长。
哈希与签名——完整性验证与身份认证
哈希函数，是单向的——你不管输入多大，它吐出一个固定长度摘要。比如 SHA-256，输出 256 位。哈希用来干嘛？最典型的两个场景：文件完整性校验、数据去重。为什么能校验？因为哪怕你改一个 bit，哈希值就会变。嗯，这里要注意，哈希本身不保证防伪，它没有私钥的概念。
数字签名，则是哈希 + 非对称加密的组合。签名方用自己的私钥对哈希值加密，验证方用签名方的公钥解密哈希值，再对比重新计算的哈希。对的，核心是——证明这个数据是谁给的，以及数据没有被篡改。我在项目中遇到过 SaaS 平台要求给每一个 API 响应都加上 ECDSA 签名，这样客户端可以验证服务器是真的，不需要再查证书。
// 用 OpenSSL 做 ECDSA 签名和验证的脚本思路
// 1. 生成密钥对
// openssl ecparam -genkey -name prime256v1 -out private.pem
// 2. 提取公钥
// openssl ec -in private.pem -pubout -out public.pem
// 3. 对文件签名
// openssl dgst -sha256 -sign private.pem -out data.sig data.bin
// 4. 验证
// openssl dgst -sha256 -verify public.pem -signature data.sig data.bin哈希和签名在密钥分层中最关键的作用，就是验证每个层的密钥是否被篡改过。比如底层 HSM 把包裹密钥（Wrapped Key）吐出来给你，你先跑一遍哈希，再拿 HSM 的公钥签名。如果对不上，说明包裹密钥被改过，立即停止加载。
| 特性 | 哈希 | 数字签名 |
|---|---|---|
| 输出 | 固定长度摘要 | 签名（长度随算法变化） |
| 密钥 | 无密钥 | 需要私钥 + 公钥 |
| 是否可逆 | 否 | 用于验证 |
| 验证对象 | 数据完整性 | 数据完整性 + 身份 |
| 常见算法 | SHA-256, SM3, BLAKE2 | ECDSA, RSA-PSS, SM2 |
| KMS 中的用途 | 校验密钥材料是否损坏 | 校验密钥来源是否可信 |
一句话总结：对称加密保数据机密性，非对称加密保密钥分发安全性，哈希保数据完整性，签名保数据来源真实性。四个基础模块，是后面密钥分层设计的基石。
好了，这一章的核心就这么多。记着多看几遍那四象限图，后面讲到密钥派生和分层包裹时，你会一直用到这张图。