GPG 导入和导出的公钥不匹配

Question

在keyserver.ubuntu.com我查找一个公钥，比如说这个，用作quux foo搜索字符串，当您单击那里的任何超链接（比如说第一个）时，您会得到这个，第一行和最后几行我将在下面展示：

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFWnnlYBEACxP/X6kj+eOQepGtv5MGXKGvyfzrxWjf1MHP6CX+l932TtoC/a
mraSF4f4HI3i0p9BCbPCTxJSA5AkT0CgF34s3IqpR+vYF8wsdj3yvfvckN/2l72d
.
.
.
koiZ01CsJs1RzL1cNPx6MofudBq4tTwjtzx0hWYmkZqwGas8EQ+BDHHYOmDmflfK
6ovi3RGi9Js0vgSSDeFFVUO5YuIg0KHD
=mPX8
-----END PGP PUBLIC KEY BLOCK-----

我使用GnuPG，并执行以下操作：

$ gpg --keyserver keyserver.ubuntu.com --search-keys quux foo

结果如下：

gpg: data source: http://162.213.33.9:11371
(1) Anand Karthik (foo bar baz quux) <anandkarthikt@gmail.com>
      4096 bit RSA key 1D94CC5AB7E8F5C6, created: 2015-07-16
Keys 1-1 of 1 for "quux foo".  Enter number(s), N)ext, or Q)uit > 

这里我输入1，显示如下：

gpg: key 1D94CC5AB7E8F5C6: public key "Anand Karthik (foo bar baz quux) <anandkarthikt@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

这样做gpg -k表明密钥确实已成功导入：

.
.
pub   rsa4096 2015-07-16 [SC]
      B2219477E4935FF8929BEF311D94CC5AB7E8F5C6
uid           [ unknown] Anand Karthik (foo bar baz quux) <anandkarthikt@gmail.com>
sub   rsa4096 2015-07-16 [E]

现在我复制我认为是哈希值 ( B2219477E4935FF8929BEF311D94CC5AB7E8F5C6) 的内容，并尝试将密钥导出为文本文件：

$ gpg --export -a B2219477E4935FF8929BEF311D94CC5AB7E8F5C6

命令输出（中间缩短）：

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFWnnlYBEACxP/X6kj+eOQepGtv5MGXKGvyfzrxWjf1MHP6CX+l932TtoC/a
mraSF4f4HI3i0p9BCbPCTxJSA5AkT0CgF34s3IqpR+vYF8wsdj3yvfvckN/2l72d
.
.
.
koiZ01CsJs1RzL1cNPx6MofudBq4tTwjtzx0hWYmkZqwGas8EQ+BDHHYOmDmflfK
6ovi3RGi9Js0vgSSDeFFVUO5YuIg0KHD
=Pj2c
-----END PGP PUBLIC KEY BLOCK-----

这看起来不像网站上的密钥。我究竟做错了什么？

Answer 1

它实际上看起来很像网站 \xe2\x80\x93 上的密钥，只是开头和中间的几个字符不同¹。事实上，如果您使用去掉 Base64 编码gpg --dearmor，然后对结果文件进行二进制比较，您只会看到这些差异：

\n

$ radiff2 orig.gpg new.gpg \n0x00000000 c6c14d => 99020d 0x00000000\n0x00000210 cd     => b4     0x00000210\n0x0000024c c2c177 => 890237 0x0000024c\n0x00000486 cec14d => b9020d 0x00000486\n0x00000696 c2c15f => 89021f 0x00000696\n

\n

有一个模式。OpenPGP 消息是基于数据包的，通过gpg --list-packets或pgpdump将揭示“密钥”由链接在一起的多个组件组成：“主”密钥对的公钥数据包，后跟用户 ID（每个后跟签名），然后后跟子密钥（每个子密钥后又跟有签名）。这把钥匙相当标准，有五个数据包......

\n

public key packet: RSA-4096 (key ID 0x1D94CC5AB7E8F5C6)\n \xe2\x94\x9c\xe2\x94\x80 user ID packet: Anand Karthik (foo bar baz quux) <...>\n \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x80signature packet: (made by 0x1D94CC5AB7E8F5C6)\n \xe2\x94\x94\xe2\x94\x80 public subkey packet: RSA-4096 (key ID 0x24E3E92111823AE6)\n     \xe2\x94\x94\xe2\x94\x80signature packet: (made by 0x1D94CC5AB7E8F5C6)\n

\n

...并且有五个看起来相似的差异，这强烈表明它们对应于数据包标头。此外，仔细观察输出gpg --list-packet，它实际上恰好显示了数据包标头的差异：

\n

\n$ diff -u <(gpg --list-packets < orig.gpg) <(gpg --list-packets < new.gpg)\n--- /dev/fd/63 2020-12-16 01: 35:38.888515388 +0200\n+++ /dev/fd/62 2020-12-16 01:35:38.888515388 +0200\n@@ -1,12 +1,12 @@\n -# off=0 ctb=c6 标签=6 hlen=3 plen=525 new-ctb\n+# off=0 ctb=99 tag=6 hlen=3 plen=525 \n :公钥数据包:\n 版本 4，算法 1，创建 1437048406，过期 0\ n pkey[0]: [4096 位]\n pkey[1]: [17 位]\n keyid: 1D94CC5AB7E8F5C6\n - # off=528 ctb=cd tag=13 hlen=2 plen=58 new-ctb\n+ # off=528 ctb=b4 tag=13 hlen=2 plen=58 \n :用户 ID 数据包: "Anand Karthik (foo bar baz quux) "\n -# off=588 ctb=c2 tag=2 hlen=3 plen =567 new-ctb\n+# off=588 ctb=89 tag=2 hlen=3 plen=567 \n :签名包: algo 1, keyid 1D94CC5AB7E8F5C6\n 版本 4, 创建 1437048406, md5len 0, sigclass 0x13\n( ...)\n

\n

OpenPGP 使用的二进制编码不像 X.509 中使用的 DER 那样严格，因此可以有不止一种方法可以完成相同的操作。查看RFC 4880（OpenPGP 规范），第一个字节（gpg 指示为“ctb=”）是一个标记字节，指示数据包格式，其本身有两个版本 \xe2\x80\x93，这导致主要不同之处：

\n

\n
• 原始密钥的数据包标签中设置了第 6 位，表明 Hockeypuck 密钥服务器软件写入了新格式标签字节（GnuPG 将其表示为“new-ctb”）。
\n
• 导出的密钥的第 6 位被清除，表明 GnuPG 写入旧格式标记字节。
\n

\n

“新”格式允许使用 6 位表示实际类型（允许 64 种不同的数据包类型），而“旧”格式仅保留 4 位（限制为 16 种数据包类型）。查看源代码，GnuPG 似乎只要可以摆脱它，就会生成旧格式标签，仅将 \xe2\x89\xa516 类型切换到新格式，从而最大限度地提高与 RFC 4880 之前的旧 PGP 实现的兼容性。

\n

这两个标签版本对“数据包长度”字段的编码也不同，这就是导致每个标头的字节 2\xe2\x80\x933 存在差异的原因。

\n\n

¹请注意，PGP 装甲消息的最后一行（以 开头的=）是用于检测损坏的校验和（24 位 CRC），因此即使只有一个字节发生变化，它自然也会有很大不同。此校验和是 ASCII-armor 格式 \xe2\x80\x93 的一部分，它不是编码数据的一部分，并且不会显示在二进制差异中。

\n