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

说实话，很多做跨平台集成的同学，最后踩的坑往往不是代码写错了，而是密码学基础没打牢。我见过太多人把「哈希」当「加密」用，或者搞混「签名」和「加密」的顺序。嗯，这一节我们就来把这些概念彻底理清楚。

你想想看，签名验签库的核心就四个东西：对称加密、非对称加密、哈希函数、数字签名。搞懂它们，后面集成什么库都不慌。

2.1 对称加密：快，但密钥怎么传？

对称加密，说白了就是加密和解密用同一把钥匙。就像你用一把锁锁住箱子，再用同一把钥匙打开它。

常见的算法有：

• AES（Advanced Encryption Standard）—— 目前最主流，我项目里90%的场景都用它
• DES —— 太老了，密钥只有56位，现在基本不推荐
• SM4 —— 国密标准，国内项目必须支持

对称加密最大的优点就是 快。加密大文件、视频流、数据库字段，首选对称加密。但它的痛点也很明显——密钥怎么安全地传给对方？

算法	密钥长度	速度	安全性	推荐场景
AES	128/192/256 bit	快	高	通用加密、文件加密
SM4	128 bit	快	高	国密合规场景
DES	56 bit	中等	低（已破解）	不推荐使用

2.2 非对称加密：慢，但解决了密钥分发

非对称加密，有一对密钥：公钥和私钥。公钥可以公开，私钥自己藏好。用公钥加密的数据，只有对应的私钥能解开；反过来，用私钥加密的数据，只有对应的公钥能解开。

常见的算法：

• RSA —— 最经典，2048位以上才安全
• ECC（椭圆曲线）—— 更短的密钥达到同等安全强度，移动端首选
• SM2 —— 国密椭圆曲线算法

非对称加密解决了密钥分发问题，但代价是 慢。比对称加密慢几百到上千倍。所以实际项目中，我们通常用非对称加密来传输对称密钥，然后用对称加密来加密实际数据。这叫「混合加密」。

2.3 哈希函数：不是加密，是摘要

哈希函数，很多人叫它「加密哈希」，其实它根本不是加密。加密可以解密，哈希不行。哈希是单向的——你把任意长度的数据扔进去，出来一个固定长度的摘要。而且哪怕原文只改一个比特，摘要就完全不一样。

常见的哈希算法：

• SHA-256 —— 目前最推荐，签名验签标配
• MD5 —— 128位，已被碰撞攻击破解，别用了
• SHA-1 —— 160位，也已不安全
• SM3 —— 国密哈希，256位

哈希在签名验签里的作用是什么？很简单——我们不会直接对几百兆的文件做签名，那样太慢了。而是先对文件做哈希，得到一个固定长度的摘要，然后对这个摘要做签名。这样既快又安全。

2.4 数字签名：防篡改、防抵赖

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

1. 发送方对数据做哈希，得到摘要
2. 发送方用 自己的私钥 对摘要加密，得到签名
3. 发送方把「数据 + 签名」一起发给接收方
4. 接收方对数据做同样的哈希，得到摘要A
5. 接收方用 发送方的公钥 解密签名，得到摘要B
6. 比较摘要A和摘要B，一致则签名验证通过

为什么这样能防篡改？因为签名是用私钥生成的，只有发送方有私钥。如果有人篡改了数据，接收方重新计算的摘要就和签名里解密出来的摘要对不上。

为什么能防抵赖？因为私钥只有发送方有，只要签名能用发送方的公钥验证通过，发送方就无法否认这个签名是自己生成的。

2.5 知识体系总览

下面这张图，把这一节的核心关系都串起来了。我建议你多看几遍，把每个箭头代表的含义记清楚。

2.6 小结：记住这几条

• 对称加密：快，适合加密大数据，但密钥分发是难题
• 非对称加密：慢，适合加密小数据，解决密钥分发问题
• 哈希函数：单向摘要，不是加密，用于数据完整性校验
• 数字签名：哈希 + 非对称加密，先摘要后签名，防篡改防抵赖