密码学基础回顾：对称加密与非对称加密、哈希函数、数字签名原理

说实话，每次带新人做安全更新分发项目，我都要先花半天时间跟他们捋一遍密码学基础。不是他们基础差，而是这部分知识太容易被忽略——大家总觉得“加密嘛，调个库就行了”。但真到了签名验证环节出问题，你连日志都看不懂。

这一章，我们就来快速过一遍密码学里最核心的四个概念。我会结合自己踩过的坑来讲，保证你听完就能跟实际场景对上号。

对称加密：简单但有个致命问题

对称加密，说白了就是加密和解密用同一把钥匙。你想想看，就像你家里的大门，用一把钥匙锁上，也用同一把钥匙打开。

常见的算法有 AES、DES、3DES。现在业界基本只用 AES，尤其是 AES-256，安全性足够，性能也还行。

我在项目中遇到过一件事：一个 IoT 设备固件更新，团队用了 AES 加密固件包，密钥硬编码在代码里。结果固件被逆向，密钥直接暴露，整个更新机制形同虚设。嗯，这就是对称加密的典型死穴——密钥分发。

非对称加密：解决密钥分发难题

非对称加密就聪明多了。它用一对密钥：公钥和私钥。公钥可以公开，私钥自己藏好。用公钥加密的数据，只有对应的私钥能解开；反过来，用私钥签名的数据，公钥可以验证。

RSA 是最经典的，但现在我建议新项目优先考虑 ECC（椭圆曲线密码学），同样的安全强度下，ECC 的密钥更短、计算更快。

特性	对称加密	非对称加密
密钥数量	1 个	2 个（公钥 + 私钥）
加解密速度	快	慢（慢 100-1000 倍）
密钥分发	困难	公钥可公开
典型算法	AES, ChaCha20	RSA, ECDSA, Ed25519
主要用途	数据加密	密钥交换、数字签名

哈希函数：数据的“指纹”

哈希函数能把任意长度的数据，压缩成一个固定长度的摘要。而且这个操作是单向的——你没法从摘要反推出原始数据。

好的哈希函数要满足几个条件：

• 抗碰撞性：很难找到两个不同的输入，产生相同的输出
• 单向性：从输出反推输入，计算上不可行
• 雪崩效应：输入改一个比特，输出大变样

常用的哈希算法有 SHA-256、SHA-3。MD5 和 SHA-1 已经不安全了，千万别再用。

数字签名：完整性的终极保障

数字签名解决的是三个问题：

1. 身份认证：数据确实来自声称的发送方
2. 完整性：数据在传输中没有被篡改
3. 不可否认性：发送方不能事后抵赖

签名过程其实很简单：

• 发送方用哈希函数计算数据的摘要
• 用私钥对摘要进行加密（这就是签名）
• 把原始数据和签名一起发给接收方
• 接收方用公钥解密签名，得到摘要 A
• 接收方自己计算原始数据的摘要 B
• 如果 A == B，签名验证通过

我曾经在一个车机 OTA 项目里遇到过签名验证失败的 Bug。排查了两天，最后发现是签名时用的哈希算法是 SHA-256，但验证端默认配置了 SHA-1。两边算法不匹配，签名自然通不过。从那以后，我要求所有项目的签名算法配置必须显式声明，不能依赖默认值。

知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以看到对称加密、非对称加密、哈希函数和数字签名之间的关系，以及它们在安全更新场景中的位置。

实际项目中的选择建议

讲了这么多理论，最后给点实在的。如果你正在设计安全更新系统，我的建议是：

• 签名算法：优先用 Ed25519，性能好、签名短、实现安全。RSA 虽然成熟，但密钥太长，签名也大，不适合 IoT 设备。
• 哈希算法：SHA-256 是底线，别用更弱的。SHA-3 也可以，但生态不如 SHA-256 成熟。
• 对称加密：固件包本身如果不需要保密，可以不加密，只签名。如果需要保密，用 AES-256-GCM，自带认证加密，省事。
• 密钥管理：私钥必须放在硬件安全模块（HSM）或安全飞地（Secure Enclave）里。别学我前面说的那个团队，把私钥放代码里。

好了，密码学基础就回顾到这里。这些概念是后续所有安全机制的地基，理解透了，后面讲签名链、证书管理、分发协议的时候，你才能跟得上节奏。