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

聊签名流程，绕不开密码学。很多同学觉得密码学是数学家的活儿，离工程很远。其实不然。你每天都在用——HTTPS、SSH、代码签名，底层全是这些东西。

我个人习惯把密码学工具分成三类：加密、哈希、签名。这三样搞明白，签名流程的骨架就有了。今天咱们先啃上半部分。

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

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

常见的对称加密算法有：

对称加密最大的优势是快。我在项目中做过压测，AES-256 软件实现能跑到几百 MB/s，硬件加速下更是 GB 级。但它的痛点也很明显——密钥分发。你把密钥传给对方，中途被截了，加密就形同虚设。

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

非对称加密解决了密钥分发的难题。它有一对密钥：公钥公开分发，私钥自己藏好。公钥加密的数据，只有私钥能解开；反过来，私钥签名的数据，公钥能验证。

常见的非对称算法：

• RSA：最经典，2048 位起步，4096 位更稳妥。但慢，签名 2048 位 RSA 每秒也就几千次。
• ECC（椭圆曲线）：同等安全强度下，密钥更短，性能更好。比如 256 位 ECC 约等于 3072 位 RSA。
• SM2：国标椭圆曲线算法，国内合规首选。

非对称加密虽然解决了密钥分发，但性能是硬伤。所以实际工程中，没人会用非对称加密去加密大文件。怎么做？混合加密——用非对称加密传对称密钥，再用对称密钥加密数据。HTTPS 的 TLS 握手就是这么干的。

哈希函数：数据的指纹

哈希函数，输入任意长度的数据，输出固定长度的摘要。而且它是单向的——从摘要反推原始数据，理论上不可能。

好的哈希函数要满足几个特性：

1. 抗碰撞性：很难找到两个不同的输入，产生相同的输出。
2. 单向性：给定输出，无法反推输入。
3. 雪崩效应：输入改一个 bit，输出一半以上的 bit 都变。

常用的哈希算法：

哈希在签名流程里干什么用？给数据打指纹。你想想看，签名是对整个文件做运算，文件一大，非对称加密慢得受不了。所以先对文件算哈希，得到一个固定长度的摘要，再对这个摘要签名。这样既保证了完整性，又提升了性能。

数字签名原理：盖章的艺术

数字签名，本质上就是用私钥对数据的哈希值做加密。验证方用公钥解密，比对哈希值是否一致。

流程是这样的：

1. 签名方：对原文算哈希 → 用私钥加密哈希 → 得到签名值 → 把原文和签名一起发出去。
2. 验证方：收到原文和签名 → 用公钥解密签名得到哈希1 → 对原文算哈希得到哈希2 → 比对哈希1和哈希2是否相等。

如果相等，说明两件事：数据没被改过（完整性），数据确实来自私钥持有者（真实性）。

常见的签名算法有：

• RSA-PSS：RSA 的概率性签名方案，比传统 PKCS#1 v1.5 更安全。
• ECDSA：基于椭圆曲线的签名算法，效率高，密钥短。
• SM2 签名：国标椭圆曲线签名算法。
• Ed25519：新一代高性能签名算法，安全性和性能都很出色，我最近几个项目都在用。

知识体系总览

下面这张图，把今天讲的核心关系串起来了。你可以把它当作本章的思维导图。

小结

今天的内容，说白了就是三句话：

• 对称加密：快，但密钥分发麻烦。适合加密数据本身。
• 非对称加密：慢，但解决了密钥分发问题。适合加密对称密钥和做签名。
• 哈希函数：单向、固定长度、抗碰撞。适合给数据打指纹。

数字签名，就是把这三者组合起来——用哈希保证数据没变，用私钥签名保证是你发的。下一章我们会深入签名流程的具体实现，包括怎么生成密钥对、怎么签名、怎么验证，以及常见的坑。