从 Signing Party 到年轻人的第一次 Revoke

前情提要

在开源软件供应链2020峰会的邀请下，以及TUNA的派遣下，我与来自UOJ的两位同学billchenchina以及Ciel面基，并举行了一次奇怪的signing party。

举办 Signing Party

首先我们交换了公钥，对照了公钥指纹。

然后我们验证了ID，无非是常规的身份证（如果 UID 中有实名的话），学生卡，以及其他ID。

以下步骤可以非面对面进行。

然后我们商议决定，除了要验证邮箱，我们还需要验证私钥的持有性，即验证各个私钥的功能性。

于是我们采取了以下握手方案：

1. A 向 B 发送用 A 签名用 B 加密的「信息」，「信息」中包含发方与接收方邮箱，以及一些字符。（B 收到后即可验证 A 的 S 能力与邮箱的持有性）
2. B 将 「信息」附在其邮件中，以「—BEGIN RAW MESSAGE—」包裹，并增加B相关的一些字符，形成「信息二」，签名并加密，发送给 A 。（A 收到后可验证 B 的S，E以及邮箱的持有）
3. A 将 「信息二」附在邮件中，附上对 B 公钥的签名，并将加上字符形成「信息三」，签名加密后发给 B。（B 收到后可验证 A 的E，C，并收获签名）
4. B 将 「信息三」附在邮件中，附上对 A 公钥的签名，形成「信息四」，签名加密后发给 A。（A 收到后可验证B的C，并收获签名）

上述方案对于一个 UID ，一组ES密钥的用户较为友好，对于多个 UID，多组ES密钥的用户，需要重复其中一些步骤才能进行下一步。

对于 A 密钥，我们并未验证，不过可以给一个中心服务器，上传各个人的公钥，只要验证其能登录上去，即可。

按签名的性质来说，我们只需要验证UID，也就是验证 ID 与邮箱与指纹即可完成 Signing Party 的前半段，后半段只需要交换签名。我们这次进行了一定的加强。

出锅

在第三步时，我应该对 A 的公钥进行签名，然后发现我找不到我的主私钥了。

我导出的私钥显示为（使用 pgpdump ）

Old: Secret Key Packet(tag 5)(277 bytes)
        Ver 4 - new
        Public key creation time - Wed May  1 17:54:39 CST 2019
        Pub alg - RSA Encrypt or Sign(pub 1)
        RSA n(2048 bits) - ...
        RSA e(17 bits) - ...
        Sym alg - Plaintext or unencrypted data(sym 0)
        GnuPG gnu-dummy (s2k 1001)

注意到，其只有 n 与 e，而没有其余参数，例如

Encrypted RSA d
Encrypted RSA p
Encrypted RSA q
Encrypted RSA u

回溯历史，发现当时我导出「主」私钥的参数为

9603  gpg --armor --export-secret-subkeys '23470D4FD461AA84!'
9610  gpg --delete-secret-keys 23470D4FD461AA84

其中 23470D4FD461AA84 为主钥的keyid，但由于命令是 export-secret-subkeys，在此keyid下找不到相应子密钥，所以导出来的私钥是空的，只有公钥与UID与一些签名。

所以在导出时应该注意！并查验导出私有钥匙的文件！可以通过 pgpdump，gpg --show-keys file，gpg --list-packets file 来查验。

Revoke

找不到私钥，但有预先生成的吊销证书，我于是将其挂载在公钥上后上传，成功吊销。

年轻人的第一次 Revoke。

新公钥

目前新公钥在 https://blog.zenithal.me/key 中，其指纹为 1127F188280AE3123619332987E17EEF9B18B6C9。

由于进行过 UID 验证，重启握手后完成了 Signing Party。