当加密文件发送给合作者时，我看到此消息：
gpg: using subkey XXXX instead of primary key YYYY
为什么会这样？我注意到，当他们向我发送加密文件时，它似乎也是针对我的子密钥而不是我的主密钥进行加密的。对我来说，这似乎不是问题；gpg（1.4.x，macosx）只是处理它并继续前进。但对于他们来说，由于他们的自动化工具设置，这似乎是一个问题，他们要求我确保使用他们的主密钥。
我尝试阅读了一些资料，并且订购了 Michael Lucas 的《GPG & PGP》一书，但我不明白为什么会有这种区别。我有读到用于签名的密钥和用于加密的密钥会有所不同，但我最初认为这是关于公钥和私钥的。
如果这是信任/验证问题，我会进行指纹比对并验证，是的，我信任此密钥。在执行此操作时，我注意到主密钥和子密钥具有不同的“使用”说明：
primary: usage: SCA
subkey: usage: E
“E” 似乎可能表示“加密”。但是，我找不到任何关于此的文档。此外，我的合作者已经使用这些工具和技术好几年了，那么为什么这只会对我造成问题呢？
答案1
更新
虽然下面的原始帖子正确地解释了为什么你可能想要使用单独的加密和签名密钥，但它并没有很好地回答为什么使用子密钥而不是主密钥的问题。Debian Wiki 提供了一个更彻底的答案。
总而言之，您的主密钥就是您的在线身份，您的身份和声誉是通过让其他人亲自签名来保证该密钥是您的而建立起来的。（您可能认为它是您的 Twitter 用户名，而您的声誉是您的 Twitter 关注者，或者您可能反对这种类比，但我希望它能让您了解为什么要保护它。）因此，由于您的主密钥非常重要并且是多年来建立起来的，因此您非常希望保护它。特别是，您不想将其存储在可能被盗或被黑客入侵的计算机上；您希望将您的主密钥离线保存在安全的地方。
当然，这会使主密钥使用起来非常不方便。因此，对于日常操作，您需要使用一个即使被盗用也不会造成太大问题的密钥。这就是发明子密钥的原因。
子密钥仍然是公钥/私钥对，只要只有您拥有私钥，它就是安全的。从加密角度来看，它与您的主密钥一样安全。不同之处在于，您的声誉仅通过您自己的签名（来自您的私钥的签名）与其相关联。使用 Twitter 类比，世界相信您是您的 Twitter 用户名，因为所有关注者都这么说（我知道，事情并不总是这样，但类比很难！），然后建立这种信任后，您就可以更轻松地通过发推文让世界相信您拥有您的 Instagram 用户名，人们会相信您，因为推文来自他们信任的您的帐户。
您仍然希望保证子密钥的安全，但现在即使子密钥被盗用，问题也不会像主密钥被盗用（或者，打个比方，有人劫持了您的 Twitter 帐户）那样严重。现在，您只需签署撤销证书和新子密钥，并将它们发布到您的公钥环上，即可撤销子密钥并颁发新子密钥（例如发推文“嘿，我的 Instagram 用户名变了，不要使用旧的，改用这个”）。这使得将子密钥保存在笔记本电脑上的风险比将主密钥保存在笔记本电脑上的风险更可接受。
总结子密钥将公钥的加密功能与（主）公钥的信任和身份功能分开，使密钥管理变得更加容易。
原始帖子
如果你仔细研究公钥加密的数学细节，你会发现签名和解密实际上是相同的数学运算.因此在幼稚的在实施过程中，可以通过要求某人签名来诱骗其解密消息。
在实践中，有几种方法可以防止这种情况发生。最明显的是，您永远不会对实际消息进行签名，而是对消息的安全哈希进行签名。不太明显的是，但为了更加安全，您使用不同的密钥进行签名和加密。此外，将加密密钥分开保存可以让您将其他可能更重要且绝对不常用的密钥离线保存，并且更安全。您检查过的密钥就是这种情况。顺便说一下，标志的含义是：
- e = 加密/解密（解密您收到的加密消息以供您阅读）
- s = 签名（签名数据。例如文件或发送签名的电子邮件）
- c = 认证（签署另一个密钥，建立信任关系）
- a = 身份验证（使用 PGP 密钥登录 SSH；这是相对较新的用法）
请注意，在所有情况下，“密钥”都表示公钥和私钥对。
如果您的朋友正确设置了所有设置，这对他来说应该不是问题，但正确设置所有设置可能比它应该的要复杂得多。因此，最好的解决方案可能是让您的朋友生成一个新的公钥，他使用它来签名和加密。就像我说的，因为抵御攻击的主要防御措施是只对消息的加密安全哈希进行签名，所以拥有这样的密钥并不是一个严重的弱点。