GnuPG Keysigning Party HOWTO

所謂的金鑰簽署大會，指的是一群都使用 PGP 加密系統的人，為了簽署彼此的金鑰而齊聚一堂。金鑰簽署大會不但能大幅拓廣信任網，也能提供機會，讓人們討論跟強編密法、個人自由、個人主權、施用加密科技或跟日後自由加密軟體有關的政治及社會議題。

金鑰簽署是一種實際對附加在某把金鑰上的公鑰、及使用者 ID 封包加以簽署的數位簽署動作。實際的動作包含了去驗證給定的使用者 ID 及公鑰是否真的擁有該把金鑰，並搞清楚這個使用者 ID 實際上到底代表著誰。

妳可以對妳自己的公鑰和金鑰上的 ID 進行數位簽署，也能夠對別人的公鑰或相關的公鑰封包這麼做。

就某種意義來說，金鑰簽章可以被視為該把公鑰有效的證明；它們是第三方對公鑰及其附屬 ID 有效性的背書。這也正是金鑰簽署建立起信任網的方法。

所謂的信任網，是一個用來描述一群金鑰間信任關係的詞彙。每一份金鑰簽章都是一個鏈結，或者說是信任網中的一條繩索。這樣的鏈結又稱做信任路徑 (Trust Paths) ；這種信任路徑可能會是雙向的，但也可能祇是單向而已。理想中的信任網應該要是任何人都與其他人雙向互相連結的；實際上每個人都相信每一把金鑰都確實屬於其持有者。信任網可以被當作是所有這種金鑰持有者間，信任路徑或鏈結的總和。讓我們舉一個實際看得見的例子，這兒就是我所屬的信任網關係圖。

舉例來說，假設 Alice 和 Bob 各自用 GPG 打造了一副 PGP 金鑰，然後她們參加了一個 PGP 金鑰簽署大會。在這場大會上 Alice 和 Bob 驗證了彼此的金鑰資訊，稍後她們並簽署了彼此的金鑰。在預設的情況下， GPG 會自動地以相對應的私鑰簽署它所打造出來的每一把公鑰（譯註：這又稱作自我簽章）。所以現在 Alice 和 Bob 至少都有兩份簽章，能夠證實她們手上的金鑰確實屬於她們自己。 Alice 的金鑰被 Alice 自己和 Bob 的金鑰簽署過，而 Bob 的金鑰也被 Bob 自己和 Alice 簽署過。之後 Alice 和 Bob 又遇到了 Cathy 。 Cathy 也打造了一副金鑰對，並且告訴 Alice 及 Bob 說她將把她的金鑰寄給她們。但是 Alice 並不喜歡 Cathy ，也不希望 Bob 跟她進行加密通訊。於是 Alice 和 Cathy 同時打造了一副宣稱屬於 Cathy 的 PGP 金鑰，這兩副金鑰也都被寄給 Bob ，而兩副金鑰上也都祇有一份來自各自相對應私鑰的簽章。 Bob 並不曉得到底哪一把金鑰纔真的是 Cathy 的。 Cathy 聽說 Bob 收到了兩份金鑰，於是開始懷疑起 Alice 。這下子 Cathy 可生氣了，她想要增加能用來對抗 Alice 詭計的資訊。為了要取得這樣的資訊， Cathy 就得要讓 Alice 和 Bob 間的加密通訊給暴露出來。因此， Cathy 決定偽造一封由 Alice 寄給 Bob 的信件，告訴他 Alice 打造了一副新的金鑰。在這封偽造信件裡， Cathy 附上了一把 Alice 的「新的」公鑰（而這把公鑰實際上是由 Cathy 自己打造的假金鑰）。然而 Bob 顯然能夠確定這祇是個詭計，因為即使 Bob 現在手上有兩把宣稱是屬於 Alice 的金鑰，但是其中一把卻由多人（他自己和 Alice ）簽署過以證實它真的屬於 Alice ，而另一把 ─ 由 Cathy 打造的偽金鑰 ─ 卻祇有來自自己的簽章。

上面這個例子已經相當單純了，實際的情況絕對可以複雜得多。妳可以閱讀 PGP 常見問答集或 PKI 上的好書，來取得解說更為詳盡的資訊。上述的例子祇用來清楚地解釋金鑰簽署的基本概念和其價值。由於 Bob 和 Alice 間互相連接的信任網，使得 Cathy 沒辦法引入 Alice 的假金鑰對。

然而簽章及信任網並不能擔保可信任的金鑰。舉例來說，當 Bob 和 Alice 第一次遇見 Cathy 時，假設 Cathy 的某個朋友 Donald 已經跟 Cathy 在一起了，而 Donald 打造了 Alice 和 Bob 的假金鑰，並且用自己的金鑰跟兩副假金鑰彼此加以簽署，讓兩把假金鑰看起來有三份簽章，再把這對金鑰寄給 Cathy 。緊接著 Cathy 就會面臨不良的金鑰及簽章。金鑰簽署要怎麼幫助 Cathy 抵抗這樣的攻擊呢？呃，讓我們假設所有的人都透過金鑰伺服器來交換金鑰，所以如果 Cathy 在金鑰伺服器上搜尋 Alice 和 Bob 的金鑰，她就會找到他們兩位的金鑰。如果 Alice 和 Bob 在金鑰簽署大會上蒐集到二十份金鑰簽章的話，顯然 Cathy 能夠比較信任被簽署了二十次的金鑰，而不是祇被簽署了三次的那一把。 Cathy 該能從額外公鑰的存在而得知更多事 ─ 所以她可以仔細地察看金鑰的打造日期以及公鑰背後的信任網。這二十把來自金鑰簽署大會的金鑰，根據打造日期的不同，也應該至少被簽署了二十次以上；通常被 Alice 和 Bob 的金鑰給簽署過的金鑰，也會被其他的金鑰所簽署。不過若 Donald 另外打造了二十副假金鑰對，並且用來產生假的信任網時，妳還是沒辦法祇靠這個辦法來鑑別。

有三個主要的理由，能夠說明為什麼妳應該要盡可能地參加金鑰簽署大會。

首先，可能也是最重要的理由是，妳應該要為了拓廣信任網而盡可能地參加金鑰簽署大會。內部越深入而緊密相連結的信任網，也就越難被整垮。這對於自由軟體社群來說格外明顯，無論是開發者或使用者皆然。社群成員依靠 PGP 科技來從密碼學上保護她們軟體套件、安全性建議和釋出通告的完整性。信任網的強壯與堅韌直接跟 PGP 提供給社群的保護強度成正比。

其次，金鑰簽署大會也能夠幫助其他人學著加入安全文化裡，並且也能鼓勵她們多加瞭解 PGP 跟相關的強編密法技術。為了要從強編密碼獲益，人們就得使用這些強編密法，而且還得妥善使用纔行。

最後一個理由是，金鑰簽署大會有助於建立社群。這能讓這些技術專家們聚在一起認識對方、網路並討論像是人民自由、加密權和網路管理等議題。討論之所以重要，不祇是因為討論是第一步，更因為這是實際行動之前的必備步驟。我撰寫本文件之時，世界上還沒有太多複雜的信任網。如果妳想要在當地建立起信任網的話，往往第一次出現的參與者日後就會變成當地的網際網路社群領導者跟政策決議者。祇要她們選擇了要這麼做，她們將會是能夠選擇要在當地機構建立起安全的強編密法科技與通訊協定的人們。這類科技與通訊協定的整合，將能夠引發像是 FBI 的食肉系統 (carnivore system) 那種技術上不可行而沒有下文的玩意兒的爭論。

要籌畫主持一場金鑰簽署大會並非太困難的事。然而除了要定期拜訪人們、挑選時間和場地外，主持人的金鑰簽署還必須比其他金鑰更為可靠纔行。除此之外，主持人該做的事通常還包括了要提供一份列有每個參與者的金鑰清單，以及決定整個大會的流程。

有兩種進行 PGP 金鑰簽署大會的方法 ─ 中心化的方法跟去中心化的方法。金鑰簽署的最佳辦法可以按照會參與的人數以及妳舉辦大會地點的氣氛來決定。大會的基本需求是要讓參與者能驗證彼此的金鑰以及身份。祇要能滿足這個最基本的需求，主辦人就能夠任意地從這兩種方法中加以調整大會的型態。

在中心化的大會中，一切都會比較嚴謹，適合用於少量或中等數量的參與者。在這種方式中，參與者會把她們的金鑰資訊寄給主辦人，而主辦人則會把這些資訊匯編成一份清單。每一位參與者抵達大會會場的時候就會領到一份金鑰清單的副本。在大會中，每一位參與者都會被主辦人先後請到台上，並且拿自己的金鑰指紋核對印在主持人給的清單上的指紋。如果參與者確定她們的金鑰跟印在紙張上的金鑰是同一副的話，就可以把她的金鑰指紋朗讀出來；這個時候其他的大會參與者就可以確認她們手上拿到的金鑰指紋正確無誤。如果這真的是正確吻合的金鑰指紋的話，參與者們就可以在紙條上加註記號。這是用來確認主持人沒有在產生紙條的過程中犯錯、或沒有任何帶有偽造金鑰資訊的紙條流入參與者手中的必要步驟。當每一個人都加註了這位參與者的金鑰後，主持人就會請下一位參與者上台，依此類推。當所有的金鑰都被驗證過後，主持人和所有的參與者就會被要求排成長長的一縱列，同時把各自的 ID 放在身前。這一縱列的第一個人於是開始沿著縱列走下去，並依序檢查每一個人的 ID 。如果這些 ID 都正確無誤，那麼這個一路走下去的人在檢查某個人的時候，這個人就會驗證這把金鑰，並且說這的確是她們在大會開始時所提供的金鑰，於是他就可以在自己的清單上加註第二個檢查記號。一旦某把金鑰上被標記了兩次記號後，就可以被簽署了。

去中心化的大會基本上就是每個人代表她自己。參與者將會被非正式的混在一起，然後自己去找出她還沒簽署的金鑰持有人。當她們相會之後，她們就會驗證彼此清單上各自的金鑰，並驗證彼此的身份證明。去中心化的大會能讓更多人相會，但卻很容易使得某些參與者並沒有真的去驗證將來要簽署的金鑰。在這種去中心化的大會中，主持人應該要鼓勵每個人都確定她們遇見了所有其他的人，並且驗證了金鑰，這是相當重要的事。雖然在去中心化的大會中，並不需要做出金鑰及指紋的清單，不過這麼做仍然有其好處。

中心化的大會相當適合拿來當作研討會午餐期間，安靜地在某人家中或餐廳等地舉行的金鑰簽署大會。去中心化的金鑰簽署大會則更適合於有相當大量的人參與的大會中，或者是用於某些嘈雜而難以控制的技客會出沒的大會裡。

這場大會越大越好。妳可以在當地的 LUG 郵遞論壇、其他妳所在跟電腦相關的論壇、甚至是在報紙上刊登廣告或發佈出版文宣來通告這場大會的舉辦。

如果妳纔剛開始在那一帶建立起信任網的話，試著請其他活躍的 PGP 使用者參與會是個好主意，因為她們將會是未來可能自己參加金鑰簽署大會的人。要找出這樣的人，妳可以試著先跟寄信到妳所在郵遞論壇時會附上 PGP 簽章的人談談，或者妳也可以在金鑰伺服器網路上搜尋電子郵件地址限定在妳當地的電子郵件。舉例來說，像是電子郵件地址以妳附近某所大學或某間大公司結尾的人，很可能就能帶領一大堆有興趣的參與者出現。

以下是一些簡單的通告範例：

如果妳打算要舉辦的大會中，安排了要讓參與者擁有每一位出席大會的人的金鑰清單，那麼主持人就得先產生出這樣一份清單。這份清單看起來應該會被匯編成像這樣的格式：

我撰寫了一支 perl 腳本來從 gpg 鑰匙圈產生像這樣的 HTML 文件。這支用來產生金鑰簽署大會的金鑰清單的 perl 腳本可以按照 GNU General Public License (GPL) 的授權內容任意使用。

這份金鑰清單的副本應該被印出來交給每一位出席金鑰簽署大會的人。主持人可以多列印一些這份清單的副本，也可以把這份清單寄出去或放在網頁上，讓出席者能夠自己印出來。

沒有比彩色圖片更能吸引人們眼神焦點的東西了。因此當妳建立當地的信任網時，繪製信任網關係圖將能夠讓人們更有參與的動機，同時也能夠讓每個人都明白這整件事到底是如何實現的。

妳可以把這些資訊轉換成像 dot 檔案這種能夠餵給 dot 或 neato 這類繪圖程式的格式，然後輕易地把所有信任網中的金鑰跟簽章都建立成圖形。 Darxus 寫了一個 perl 腳本，能把鑰匙圈裡的金鑰跟簽章都轉換成 dot 格式的檔案，這個 perl 腳本也一樣地可以在 GPL 的授權下任意使用。為了要繪製出信任網，妳得下載 Darxus 的 sig2dot.pl 腳本，並從 AT&T Research 下載 graphviz 套件。由於執行這個腳本所需的記憶體數量限制，妳可能無法描繪出超過幾百個節點所構成的信任網。

從 gpg 鑰匙圈繪製信任網的指引也包含在 sig2dot.pl 腳本裡了，不過妳也可以從 Debian 鑰匙圈繪製頁面找到。喏，這兒就是檢視信任網圖形的鏈結，這個圖形就是由 sig2dot.pl 腳本和 neato 繪製程式所產生的。妳也可以在 Debian 金鑰繪製頁面找到更多資訊。

妳不應該把電腦帶到大會現場，因為置換執行檔或進行系統修改，都是能輕易瓦解 PGP 系統的方法。

如果有人帶了一台攜帶式電腦到場，而每個人都用這台電腦來在會場簽署別人的金鑰的話，沒有人會知道這台電腦是否正執行著按鍵側錄程式、或修改過的 GPG 、修改過的 Linux 核心甚至是正在使用修改過的鍵盤；而上述的這些手段都將能拿來擷取使用這台電腦的人的秘密金鑰。

在會場使用電腦同時也會讓妳暴露在更多像是肩窺 (shoulder-surfing) 的簡單攻擊手段，或像是弱秘密金鑰打造、秘密金鑰修改甚至是以病毒入侵並修改你的 GPG 執行檔以直接洩漏秘密金鑰等這類複雜攻擊手段裡。

打造金鑰對的程序相當簡單。基本上來說妳就祇需要執行 gpg --gen-key 就行了。然而我建議妳最好同時也產生一份撤銷憑證，免得日後妳不幸無法存取秘密金鑰（像是弄丟了密碼串或遺失了秘密金鑰）時還有最後一條路可走。產生撤銷憑證的指引可以在本文件的 3.7 節找到。

以下這份逐步指引是按照我所知道的實際使用情況原則而撰寫而成的，理論上也夠安全。舉例來說：

有些人也許就算不談論這些安全預警也能感到自在。舉例來說，如果妳有一台攜帶式電腦或家用電腦，而且妳用這台電腦來讀取所有的電子郵件的話，那麼也許妳會很愉快地把金鑰儲存在這台電腦的硬碟裡。同時妳也能放心地打造一副永遠不會過期的金鑰對，用來鑑別妳自己的身份並用於大量的通訊中 ─ 然後再打造另一副額外的金鑰對來處理極端敏感的通訊（妳真的該這麼做）。再次聲明，以下這份逐步指引是按照我所知最佳的實務安全性原則所撰寫而成的。妳並不需要完全按照這些步驟，祇需要打造一副金鑰對就行了。另一方面來說，如果妳跟我一樣也是對安全性極度偏執的怪胎的話，那麼按照這些指引至少能在短時間內，暫時快速地提供妳所需要的冷靜感。

以下這份逐步指引是按照我所知道最佳的實務安全性（極度偏執）原則所撰寫而成的。舉例來說：

1) 到 www.gnupg.org 並下載最新版的 gnupg: gnupg-x.x.x.tar.gz

警告：請確定妳至少正在執行 1.0.6 版以後的 GnuPG 。 1.0.6 版以前的版本至少有一個顯著的安全性弱點。

2) 檢查 GnuPG 壓縮檔的 PGP 簽章和 MD5 加總檢查：

bash$ gpg --verify gnupg-x.x.x.tar.gz.sig gnupg-x.x.x.tar.gz bash$ md5sum gnupg-x.x.x.tar.gz

3) 解開壓縮檔、進行組態、編譯然後加以安裝：

bash$ tar xvzf gnupg-x.x.x.tar.gz bash$ cd gnupg-x.x.x bash$ ./configure bash$ make bash$ su bash# make install bash# exit bash$ cd

如果妳安裝 GnuPG 的系統會跟其他人共用的話，妳也許也會想要對 gpg 執行 setuid root 來讓它使用安全的記憶體。如果妳選擇要這麼做，那麼妳就應該預先警惕到可能的危險，並且用 md5 簽章跟 pgp 簽章來檢查妳手上的壓縮檔，以確保妳沒有安裝到被裝殖了特洛伊木馬的程式。

4) 拿一片準備用來存放妳的金鑰的磁片，並且先加以格式化。

bash$ /sbin/mkfs.ext2 /dev/fd0

4a) 把軟碟掛上並在上面建立一個屬於妳的目錄，用來存放妳的金鑰：

bash$ mount /mnt/floppy bash$ mkdir /mnt/floppy/.gnupg

有需要的話（依照妳系統上的 fd0 存取而異）：

bash$ chown <your_uid>:<your_gid> /mnt/floppy/.gnupg

4b) 從妳的家目錄建立一個指向軟碟的符號鏈結

bash$ ln -s /mnt/floppy/.gnupg .gnupg

5) 打造妳的 gnupg 金鑰

bash$ gpg --gen-key

5a) 選擇妳想要使用的金鑰類別 ─ 用預設值就好了。

Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) Your selection? <return>

5b) 選擇妳的金鑰尺寸： 2048

DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024) 2048<return> Do you really need such a large keysize? yes<return>

5c) 選擇這把金鑰的壽命： 5 年會是個好選擇

Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 5y<return> Key expires at Sun Sep 21 16:17:15 2005 EDT Is this correct (y/n)? y<return>

5d) 輸入妳的姓名跟電子郵件地址…

Real name: Demo User<return> Email address: demo@nonexistent.nowhere<return> Comment: You selected this USER-ID: "Demo User <demo@nonexistent.nowhere>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O<return>

5e) 選擇一個密碼串。妳得仔細挑一個纔行。這個密碼串應該要夠長而且要難以被猜到纔行。同時這還應該是妳將不會忘記的東西。如果妳忘記了妳的密碼串的話，將會無法回復妳的金鑰。

5f) 移動滑鼠並敲擊按鍵，也可以在背景更新位置或執行大規模的搜尋動作。 GPG 會讀取 /dev/random 來取得打造妳的金鑰所需的亂數。 /dev/random 則是由各種中斷所移植來的。

6) 任意修改你的金鑰。舉例來說，如果妳有很多個電子郵件地址的話，妳可能就會想要把她們都列進金鑰裡的有效電子郵件地址：

bash$ gpg --list-secret-keys /home/demo/.gnupg/secring.gpg ---------------------------- sec 1024D/C01BAFC3 2000-09-21 Demo User <demo@nonexistent.nowhere> ssb 2048g/7A4087F3 2000-09-21 bash$ gpg --edit-key C01BAFC3 Command> help Command> adduid [...] Command> save

7) 把妳的金鑰送到金鑰伺服器上：

[vab@firster vab]$ gpg --keyserver <keyserver> --send-key <Your_Key_ID>

妳應該可以看到一個像這樣的成功訊息：

gpg: success sending to `<keyserver>' (status=200)

值得注意的事有些人相信保持公開金鑰的隱密性對於加密通訊有額外的安全性。這是真的，因為金鑰伺服器可能會被破壞或入侵，而在使用者查詢時傳回不正確的公開金鑰。甚至在特定某台公開金鑰伺服器上的金鑰，可能並不是該金鑰最新的版本。舉例來說，有些加到金鑰上的簽章就沒有被傳播或上船到金鑰伺服器上。另外金鑰對裡的公開金鑰也確實需要去抵抗各式各樣針對 pgp 所使用編碼系統的攻擊。雖然有許多人認為，祇要金鑰尺寸夠大，那麼無論公開金鑰被傳播的多廣，都將難以被擊破，但是保持公開金鑰的隱密性確實能夠使金鑰對更加堅固。

我並不建議妳把公開金鑰保持隱密，因為這將會打消妳使用 PGP 跟其他人通訊的意圖。注意到金鑰伺服器被入侵或破解時，可能會傳回無效的金鑰這個議題，能讓妳採取必要的防護措施，像是把妳的金鑰指紋放在 .signature 檔案或網頁上，以免收到用無效金鑰加密給妳的信件。至於要強調擔心有人用妳廣為人知的公開金鑰攻擊妳的金鑰對的話，我會說如果妳真的非常在意金鑰對的強度，或者是真的對於通訊隱密性極度偏執的話，那麼妳可以為每一次的通訊都打造一份額外的金鑰對（而且會在幾個小時或幾天內就過期），並且透過加密的通訊管道來跟妳的溝通對象傳遞這些金鑰對。

如果妳不希望把妳的金鑰放上公開金鑰伺服器，那麼妳就應該跳過這些步驟，同時在把公開金鑰寄給金鑰簽署大會主持人時，註明說妳不想讓妳的金鑰被放上公開金鑰伺服器。於是主持人就能夠擷取妳的公開金鑰資訊，並且把妳的金鑰用加密過的電子郵件或其他方法，轉寄給其他參與者，同時也一併註明這把金鑰在簽署後祇應該寄回給持有人，而不該上傳到金鑰伺服器。

這不是個必要的步驟。

製作及存放撤銷憑證能讓妳撤銷妳的金鑰，即便是妳的私有金鑰已經因為被洩漏、被奪取、忘記密碼串或儲存媒體損毀而不再能存取也一樣。如果妳希望在無法存取私有金鑰時，有能力撤銷妳的公開金鑰，那麼妳就應該要製作一份撤銷憑證，並且把它存放在安全且可靠的地方。妳也應該列印一份撤銷憑證的副本，因此當存放撤銷憑證的媒體也損毀的時候，妳還能以手鍵入這個撤銷憑證。

如果妳的撤銷憑證遭到洩漏，那麼洩漏妳的撤銷憑證的人也將能散播這份憑證，而使妳的金鑰失效。然而就算她能夠存取妳的撤銷憑證，也無法洩漏妳的秘密金鑰。也就是說她們將無法製作出偽造的簽署、把用妳的金鑰對加密過的訊息解密、或喬裝成是妳金鑰對的持有人。因為洩漏撤銷憑證的唯一風險就祇是金鑰對失效而已，所以這麼做通常是相當安全而值得的。

3.9 節裡面有更多關於金鑰撤銷的資訊。

製作撤銷憑證的 GnuPG? 命令是：

bash$ gpg --output revcert.asc --gen-revoke <key_id>

9) 把妳的資訊寄給主持人，並且告訴她妳將會出席這場金鑰簽署大會。如果妳正在使用金鑰伺服器的話，下列的命令會把妳所需要寄給主持人的資訊印出來。妳可以用一封加密過的電子郵件把這個資訊寄給主持人。

bash$ gpg --fingerprint <Your_Key_ID>

10) 解除軟碟掛載並取出：

bash$ umount /mnt/floppy

注意：為了安全起見妳還可以把軟碟帶在身邊，或把它放在可靠、上鎖了的書桌抽屜等。妳最好別讓妳可被網際網路存取的 .gnupg 目錄裡含有妳的金鑰。

11) 出現在大會上。

第一步：取得金鑰副本

通常妳得跟金鑰伺服器交涉。不過如果妳正要簽署某把不在金鑰伺服器上的金鑰時，妳可以用 gpg --import 來把這把金鑰匯入。如果妳正在跟金鑰伺服器交涉的話，下列的命令將會把金鑰從金鑰伺服器上下載到妳的公鑰鑰匙圈裡。

bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>

如果妳得到讀取錯誤的訊息，這就表示金鑰伺服器負荷過重了。請在幾秒鐘後再試一遍。

第二步：指紋和驗證金鑰

bash$ gpg --fingerprint <Key_ID>

GPG 會印出 <Key_ID> 這把金鑰（就是妳剛剛下載金鑰）的指紋。請用妳在大會所取得的檢核表來檢查這裡出現的指紋。注意： 不要用網頁上的指紋來檢查檢核表上的指紋，因為伺服器傳給妳的金鑰有可能跟在網頁上顯示的並非同一把。

第三步：簽署金鑰

bash$ gpg --sign-key <Key_ID>

如果妳有多把私有金鑰的話，妳可以像這樣祇訂要用哪一把私有金鑰來簽署其他人的公開金鑰：

bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID>

如果妳沒辦法處理 RSA 金鑰的話，可能是妳的 gnupg 版本太舊了。 1.0.3 版以前的 GnuPG 並不包含 RSA 支援。注意：如果妳的發行商用套件管理軟體裝了舊版的話，妳得先把它反安裝再安裝新版。妳可以執行這樣的指令來檢查版本：

bash$ gpg --version

第四步：傳回或上傳已簽署的金鑰

如果妳正在處理的對象並不希望她們的金鑰被送上金鑰伺服器的話，那麼這個節骨眼上妳就該選擇一個方法把她們已被簽署的金鑰送回去 ─ 通常是用加密過的郵件來傳送。妳不應該未經金鑰持有人允許就把金鑰送上金鑰伺服器。發佈某一把公開金鑰將會略微削弱金鑰對的安全性，因此讓金鑰比其持有人所希望的更為公開，將會是非常粗魯的行為。

通常妳會跟金鑰伺服器打交道。如果妳正是在這種狀況中的話，就可以像這樣把已簽署的金鑰送回金鑰伺服器：

bash$ gpg --keyserver <keyserver> --send-key <Key_ID>

妳應該會看到一個像這樣的成功訊息：

gpg: success sending to `<keyserver>' (status=200)

恭喜！現在對別人金鑰的簽署已經完成了，而妳的簽署也已經合併到她們的公開金鑰裡了。一個信任路徑於是被建立起來。

當妳懷疑妳的秘密金鑰已經被洩漏的時候，妳就應該要馬上撤銷妳的公開金鑰。金鑰撤銷需要用到公開金鑰的撤銷憑證。金鑰的撤銷代表著這把金鑰不再有效（安全）而且不應該被繼續使用。一旦撤銷憑證被提出了，就不能反悔。

因為每次妳的 PGP 金鑰被存取時都是散佈（傳閱）在人群之間，而非從某個中央點散佈出來，所以妳也得用跟散佈公開金鑰相同的方法來或散佈妳的撤銷憑證。撤銷憑證的流通就跟妳散佈公開金鑰的方法一樣；通常也就是把撤銷憑證上傳到金鑰伺服器網路上。如果妳因為安全性的顧慮而還沒有把公開金鑰上傳到伺服器的話，妳還是可以把撤銷憑證上傳到金鑰伺服器。在這個情況下，妳是拿把公開金鑰給公開所導致安全性輕微下降，來交換某些人可能還不知道妳的金鑰已經被撤銷的安全性風險。

讓我們複習一下，製作撤銷憑證的 gpg 命令是：

bash$ gpg --output revcert.asc --gen-revoke <key_id>

如果妳知道妳的金鑰甚麼時候或者是怎麼被洩漏的話，那麼就算妳在打造金鑰時就製作過撤銷憑證，妳還是會想要再重新製作新的撤銷憑證，來撤銷妳的金鑰對。因為在這個情況下， OpenPGP 標準會讓妳指定為什麼要撤銷金鑰對的原因，甚至讓妳自由輸入一些註解來說明這個撤銷原因。當撤銷憑證跟這些資訊一起流傳的時候，顯然會對金鑰打造期間的一般性憑證更為有益且合宜。

Copyright (c) 2000 - 2003 V. Alex Brennen.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation.

This document lives at http://www.cryptnet.net/fdp/crypto/gpg-party.html

No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.

All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.

In this document, I have the pleasure of acknowledging:

Feedback is most certainly welcome for this document. Send your additions, comments and criticisms to the following email address : <xxx@xxx.xxx>.

[en] English

[de]German (Local Mirror)

[si] Slovenian (Local Mirror)

[zh-TW] Traditional Chinese (Local Mirror)

If you know of a translation or would like to translate it to another language please let me know so that I can distribute or link to the translated versions.