☰

仍然對 GPG 金鑰和子金鑰感到困惑

tag-icon • tag-icon command-line encryption gnupg
仍然對 GPG 金鑰和子金鑰感到困惑

我剛剛產生了一個新密鑰

gpg --快速產生金鑰

現在，當我這樣做時

gpg --列表鍵[電子郵件受保護]

我得到這樣的東西：

pub   rsa2048 2020-01-29 [SC] [expires: 2022-01-28]
      DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF
uid           [ultimate] [email protected]
sub   rsa2048 2020-01-29 [E]

但是當我這樣做時：

gpg --編輯鍵[電子郵件受保護]

我得到類似以下內容：

gpg (GnuPG) 2.2.17; Copyright (C) 2019 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/DEADBEEFDEADBEEF
     created: 2020-01-29  expires: 2022-01-28  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/BEEFDEADBEEFDEAD
     created: 2020-01-29  expires: never       usage: E   
[ultimate] (1). [email protected]

我認為我至少在某種程度上理解了鍵和子鍵的概念，但這對我來說仍然沒有意義。

  1. 為什麼輸出在一種情況下顯示公鑰，在另一種情況下顯示秘密密鑰？
  2. 為什麼在第一種情況下公鑰 ( pub) 顯示為能夠簽署 ( )，而在第二種情況下S秘密金鑰 ( ssb) 顯示為能夠加密 ( ) ？E這不是與我們在公鑰加密101中學到的內容背道而馳嗎？

答案1

為什麼輸出在一種情況下顯示公鑰，在另一種情況下顯示秘密密鑰？

在 GnuPG 2.1+ 中，我猜該--edit-key命令會顯示密鑰，因為它一直都是這樣做的。

回到 GnuPG 1.x（與原始的 PGP 2.x 類似），有兩個完全獨立的金鑰環（pubring 和 secring）。有些操作與其中之一配合使用，有些操作與另一種配合使用。所以--list-secret-keys過去完全一樣，--list-keys只是它從不同的檔案讀取，並且--edit-keys過去有一個可以在兩個視圖之間翻轉的子命令。

為什麼在第一種情況下公鑰 (pub) 顯示為能夠簽署 (S)，而在第二種情況下秘密金鑰 (ssb) 顯示為能夠加密 (E)？這不是與我們在公鑰加密101中學到的內容背道而馳嗎？

不會。意思是不僅用於「內部」密鑰在數學上能夠進行的加密操作。這意味著它們不會根據您查看的是公共部分還是私人部分而改變。

例如，您的範例 PGP 金鑰區塊中有兩個 RSA 金鑰對，從技術上講，它們都可以簽署/驗證以及加密/解密。但擁有兩個的全部意義在於您希望將它們的用途分開 – 即您不希望 GnuPG 使用用於簽名的子密鑰來執行加密，因此使用標誌將其過濾掉。

（沒有單獨的「解密」或「驗證」標誌，因為訊息或簽名已經指示要使用哪個金鑰。）

這也意味著可以有多個使用標誌映射到相同的操作（簽名或驗證），但在不同的上下文中：

  • 「S」允許密鑰用於簽署訊息和文件（電子郵件等）；
  • 「C」允許密鑰用於簽署（證明）其他密鑰/子密鑰；
  • 「A」允許金鑰用於簽章身分驗證質詢（如 TLS 或 SSHv2 中）。

儘管這三者在加密意義上都進行了相同類型的數位簽名，但出於政策原因，金鑰本身通常是分開的。 （例如，「c」認證金鑰應該比「a」認證金鑰受到更嚴格的保護。）

相關內容