📚 课程目录第4章常见加密算法

常见加密算法：AES、RSA、ECC、SHA-256、HMAC 的特点与选择

做加密审计日志，说白了就是跟一堆数学问题打交道。很多人一上来就被各种算法搞晕了——这个用在哪、那个管什么，混着用会不会出事？

我个人习惯，先按用途把算法分成三类：对称加密、非对称加密、哈希与消息认证。理清这层关系，你再看具体算法就清晰多了。

加密和解密用同一个密钥。速度极快，适合大批量数据。在审计日志场景中，通常用于加密日志主体内容。

我在项目中遇到过这种情况：团队一开始用了AES-128，觉得够用。后来客户的安全审计要求必须用256位密钥。还好当时留了升级接口，不然得重构大半个解析层。

特性	AES-128	AES-192	AES-256
密钥长度	128 bit	192 bit	256 bit
轮数	10	12	14
安全级别	足够（非绝密）	高安全	最高安全（推荐）
性能	最快	中等	略慢（但依然是硬件级速度）

我的建议：审计日志直接上 AES-256-GCM。GCM 模式自带认证加密，能同时防偷看和防篡改。别用 ECB 模式——它会把相同明文加密成相同密文，等于没加密。

你想想看，如果所有人都用对称加密，密钥怎么安全地传给对方？非对称加密就是用来解决这个问题的。它有一对密钥：公钥公开、私钥保密。

老牌算法，应用最广。生成密钥对很简单，但有个短板——加密速度慢。我一般只在两个地方用它：密钥交换和数字签名。

我曾经踩过一个坑：用RSA-1024去做签名，结果两年后NIST直接把它标记为不安全。从那以后，我的密钥长度底线就是2048位。保守一点，用4096位也行，就是每次签名要多等个几百毫秒。

RSA 选型要点：

ECC（椭圆曲线密码学）是 RSA 的替代方案。同样的安全强度，ECC 的密钥长度只有 RSA 的十分之一左右。

我之前在 IOT 设备上做审计日志，设备存储和计算能力都有限。RSA-2048 签名要跑上百毫秒，换成 ECDSA（P-256 曲线），速度翻了快五倍，密钥存储空间也省了一大截。

个人经验：新项目优先选 ECC。别再用 RSA-1024 了，那东西现在用普通显卡就能破解。曲线选 P-256 或 Curve25519，兼容性最好。

这两种算法不是用来加密的。它们做的是另一件事——保证数据没被改过。

SHA-256 把任意长度的数据，压缩成固定 256 位的摘要。只要原文改了一个比特，摘要就面目全非。这个特性在审计日志里至关重要——我们用它来建立 哈希链。

具体怎么用？每条日志记录完，把上一条日志的哈希和本条日志内容拼起来，再算一次 SHA-256。哪条记录被篡改过，哈希链立马断掉。

警告：别用 MD5 做哈希链！别用 SHA-1！

MD5 已被彻底攻破，人工碰撞可以轻松伪造。SHA-1 虽然还没完全破，但 Google 在 2017 年就已经演示了实际碰撞攻击。

审计日志是防追溯的，一旦哈希被突破，整个日志系统就不值得信任了。

SHA-256 能防篡改，但防不了伪造。攻击者如果拿到了你的哈希算法，完全可以自己算一个合法的哈希值覆盖上去。这时就需要 HMAC。

HMAC 说白了就是带密钥的哈希。只有拥有密钥的人才能生成正确的 HMAC 值。我在审计日志系统里做消息来源验证时，都用 HMAC 代替纯哈希。

HMAC 的核心优势：

现在你知道每种算法做什么了。但在实际项目里，选型不是单选题——你得组合使用。

审计日志环节	推荐算法	我踩过的坑
日志主体加密	AES-256-GCM	用过 CBC + HMAC，结果忘了更新 IV 导致多个日志 IV 复用
日志签名	ECDSA（P-256）	RSA-2048 签名太长，日志行被撑到 8KB 以上
哈希链	SHA-256	有人用 SHA-1 跑了一个月，我要求全部重算
消息来源验证	HMAC-SHA256	密钥写死在配置文件里，差点泄露
密钥交换	ECDH（基于 ECC）	用 RSA 交换密钥，速度太慢被业务投诉

选型建议一句话：

加密体量用 AES，签名密钥用 ECC，完整性校验用 SHA-256，来源认证用 HMAC，密钥交换走 ECDH。

记住这个组合，你的审计日志系统基本就稳了。

嗯，以上这些算法组合我已经在三个不同项目里验证过了。每次遇到选型扯皮，我就掏出这张表——技术主管看了没话说，安全审计看了也挑不出毛病。