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

各位同学，咱们今天聊点硬核的。密码学这东西，听起来高大上，其实说白了就是「怎么藏秘密」和「怎么证明你是谁」这两件事。我做固件签名这么多年，踩过的坑有一半都跟密码学基础不扎实有关。今天咱们就把这几个核心概念掰开揉碎了讲清楚。

一、对称加密：一把钥匙开一把锁

对称加密，顾名思义，加密和解密用的是同一把密钥。就像你家里的大门，用一把钥匙锁上，再用同一把钥匙打开。

我早年做一个小型 IoT 设备固件升级时，就图省事用了对称加密。结果密钥硬编码在代码里，被逆向工程师一把揪出来……嗯，从那以后我再也不敢这么干了。

常见的对称加密算法：

算法	密钥长度	特点
AES	128/192/256 bit	目前最主流，硬件加速支持好
DES	56 bit	太老了，别用了，我见过有人还在用，赶紧换
3DES	112/168 bit	DES 的加强版，但效率低，也不推荐
SM4	128 bit	国密标准，国内项目必须考虑

二、非对称加密：公钥私钥，各司其职

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

你想想看，这解决了什么问题？密钥分发！你不需要偷偷摸摸把密钥传给对方，直接把公钥扔到网上都行。

常见的非对称加密算法：

算法	密钥长度	典型用途
RSA	2048/4096 bit	签名、加密，最经典
ECC	256 bit（相当于 RSA 3072）	签名、密钥交换，短密钥高强度
SM2	256 bit	国密椭圆曲线算法

三、哈希函数：数据的指纹

哈希函数，说白了就是把任意长度的数据，压缩成一个固定长度的「指纹」。这个指纹有几个特点：

• 单向性：从指纹反推原始数据，理论上不可能
• 抗碰撞性：很难找到两个不同数据有相同的指纹
• 雪崩效应：改一个 bit，指纹天差地别

我在项目中遇到过最典型的场景：固件完整性校验。你下载了一个固件包，怎么知道它没被篡改？算一下它的哈希值，跟官方公布的对比一下就行。

常见的哈希算法：

算法	输出长度	安全性
MD5	128 bit	已破解，别用了
SHA-1	160 bit	已破解，别用了
SHA-256	256 bit	目前安全，推荐
SM3	256 bit	国密标准，国内项目推荐

四、数字签名：证明这东西是你发的

数字签名，就是把哈希函数和非对称加密结合起来。流程是这样的：

1. 发送方对数据算哈希，得到摘要
2. 发送方用私钥对摘要加密，得到签名
3. 发送方把数据和签名一起发出去
4. 接收方用公钥解密签名，得到摘要 A
5. 接收方对数据算哈希，得到摘要 B
6. 对比 A 和 B，一致则签名有效

你想想看，这保证了什么？

• 完整性：数据被篡改，哈希对不上
• 真实性：只有持有私钥的人才能生成有效签名
• 不可否认性：私钥只有你自己有，你不能说「这不是我签的」

五、知识体系总览

下面这张图，把今天讲的核心概念串起来了。我建议你多看几遍，理清它们之间的关系。

六、实际应用中的选择建议

说了这么多理论，咱们落地到固件签名场景里，我给出几个实际建议：

• 哈希算法：用 SHA-256，别犹豫。MD5 和 SHA-1 已经进了历史垃圾堆。
• 签名算法：RSA-2048 是稳妥之选，ECC-256 性能更好。如果做国密项目，用 SM2。
• 密钥管理：私钥必须放在硬件安全模块（HSM）或安全芯片里，别放文件系统里。我曾经见过有人把私钥放在 Git 仓库里……那画面太美我不敢看。
• 签名流程：先哈希，再签名。不要直接对固件签名，效率太低。