GPG - 為什麼我使用子密鑰而不是主密鑰進行加密？
加密要發送給協作者的文件時，我看到以下消息：
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”似乎意味著“加密”。但是，我還沒有找到任何關於此的文件。此外，我的合作者多年來一直在使用這些工具和技術，為什麼這對我來說只是個問題？
更新
雖然下面的原始文章正確地解釋了為什麼您可能想要使用單獨的加密和簽名密鑰，但它並沒有很好地回答為什麼您使用子密鑰而不是主密鑰的問題。Debian Wiki 提供了更全面的答案。
總而言之，您的主密鑰是您的線上身份，而您的身份和聲譽是通過讓其他人通過自己簽名來保證該密鑰是您的而建立的。（你可能會認為它是你的 Twitter 賬號，你的聲譽是你的 Twitter 追隨者，或者你可能會反對這個類比，但我希望它能讓你明白為什麼要保護它。）所以，既然你的主要密鑰非常重要，並且是多年積累的，您非常想保護它。特別是，您不想將其儲存在可能被盜或被黑客入侵的電腦上；您希望將主鍵離線保存在安全的地方。
當然，這會使您的主鍵使用起來非常不方便。因此，對於日常操作，您希望使用一個問題不大的密鑰來替換它，如果它被洩露。這就是發明子鍵的原因。
子密鑰仍然是公鑰/私鑰對，只要您擁有私鑰，它就是安全的。在密碼學上，它與您的主密鑰一樣安全。不同之處在於您的聲譽僅由您自己的簽名（來自您的私鑰的簽名）附加到它。用 Twitter 類比，世界相信你是你的 Twitter 使用者，因為你所有的追隨者都這麼說（我知道，它並不總是這樣，但類比很難！），然後建立這種信任，你可以然後通過發布推文更容易讓全世界相信你擁有你的 Instagram 賬號，人們會相信你，因為推文來自你信任的賬戶。
您仍然希望確保您的子密鑰安全，但現在如果它被洩露，那麼如果您的主密鑰被洩露（或者，類似地，有人劫持了您的 Twitter 帳戶），這並不是什麼大問題。現在，您可以通過簽署撤銷證書和新子密鑰並將它們都發佈在您的公共密鑰環上來撤銷子密鑰並發布新的子密鑰（比如發推文“嘿，我的 Instagram 句柄已更改，不要使用舊的，使用這個一個代替”）。這使得將子密鑰保留在筆記型電腦上比保留主密鑰更容易接受。
TL;DR子密鑰通過將公鑰的加密功能與（主）公鑰的信任和身份功能分開，使密鑰管理變得更加容易。
原帖
如果您研究公鑰加密的數學細節，您會發現簽名和解密實際上是相同的操作。因此，在一個簡單的實現中，可以通過要求某人簽名來欺騙某人解密消息。
在實踐中做了幾件事來防止這種情況發生。最明顯的是，您從不簽署實際消息，而是簽署消息的安全雜湊。不太明顯，但為了更加安全，您使用不同的密鑰進行簽名和加密。此外，將加密密鑰分開可以讓您將其他可能更重要且使用頻率較低的密鑰保持離線且更安全。您檢查過的鑰匙就是這種情況。順便說一下，標誌的意思是：
- e = 加密/解密（解密您收到的加密消息以供您閱讀）
- s = sign（簽名數據。例如文件或發送簽名的電子郵件）
- c = certify（簽署另一個密鑰，建立信任關係）
- a = 身份驗證（使用 PGP 密鑰登錄 SSH；這是相對較新的用法）
請注意，在所有情況下，“密鑰”都表示公鑰和私鑰對。
如果您的朋友一切設置正確，這對您的朋友來說應該不是問題，但是正確設置一切可能比應有的複雜。因此，最好的解決方案可能是讓您的朋友生成一個他用於簽名和加密的新公鑰。就像我說的那樣，因為針對攻擊的主要防禦措施是僅對消息的加密安全雜湊進行簽名，所以擁有這樣的密鑰並不是一個嚴重的弱點。