密钥生成算法：RSA、ECC、AES、HMAC 等

说到密钥生成，很多新手上来就问：哪个算法最好？说实话，没有的最优。我这些年折腾下来，觉得选算法更像是配钥匙——你得看门是哪家的，锁芯长什么样。下面我把四大类核心算法掰开揉碎了讲。

对称 vs 非对称，先分清楚

简单画个界线：对称算法加密和解密用同一把钥匙，速度快；非对称算法有一对钥匙（公钥+私钥），安全但慢。实际应用中，往往混合使用。嗯，下面这张图能帮你快速定位。

密钥生成算法体系 密钥生成算法 非对称 对称 RSA ECC AES HMAC 1024~4096 bit 256~521 bit 128~256 bit 160~512 bit 应用场景速览 RSA: 数字签名、密钥交换、证书 ECC: 移动端、IOT、区块链钱包 AES: 文件加密、数据库、通信加密 HMAC: API鉴权、消息完整性校验

RSA —— 非对称的老大哥

RSA 基于大整数分解难题。你想想看，两个大质数相乘容易，但把积拆回去几乎不可能。我最早接触 RSA 是在大学密码学课上，老师给我们演示怎么用 openssl 生成一对 1024 位的钥匙。

生成流程大概三步：

  1. 随机选两个大素数 p 和 q，计算 n = p×q
  2. 计算欧拉函数 φ(n) = (p-1)(q-1)，选一个公钥指数 e
  3. 用扩展欧几里得算法算私钥 d ≡ e⁻¹ mod φ(n)

我个人习惯用 2048 位起步，512 位早就不安全了。记得几年前有个客户拿了个 768 位的证书来，我当场就让他升级——那个长度在公开文献里已经被证明可破解。

避坑指南：我曾经在生成 RSA 密钥时忘记检查随机数源，结果在嵌入式设备上重复生成了相同的 p 和 q。后来我每次都要做一次 openssl rsa -check -in key.pem 确保唯一性。

ECC —— 更短的钥匙，同等的安全

ECC 靠的是椭圆曲线上的离散对数问题。说白了，它用更短的密钥长度就能达到 RSA 差不多的安全水平。比如 256 位的 ECC 强度对标 3072 位的 RSA。

常见曲线：

  • NIST P-256（secp256r1）—— 最常用，浏览器、TLS 握手的大路货
  • Curve25519（X25519）—— 我近几年最喜欢用，侧信道攻击防御好，速度快
  • secp384r1 —— 对顶级安全有偏执时选它

为什么 ECC 性能优势这么明显？因为你看 RSA 每次签名都要做大整数模幂，而 ECC 只是点乘运算。我在移动端项目里实测，ECC 签名比 RSA 快 10 倍以上，省电不是一星半点。

AES —— 对称加密的标配

AES 不是钥匙生成本身，而是生成密钥后怎么用。但密钥生成阶段要特别注意：密钥必须真随机。我见过有人用当前时间戳当 AES 密钥——这就是个定时炸弹。一个好的 AES 密钥应该这样生成：

# Python 示例：从系统熵源生成 256 位 AES 密钥
import os
aes_key = os.urandom(32)  # 32 字节 = 256 位
print(aes_key.hex())

密钥长度有 128、192、256 三种。我的建议：新项目统一用 256 位。128 位虽然还没被暴力破解，但量子计算在路上了，能留点余量就留点。

HMAC —— 不是加密，是认证

HMAC 全名叫散列消息认证码。它不生成长期密钥，而是基于一个预共享的密钥和哈希函数（如 SHA-256）产生一个定长的认证标签。你想想看，API 鉴权时怎么防止消息被篡改？HMAC 就是标准答案。

生成 HMAC 密钥时同样要随机，长度一般和底层哈希输出一样（SHA-256 就是 32 字节）。

注意！ 不要复用其他算法的密钥给 HMAC。我曾经遇到一个团队把 AES 的密钥直接拿来做 HMAC，结果因为密钥长度和哈希块大小不匹配，导致潜在的侧信道泄露。各算法密钥独立生成，这是铁律。

算法选型清单

下面这张表是我自己项目里常用的选型参考，直接拿去用：

算法 密钥长度（位） 速度 典型场景 注意事项
RSA2048~4096慢（签名/验证）证书、密钥交换长度不要低于2048
ECC256~521快移动端、区块链选择标准曲线，避免自定义
AES128/192/256极快批量数据加密密钥必须真随机，建议256
HMAC与哈希输出同长快消息认证、API鉴权密钥独立生成，不与其他算法共用

总结一句话

选算法就是配对场景，没有万能钥匙。RSA 适合证书体系，ECC 轻量高效，AES 负责批量加密，HMAC 确保消息没被动过手脚。生成密钥时，记得三个字：真随机、不重用、留余量。做到这三点，密钥生成这关基本就稳了。

← 上一章 📖 返回目录 下一章 →