模块七 · 网络安全
端点鉴别与安全电子邮件
上一章解决了"数据没被改"。但还有一个更基本的问题：你怎么知道对面真的是它声称的那个人？ 这一章讲鉴别（authentication），以及把这些技术用起来的一个真实场景 —— 电子邮件。
本章要解决的问题：上一章解决了"数据没被改"。但还有一个更基本的问题：你怎么知道对面真的是它声称的那个人？ 这一章讲鉴别（authentication），以及把这些技术用起来的一个真实场景 —— 电子邮件。
本章的证据来源：概念讲法参考教材§8.4–8.5，纸书417–423页（PDF436–442页），具体出处见章末。旧稿的命令与数值属于历史转述，相关附件未随当前项目提供，本次没有重新采集或运行原实验；模型计算、协议规则与观察不能互相替代。
先从一个例子理解概念
你收到一条自称来自朋友的消息，还可能是别人重放的旧消息。内容能解密或签名能通过之后，仍要问验证了谁、是否属于这一次通信。
端点鉴别与消息认证
端点鉴别验证正在通信的对方身份；消息认证验证消息与可信持钥者的关系。两者相关，但不能把旧消息验证成功当作对方此刻正在参与。
新鲜性与重放
新鲜性表示消息与当前交互相关；重放是再次发送截获的有效旧消息。随机挑战等机制可在明确协议条件下帮助判断，但要验证它与响应的绑定。
鉴别要防的三件事
"证明你是你"听起来简单，但要做到需要防住三种攻击：
| 要防什么 | 攻击的样子 |
|---|---|
| 重放 | 攻击者录下你上次的认证信息，原样重发一遍 |
| 冒充 | 攻击者伪装成合法方 |
| 中间人 | 攻击者夹在双方中间，向两边分别冒充对方 |
先看它有多难。 假设最简单的方案是"报口令"：
客户端：我的口令是 hunter2
服务器：对，你通过了这个方案的问题一眼可见：
- 口令在网络上明文传输 → 被偷看就完了
- 就算加密了，攻击者录下来重放一次也能通过 → 重放攻击
用随机数（nonce）防重放
解决办法很直接：让每次认证的"题目"都不一样。
① 客户端说：我是 Alice
② 服务器回一个【随机数】nonce（每次都不同，用完就丢）
③ 客户端用密钥和这个 nonce 算出一个值发回去
④ 服务器用同样的密钥和 nonce 验算关键在于 nonce 是随机的、一次性的：
重放攻击：攻击者录下第 ③ 步的应答，下次想重发
→ 但服务器这次给的 nonce 不同了
→ 旧应答算出来的值对不上 → 失败这就是"挑战应答"（challenge-response）：服务器出一道新题，只有知道密钥的人能算对答案，而答案不能复用。
为什么不在第 ③ 步直接发密钥？ 因为那样密钥就在网络上传输了。发"用密钥算出的结果"，而不是密钥本身 —— 服务器可以验算，但偷看的人拿不到密钥。
一个必须避免的错误：只鉴别一方
这里有一个很隐蔽的陷阱。
设想一个"只有客户端向服务器证明身份"的协议（比如经典的"三次握手式"口令鉴别）。验证方是服务器，客户端不验证服务器。
问题在于：客户端不知道自己连的是不是真服务器。
攻击者 M 夹在中间：
Alice ──→ M ──→ 真服务器 （M 转发 Alice 的应答，通过验证）
Alice ←── M （M 现在可以冒充服务器和 Alice 说话）因为 Alice 从来不验证对方，M 就可以完全接管这段对话 —— 这就是中间人攻击。
数字签名在鉴别里的作用
上一章讲的数字签名正好是天然的鉴别工具：
服务器把公钥给你
服务器对某个数据签名
你用公钥验证 → 只有持有私钥的服务器能生成这个签名
→ 你确认了"对方确实持有那把私钥"这比口令方案强的地方在于：
| 口令/共享密钥 | 数字签名 | |
|---|---|---|
| 服务器要不要存秘密 | 要（存口令或密钥的散列） | 不用（只存公钥） |
| 服务器被攻破的后果 | 攻击者拿到所有用户的口令 | 拿不到私钥就伪造不了 |
| 能否向第三方证明 | 不能 | 能 |
所以现代协议（TLS）用证书 + 签名来做服务器鉴别（下一章细讲）。
安全电子邮件：一个真实的综合场景
电子邮件是这些技术最早、最广泛应用的地方之一，因为它天生面临一个尴尬处境：
所以邮件安全需要解决四件事：
| 需求 | 用什么 |
|---|---|
| 保密（服务器和中间节点看不到内容） | 加密 |
| 完整性（内容没被改） | 散列 + 签名 |
发件人真实（From 不是伪造的） | 数字签名 |
| 不可否认（发件人不能抵赖） | 数字签名 |
PGP 的思路就是把这几件事组合起来：
发件人：
① 对邮件正文算散列
② 用自己的【私钥】对散列签名 → 提供完整性与不可否认
③ 生成一个一次性的对称密钥
④ 用对称密钥加密（正文 + 签名） → 提供保密
⑤ 用收件人的【公钥】加密那个对称密钥
⑥ 把两部分一起发出去
收件人：
① 用自己的【私钥】解开对称密钥
② 用对称密钥解开正文和签名
③ 用发件人的【公钥】验证签名注意这个流程把前面几章的东西全用上了：
- 对称加密加密正文（因为快，且没有长度限制）
- 公钥加密只加密那个小密钥（因为慢且长度受限）
- 散列 + 签名保证完整性和来源
- 公钥分发依赖证书或事先交换的公钥
这和 HTTPS 握手的结构是同一套思路 —— 只不过 HTTPS 是自动的、面向连接，PGP 是手动的、面向消息。
本机的实测限制
本教程没法在本机演示邮件的加密与签名，原因是前面已经实测过的两条：
| 限制 | 实测结果 | 出处 |
|---|---|---|
| SMTP 会话走不通 | TCP 连上了但读不到 banner（代理假可达） | 《电子邮件与 SMTP》 |
| DNS TXT 查询失败 | 返回 DNS server failure，SPF/DMARC 无法验证 | 同上 |
所以本章的 PGP 流程属于标准描述，不是本机验证的结果。
常见误解
误解一：「加密了就等于鉴别了」
不是。 加密保证"别人看不到"，但不告诉你对方是谁。你可以和一个冒充者建立加密连接 —— 他看到你的所有数据。 TLS 里这两件事是分开做的：加密用协商出的密钥，鉴别用证书和签名。
误解二：「用随机数 nonce 是多余的，口令对就行了」
不多余，它是防重放的关键。 没有 nonce 时，攻击者录下你上次的应答重发一遍就能通过（他甚至不需要知道口令）。nonce 让每次的题目都不同，旧答案作废。
误解三：「只要一方鉴别成功，连接就安全了」
不对，鉴别必须双向。 如果只有客户端向服务器证明身份，服务器不向客户端证明，那中间人可以夹在中间：对服务器冒充客户端、对客户端冒充服务器 —— 而客户端毫无察觉。
误解四：「邮件加密了就安全了」
还要看发件人身份。 SMTP 没有任何发件人认证机制，From 可以随便填。所以即使内容加密，你也不知道发件人是不是它声称的那个人 —— 除非有数字签名（或 SPF/DKIM/DMARC 这类基于 DNS 的机制）。 而这几个机制本机都验证不了（TXT 查询失败）。
误解五：「PGP 用公钥加密了整个邮件」
没有。 它只对那个一次性的对称密钥做公钥加密，正文是用对称密钥加密的。 原因是混合加密让不同工具承担不同任务：用对称机制保护邮件内容，用公钥方案保护所需的密钥材料。公钥运算成本和可处理长度依算法、参数与编码而定；旧稿的RSA-OAEP示例和速度比不能推广为所有公钥算法的固定上限，也不是上一章的签名实验。
本章小结
| 结论 | 类型 |
|---|---|
| 鉴别要防重放、冒充、中间人三类攻击 | 标准 |
| 明文口令方案的问题：会被偷看，且可被重放 | 标准 |
| nonce（一次性随机数）让每次认证题目不同，从而防重放 | 标准 |
| 挑战应答发送的是"用密钥算出的结果"，而非密钥本身 | 标准 |
| 只鉴别一方的协议会被中间人攻破，鉴别必须双向 | 标准 |
| 数字签名是天然的鉴别工具：验证方无需持有任何秘密 | 标准 |
| 邮件安全需要保密、完整性、发件人真实、不可否认四项 | 标准 |
| PGP 用对称加密正文、公钥加密对称密钥、签名保证来源 | 标准 |
| PGP 的结构与 TLS 握手思路一致（都是混合加密 + 签名） | 推理 |
| 实测：本机 SMTP 会话收不到 banner，DNS TXT 查询失败 | 实测限制 |
| 因此本章的 PGP 与鉴别流程属标准描述，非本机验证 | 实测限制 |
自测题
7 题 · 先自己答，再展开对照
鉴别要防哪三类攻击？
重放（录下你上次的认证信息重发）、冒充（伪装成合法方）、中间人（夹在双方之间，向两边分别冒充对方）。nonce 是怎么防重放的？为什么挑战应答里不发密钥本身？
因为 nonce 是随机的、一次性的。 攻击者即使录下你上次的应答，服务器这次给的题目不同了，旧答案算出来的值对不上 —— 重放失败。
不发密钥本身的原因：那样密钥就在网络上传输了，被偷看就彻底泄露。发"用密钥算出的结果"，服务器能验算，但偷看的人拿不到密钥。如果只有客户端向服务器证明身份，会有什么问题？
会被中间人攻破。 因为客户端从不验证对方，攻击者可以夹在中间：对服务器方向冒充客户端（转发客户端的应答，通过验证），对客户端方向冒充服务器（接管后续对话）。
所以鉴别必须双向。用数字签名做鉴别，比用共享密钥做鉴别强在哪两点？
① 服务器不需要保存任何秘密（只存公钥），被攻破的后果小得多；② 具备不可否认性 —— 只有私钥持有者能生成签名，所以能向第三方证明"这条消息确实是它发的"。
（共享密钥方案里验证方自己也知道密钥，所以他也能伪造，第三方无法分辨。）PGP 加密一封邮件时，为什么正文不用公钥加密？
混合加密把邮件内容交给对称机制，把所需密钥材料交给公钥方案保护。 公钥方案的开销和长度限制依具体算法与参数而异，不能把旧稿一次RSA-OAEP示例或速度比说成所有方案的固定性质。
所以只用公钥加密那个一次性的对称密钥，正文用对称密钥加密。这就是"混合加密"。邮件加密了，是否就能确定发件人是谁？
不能。 SMTP 协议没有任何发件人认证机制，From字段可以随便填。加密只保证"内容没被偷看"，不告诉你发件人是谁。
要判断发件人真实性，需要数字签名（PGP）或 SPF/DKIM/DMARC 这类基于 DNS 的机制。而这几个机制本机都验证不了（TXT 查询返回DNS server failure）。本机为什么没法演示邮件的加密与签名？
因为两条本机实测的限制：① SMTP 会话走不通 —— TCP 端口显示"可达"，但真做协议对话时连 banner 都读不到（代理在本地代替握手）；② DNS TXT 查询直接失败，所以 SPF/DMARC 也无法验证。
所以本章的 PGP 流程属于标准描述，不是本机验证的结果。
参考资料与适用范围
- RFC 8017 §7.1：RSA-OAEP输入长度取决于模数和散列长度
- 《计算机网络：自顶向下方法（原书第8版）》§8.4–8.5，纸书417–423页（PDF436–442页）：本章概念与机制的对应教学章节，引用时需保留模型与版本条件。
- 教材作者配套教学资源入口：网站目前显示的教材版本与用户提供的第8版可能不同，页码以本章列出的中文第8版为准。
修订核对日期：2026-10-13。本次补充概念入口与教材出处；旧稿的具体数值为历史观察，未重新实测。相关脚本和完整日志未随当前项目提供，不能仅凭转述断言实验已复核，也不据此断言数据造假。