6.1.3 数字签名与信息摘要
本课核心知识点整理
签名在网络里解决什么
现实中的签名能表达“这件事是我确认的”。网络中的数字签名也类似:它要证明消息确实来自发送者,并且发送者事后不能否认。
数字签名关注的不是把内容藏起来,而是:
| 目标 | 数字签名如何支持 |
|---|---|
| 身份认证 | 只有发送者有自己的私钥,能生成对应签名 |
| 完整性 | 消息被篡改后摘要会变,验签不通过 |
| 不可否认 | 私钥由发送者独有,发送者难以否认签名 |
为什么先做摘要再签名
非对称运算慢,不适合直接对大段明文签名。于是先用哈希函数从原文生成一个短小、固定长度的信息摘要,再用发送者私钥对摘要签名。
信息摘要的特点:
| 特点 | 含义 |
|---|---|
| 单向性 | 从原文生成摘要容易,从摘要反推原文不可行 |
| 固定长度 | 无论原文多长,摘要长度固定 |
| 敏感性 | 原文微小变化会导致摘要明显变化 |
| 完整性校验 | 比较摘要可发现数据是否被篡改 |
常见摘要算法:
| 算法 | 考试常见长度 |
|---|---|
| MD5 | 128 位 |
| SHA | 160 位 |
实际工程中 SHA 家族已有更多更长的版本,但软件设计师传统题里常按 MD5 128 位、SHA 160 位考。
数字签名流程
发送方:
text
原文 -> 哈希函数 -> 摘要 -> 用发送者私钥签名 -> 签名摘要接收方:
text
收到原文和签名摘要
-> 用发送者公钥验证签名,得到摘要1
-> 对收到的原文重新哈希,得到摘要2
-> 比较摘要1和摘要2如果两者一致,说明消息未被篡改,并且签名确实与发送者公钥匹配。
为什么签名不是保密
发送者用自己的私钥处理摘要,接收者用发送者公钥验证。因为公钥是公开的,任何人都能验证签名,所以签名本身不提供保密性。它提供的是身份认证、完整性和不可否认。
若要保密,还需要加密正文,通常使用对称加密或数字信封。
例题
单选
数字签名生成时通常使用:
单选
信息摘要的主要用途是:
单选
下列属于信息摘要算法的是:
自查要点
- 为什么数字签名通常不直接对原文签名?
- 摘要的单向性、固定长度分别是什么意思?
- 数字签名用谁的私钥生成,用谁的公钥验证?
- 为什么签名能支持不可否认,却不能提供保密性?