1. 签名验签基础概念：数字签名是什么？为什么需要验签？签名与加密的区别

各位好，我是老周。今天咱们开始聊签名验签。说实话，我做了十几年安全工程，见过太多人在签名验签上栽跟头。有的是签名格式不对，有的是验签时密钥搞混了，还有的干脆把签名当加密用——嗯，这个坑我当年也踩过。

所以第一章，咱们先把基础打牢。数字签名到底是什么？为什么非验不可？它跟加密到底有啥区别？搞明白这些，后面调试错误时你才能一眼看出问题在哪。

1.1 数字签名：一张无法伪造的电子手印

数字签名，说白了就是一段附着在数据后面的「电子手印」。它用私钥对数据的摘要进行加密，生成一个别人无法伪造的凭证。

我习惯用一个比喻来解释：你写了一份合同，签上自己的名字，再盖上公章。别人拿到合同，一看签名和公章，就知道是你签的，而且内容没被改过。数字签名干的就是同样的事——只不过是在数字世界里。

具体流程是这样的：

1. 发送方用哈希算法对原始数据算出一个摘要（固定长度的指纹）。
2. 用自己的私钥对这个摘要加密，生成签名。
3. 把原始数据 + 签名一起发给接收方。
4. 接收方用发送方的公钥解密签名，得到摘要A。
5. 同时自己对原始数据算一遍哈希，得到摘要B。
6. 比较A和B——如果一致，说明数据没被篡改，且确实来自私钥持有者。

下面这张图把整个流程串起来了，我建议你多看两眼，后面调试时脑子里要有这个图。

1.2 为什么需要验签？不验行不行？

你可能会想：「数据都加密传输了，还验什么签？」

我跟你讲，不行。加密只保证数据在传输过程中不被偷看，但它不保证数据是谁发的。举个例子：

• 场景A：你收到一条银行转账指令，数据是加密的。但你怎么知道这条指令真的是银行发的，而不是黑客伪造的？
• 场景B：你下载了一个软件更新包，包体是加密的。但你怎么确认这个包没有被替换成恶意版本？

验签就是用来回答这两个问题的。它提供的是：

安全属性	说明	不验签的风险
身份认证	确认数据确实来自声称的发送方	攻击者可以冒充合法发送方
数据完整性	确认数据在传输中未被篡改	中间人可以修改数据内容
不可否认性	发送方无法抵赖自己发过该数据	发送方可以否认发送行为

1.3 签名与加密：别再搞混了

这是新手最容易混淆的地方。我面试时经常问：「数字签名和加密有什么区别？」能答清楚的人不到一半。

咱们直接上对比表：

对比维度	数字签名	加密
核心目的	证明身份 + 防篡改	保证机密性（防偷看）
使用密钥	私钥签名，公钥验签	公钥加密，私钥解密
密钥关系	签名者持有私钥，验证者持有公钥	加密者持有公钥，解密者持有私钥
输出结果	签名（附加在原文后）	密文（替换原文）
能否还原原文	不能（签名不是加密原文）	能（解密后还原原文）
典型算法	RSA-PSS, ECDSA, EdDSA	RSA-OAEP, ECIES, AES-GCM

你看，签名和加密用的密钥方向正好相反。签名是「私钥签名、公钥验签」，加密是「公钥加密、私钥解密」。这个方向一旦搞反，调试时就会遇到各种莫名其妙的错误。

1.4 一个常见的误解：「签名就是加密的哈希」

很多人说：「签名不就是对哈希值加密吗？」

嗯，从操作上看确实有点像。但严格来说，现代签名算法（比如 RSA-PSS、ECDSA）并不是简单的「加密哈希」。它们有自己特定的填充方案和数学结构。

举个例子：RSA-PSS 签名在签名前会做复杂的填充，包括加盐值、哈希链等。如果你直接用 RSA 加密函数去处理哈希值，得到的「签名」在标准验签工具下是通不过的。

我建议你记住一句话：签名算法是独立的密码原语，不是加密算法的附属品。调试时如果发现签名验签不通过，先检查你用的是不是标准的签名接口，而不是自己拼凑的「加密哈希」方案。

1.5 本章小结

咱们把这一章的核心点捋一捋：

• 数字签名 = 私钥对数据摘要的签名，相当于电子手印。
• 验签 = 用公钥验证签名，确保数据来源可信且未被篡改。
• 签名 ≠ 加密：签名用私钥，加密用公钥；签名不隐藏原文，加密隐藏原文。
• 不验签的风险：身份冒充、数据篡改、事后抵赖——哪个都够你喝一壶的。