☰

跟踪 GPG 密钥

tag-icon • tag-icon ssh encryption gnupg
跟踪 GPG 密钥

运行 GPG 时我看到以下屏幕：

gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa2048/redacted1
     created: 2016-01-22  expires: never       usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/redacted2
     created: 2016-01-22  expires: never       usage: E   
ssb  rsa4096/redacted3
     created: 2022-02-01  expires: 2023-02-01  usage: E   
[ultimate] (1). Daniël van den Berg <[email protected]>
[ultimate] (2)  Daniël van den Berg <[email protected]>

现在我知道我刚刚生成了 redacted3，因为我刚刚生成了一个 rsa4096 密钥，用作访问我的 git 服务器的 ssh 密钥。但是……我又生成了 redacted2 干什么？（我记得，但半年后就记不清了。或者说，我自己知道，3 天后就记不清了。）

我可以在子项中添加注释来帮助我区分它们吗？ 建议的区分方法是什么？ （带有 ID 和注释的 csv？）

答案1

现在我知道我刚刚生成了 redacted3，因为我刚刚生成了一个 rsa4096 密钥作为访问我的 git 服务器的 ssh 密钥。

不太可能起作用——它有E使用标志，这意味着它是一个仅用于加密的密钥，不能用于身份验证（这需要签名，但在 GnuPG 中有一个专用的A使用标志）。如果您为 SSH 访问生成了它，请将其删除，然后使用正确的使用选择重新执行此操作。

但是……我又生成了 redacted2 干什么？（我记得，但半年后就记不清了。或者说，我自己也记不清了，3 天后就记不清了。）

它是与 redacted1 一起自动生成的。它也有E使用标志，这意味着它是一个加密子密钥——GnuPG 会自动创建第一个子密钥，因为主密钥 (redacted1) 始终是仅签名密钥。您不需要专门为您的子密钥记住这一点——请将其保留在您的一般 GnuPG 笔记中，因为它对于每个 GnuPG 密钥都相同。

（主键必须是有能力的制作签名，因为它可以认证子密钥和 UID。在遥远的过去，它曾经是一个多用途的SCE签名/认证/加密密钥，因为 RSA 可以同时完成这两项工作 - 然而，长期以来一直有人建议不要用同一个 RSA 密钥混合签名和加密。因此，主密钥现在只是SC或有时甚至只是C使用，而加密目的则需要一个单独的子密钥。）

我可以向我的子项添加注释来帮助我区分它们吗？

不，GnuPG 没有该功能。

建议采取什么方法来将它们分开？（带有 ID 和注释的 csv？）

在许多情况下（例如备份存储、工作与个人等），请创建完全独立的密钥，它们自然会具有不同的 UID 标签。例如，我有两个独立的密钥集（一个用于工作，一个用于个人），它们具有不同的电子邮件地址。

但一般来说你不应该有如此多的子密钥，以至于无法追踪它们。例如，对于加密E密钥，只有实际意义才是一一次只能发送一个未撤销、未过期的子密钥 – 因此 GnuPG 已经允许您通过“expires:”字段来区分它们。（如果您无法区分哪个加密子密钥是真正的子密钥，那么向您发送消息的人也无法区分。）

同时，对于签名子密钥，拥有多个给定类型的子密钥也很少有意义，因为它们都与 WoT 中的相同身份和相同“信任”相关联。例如，如果您的主密钥是 RSA SC，则拥有一个 ECDSA 签名子密钥是有意义的，但拥有 3 个 RSA 签名子密钥则没有意义。

我想说的是，身份验证子密钥也是如此；将一个这样的密钥与您的主身份绑定就足够了，如果您碰巧出于特定目的需要更多 SSH 密钥对 - 它们可以放在新的密钥集下，甚至只是保留独立的 OpenSSH 密钥文件，而不是塞进您的 GnuPG 密钥环中。

相关内容