2. 签名验签原理：非对称密钥体系与哈希算法

各位同学，今天我们来聊聊签名验签最核心的基石——非对称密钥体系。说白了，这就是用一对钥匙来解决信任问题：一把公开，一把私密。我在项目中见过太多因为原理理解不透彻导致的性能事故，所以我建议，咱们先把根扎稳。

2.1 非对称密钥体系：公钥与私钥

对称加密只有一个密钥，你知我知，但怎么安全地把密钥交给对方？这个问题困扰了密码学很多年。直到非对称加密出现，问题迎刃而解。

• 私钥(Private Key)：必须保密，只有自己持有。用于签名或解密。
• 公钥(Public Key)：可以公开分发，谁都可以拿到。用于验签或加密。

数学上，公私钥是成对生成的。从一个方向（私钥→公钥）很容易，反过来（公钥→私钥）在计算上几乎不可能。嗯，这里要注意，不同的算法实现这个“单向性”的数学原理完全不同，直接决定了它们的性能和安全性。

2.2 主流算法对比：RSA、ECDSA、Ed25519

我个人习惯把这三类算法看成三把不同材质的锁。它们各有各的脾气，选错了，HSM性能可能直接腰斩。

RSA：成名最早，应用最广。它的验签速度非常快，因为公钥指数通常选65537这种很小的数。但签名就很慢，尤其密钥一长，CPU直接拉满。

ECDSA：在同等安全强度下，密钥比RSA短得多。比如256位ECDSA和3072位RSA安全性相当。但ECDSA有一个痛点：签名过程中需要生成高质量的随机数。随机数出问题，私钥就可能泄露。索尼PS3当年就是栽在这个坑里。

Ed25519：这是现代签名算法的翘楚。速度快，签名短，而且内部做了防侧信道攻击设计。我记得第一次在生产环境上线Ed25519时，HSM的TPS直接翻了一倍。它的验签过程是确定性的，不需要随机数，天生就比ECDSA安全一些。

2.3 数字签名与验证流程

你想想看，签名的本质是什么？是“绑定”：把签名者的身份和一段数据绑定在一起。怎么绑？靠的是私钥的独占性和哈希算法的唯一性。

签名流程(发送方操作)：

1. 计算摘要：对原始数据进行哈希运算，得到一段固定长度的摘要。
2. 签名：用私钥对摘要进行加密运算，生成签名值。
3. 发送：将原始数据 + 签名值一起发给接收方。

验签流程(接收方操作)：

1. 计算摘要：对接收到的原始数据进行同样的哈希运算，得到摘要。
2. 解密对比：用公钥对签名值进行解密，得到另一个摘要。
3. 判断：对比两个摘要。如果一致，验签通过；否则，数据被篡改或签名者身份伪造。

2.4 哈希算法的作用：SHA-256、SHA-384

哈希算法在签名流程中扮演了“桥梁”的角色。它把任意长度的数据，压缩成一个固定长度的摘要。没有它，非对称签名几乎不可用。

• 抗碰撞性：很难找到两个不同的数据，它们哈希值相同。这是安全签名的前提。
• 单向性：从数据到摘要很容易，从摘要反推数据几乎不可能。
• 定长输出：SHA-256输出256位(32字节)，SHA-384输出384位(48字节)。

为什么要区分SHA-256和SHA-384？我个人经验是这样的：如果你的密钥强度高，比如RSA-4096或者P-384曲线，建议配SHA-384。为什么？因为密钥能提供的安全强度刚好和哈希摘要的安全强度匹配，不会出现“短板效应”。

2.5 核心逻辑框架图

我把整个非对称签名验签的核心流程整理成一张图。你可以把它当作一个思维导图，或者挂在工位旁边的速查表。

图中左边是签名方，右边是验签方。两者做的哈希运算是完全一样的。如果两边摘要对不上，要么是数据在传输过程中被动了手脚，要么是签名方根本不是公钥对应的那个人。实际工作中，我们重点监控的就是这个“摘要对比”环节。