在加密要发送给协作者的文件时，我看到以下消息：
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”似乎意味着“加密”。但是，我一直无法找到有关此的任何文档。此外，我的合作者已经使用这些工具和技术多年了，为什么这对我来说只是一个问题？
Old*_*Pro 48
虽然下面的原始帖子正确地解释了为什么您可能想要使用单独的加密和签名密钥，但它并没有很好地回答为什么使用子密钥而不是主密钥的问题。Debian Wiki 提供了更全面的答案。
总而言之，您的主密钥是您的在线身份，而您的身份和声誉是通过让其他人通过自己签名来保证该密钥是您的来建立的。（你可能认为它是你的 Twitter 用户，你的声誉是你的 Twitter 粉丝，或者你可能会反对这个类比，但我希望它能让你了解为什么要保护它。）所以，因为你的主要密钥非常重要并且经过多年积累，您非常想保护它。特别是，您不希望将其存储在可能被盗或被黑客入侵的计算机上；您希望将主键离线保存在安全的地方。
当然，这会使您的主键使用起来非常不方便。因此，对于日常操作，您希望使用一个不会有太大问题的密钥来替换，如果它受到威胁。这就是发明子密钥的原因。
子密钥仍然是公钥/私钥对，只要您拥有私钥，它就是安全的。从密码学上讲，它与您的主密钥一样安全。不同之处在于您的声誉仅通过您自己的签名（来自您的私钥的签名）附加到它。使用 Twitter 类比，全世界都相信你是你的 Twitter 用户，因为你的所有关注者都这么说（我知道，它并不总是那样有效，但类比很难！），然后建立这种信任，你就可以然后通过推文更容易说服全世界你拥有你的 Instagram 账号，人们会相信你，因为推文来自你的帐户，他们信任。
您仍然希望确保您的子密钥安全，但现在如果它被泄露，如果您的主密钥被泄露（或者，类似地，有人劫持了您的 Twitter 帐户），这不是大问题。现在你可以通过签署一个撤销证书和一个新的子密钥并将它们都张贴在你的公钥环上来撤销子密钥并颁发一个新的子密钥（比如发推文“嘿，我的 Instagram 句柄改变了，不要使用旧的，使用这个一个”）。这使得将子键保存在膝上型计算机上的风险比将主键保存在膝上型计算机上的风险更高。
TL;DR子密钥通过将公钥的加密功能与（主）公钥的信任和身份功能分开，使密钥管理变得更加容易。
如果您查看公钥加密数学的详细信息，您会发现签名和解密实际上是相同的操作。因此，在一个简单的实现中，可以通过要求某人对消息进行签名来诱使他们解密消息。
在实践中做了一些事情来防止这种情况。最明显的是，您从不签署实际消息，而是签署消息的安全散列。不太明显，但为了更加安全，您使用不同的密钥进行签名和加密。此外，将加密密钥分开可以让您保持另一个可以说更重要且绝对不常使用的密钥离线和更安全。您检查过的钥匙就是这种情况。顺便说一下，标志的意思是：
请注意，在所有情况下，“密钥”都表示公钥和私钥对。
如果您的朋友已正确设置所有内容，这对他来说应该不是问题，但是正确设置所有内容可能比应有的更复杂。因此，最好的解决方案可能是让您的朋友生成一个新的公钥，用于签名和加密。就像我说的，因为抵御攻击的主要防御措施是只对消息的加密安全散列进行签名，所以拥有这样的密钥并不是一个严重的弱点。