惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
DataBreaches.Net
N
Netflix TechBlog - Medium
P
Proofpoint News Feed
D
Docker
J
Java Code Geeks
L
LangChain Blog
Microsoft Security Blog
Microsoft Security Blog
The GitHub Blog
The GitHub Blog
I
InfoQ
Stack Overflow Blog
Stack Overflow Blog
云风的 BLOG
云风的 BLOG
Engineering at Meta
Engineering at Meta
MongoDB | Blog
MongoDB | Blog
月光博客
月光博客
T
Tailwind CSS Blog
M
MIT News - Artificial intelligence
Blog — PlanetScale
Blog — PlanetScale
Google DeepMind News
Google DeepMind News
腾讯CDC
罗磊的独立博客
U
Unit 42
爱范儿
爱范儿
Vercel News
Vercel News
MyScale Blog
MyScale Blog

GoodBoyboy 's Blog|惬意小屋-点滴记忆

嘉立创牛逼,免费的总裁卡到了 时间过得蛮快的 撒谎撒多了,别把自己都骗了 Fedora LUKS2设置TPM2+PIN与FIDO2解锁 解决天选三AX210在fedora 44/Ubuntu 26.04上睡眠后恢复失败的问题 新的博客评论系统正式启动 博客评论数据已全部完成迁移 评论系统即将更换 在WSL中使用Canokey智能卡进行Git Commit签名 博客评论系统的一些设计 打算做个博客评论系统 开了一个游泳馆的月卡 今天游泳累炸了 回家吵的第一场架 新设计了一个Astro主题 Cap,一个基于PoW的自托管验证码系统 公益服务迁移通知 一种基于argon2id算法与shamir算法的内存PoW(工作量证明)解密游戏 记忆里的屋子(一) Ubuntu 26.04 Btrfs+LUKS2安装 主域名服务不稳定通知 腾讯元宝客户端实习二面凉经 腾讯元宝客户端实习一面面经 对越来越多AI博文的看法 GoodBoyboy Blog、Talk联动成功 只有失去了才会懂得珍惜,但幸好我还没有失去 滴滴Android客户端一面凉经 GoodBoyboy 's Talk上线! Easy Drop——一个基于Gin开发的高性能、轻量级说说平台 Perfect Pic —— 一个基于 Gin 开发的高性能、轻量级图床
OpenPGP邮件加密——关于测试邮件握手的思考
GoodBoyboy · 2025-11-26 · via GoodBoyboy 's Blog|惬意小屋-点滴记忆

前言

和网友互换了OpenPGP公钥,然后测试了下加密邮件,然后有了下面的思考:

如何“规范”的进行加密邮件测试?

结论

这里先给出我的结论:进行三轮握手。

Tips:以上结论用于子密钥分担不同职责的情况。

原因

OpenPGP密钥有四个职能:认证、加密、验证、签名。

一般来说,主密钥担任认证职责,三个子密钥分别担任加密、验证、签名职责。

目前市面上的OpenPGP 物理安全密钥会有三个插槽,分别对应存储三个子密钥,主密钥则离线冷存储。

当两个人互换OpenPGP公钥后,准备发送测试邮件测试邮件加密功能:

这里使用A和B区分用户

第一次握手:A向B(也可以是B向A)发测试邮件(发起握手请求)

A的邮件客户端会使用B的OpenPGP公钥中的“加密”子密钥的公钥,对邮件内容进行加密,并使用自己的OpenPGP公钥中的“签名”子密钥对邮件进行签名。

B在收到邮件后,邮件客户端会使用自己的OpenPGP公钥中的“加密”子密钥的私钥对邮件内容进行解密,并且使用A的OpenPGP公钥中的“签名”子密钥的公钥对签名进行检查,如果检查通过,那么代表:

A什么都还不知道(B还未作出回应)

B知道了自己的OpenPGP公钥中的“加密”子密钥功能正常(邮件客户端正常解密邮件),A的OpenPGP公钥中的“签名”子密钥功能正常(邮件客户端正确显示邮件签名)

第二次握手:B向A发送测试邮件

这次和第一次流程是反过来的

B的邮件客户端会使用A的OpenPGP公钥中的“加密”子密钥的公钥,对邮件内容进行加密,并使用自己的OpenPGP公钥中的“签名”子密钥对邮件进行签名。

A在收到邮件后,邮件客户端会使用自己的OpenPGP公钥中的“加密”子密钥的私钥对邮件内容进行解密,并且使用B的OpenPGP公钥中的“签名”子密钥的公钥对签名进行检查,如果检查通过,那么代表:

A知道了自己的OpenPGP公钥中的“加密”子密钥功能正常(邮件客户端正常解密邮件),B的OpenPGP公钥中的“签名”子密钥功能正常(邮件客户端正确显示邮件签名),自己的OpenPGP公钥中的“签名”子密钥功能正常(否则B也不会回复测试成功),B的OpenPGP公钥中的“加密”子密钥功能正常(否则B也不会回复测试成功)。

B还是仅知道自己的OpenPGP公钥中的“加密”子密钥功能正常,A的OpenPGP公钥中的“签名”子密钥功能正常

第三次握手:A向B发送完成测试邮件

同样是B在收到邮件后,邮件客户端会使用自己的OpenPGP公钥中的“加密”子密钥的私钥对邮件内容进行解密,并且使用A的OpenPGP公钥中的“签名”子密钥的公钥对签名进行检查,如果检查通过,那么代表:

A已知全部

B知道了自己的OpenPGP公钥中的“加密”子密钥功能正常(第一轮握手已知),A的OpenPGP公钥中的“签名”子密钥功能正常(第一轮握手已知),自己的OpenPGP公钥中的“签名”子密钥功能正常(不然A也不会回复测试成功),A的OpenPGP公钥中的“加密”子密钥功能正常(不然A也不会回复测试成功)。

整理成表格如下:

轮数 A B
第一轮握手A->B A什么都还不知道 B的“加密”子密钥功能正常、A的“签名”子密钥功能正常
第二轮握手B->A A的“加密”子密钥功能正常、B的“签名”子密钥功能正常、A的“签名”子密钥功能正常、B的“加密”子密钥功能正常 B的“加密”子密钥功能正常、A的“签名”子密钥功能正常
第三轮握手A->B A的“加密”子密钥功能正常、B的“签名”子密钥功能正常、A的“签名”子密钥功能正常、B的“加密”子密钥功能正常 B的“加密”子密钥功能正常、A的“签名”子密钥功能正常、B的“签名”子密钥功能正常、A的“加密”子密钥功能正常

整理成mermaid如下:

sequenceDiagram
    autonumber
    participant A
    participant B

    Note over A,B: 握手过程开始

    %% 第一轮
    rect rgb(240, 248, 255)
    Note left of A: 状态: A什么都还不知道
    A->>B: 第一轮握手 (A -> B)
    Note right of B: 状态: <br/>1. A的“签名”子密钥功能正常<br/>2. B的“加密”子密钥功能正常
    end

    %% 第二轮
    rect rgb(255, 250, 240)
    B->>A: 第二轮握手 (B -> A)<br/>(隐含B的1、2点状态)
    Note left of A: 状态: <br/>1. A的“加密”子密钥功能正常<br/>2. B的“签名”子密钥功能正常<br/>3. A的“签名”子密钥功能正常<br/>4. B的“加密”子密钥功能正常
    Note right of B: (B维持上一轮状态)
    end

    %% 第三轮
    rect rgb(240, 255, 240)
    A->>B: 第三轮握手 (A -> B)
    Note left of A: (A维持全正常状态)
    Note right of B: 状态: <br/>1. A的“加密”子密钥功能正常<br/>2. B的“签名”子密钥功能正常<br/>3. A的“签名”子密钥功能正常<br/>4. B的“加密”子密钥功能正常
    end

至此,A与B都已知自己和对方的邮件签名和加密功能正常。

后记

怎么感觉像是TCP的三次握手(