來源：Noemi Glaeser，a16z crypto
在公鑰密碼學中，一直以來都有一個難題，那就是如何將加密金鑰（如公鑰）正確地與一個特定的身分（例如某個人或組織）關聯起來。這個問題的關鍵在於，要有一種公開且一致的方式來顯示身分和公鑰之間的關係，這樣大家才能放心地使用這些公鑰來加密資訊。
如果沒有這樣明確的關係，別人可能無法確定某個公鑰到底屬於誰，這樣就有可能把加密訊息傳送給錯誤的人，導致資訊外洩或其它嚴重的後果。在Web3 中，這個問題依然存在。
對於上述的問題，目前有三種解決方案：Public Key Directory、基於身分的加密（IBE）、和基於註冊的加密（RBE）。這三種方法在匿名性、互動性和效率上各有各的優點。例如，IBE 需要強大的信任基礎，但在某些情況下，IBE 在匿名性和效率上表現得更好。本文旨在探討這三種方法在區塊鏈上的應用，並比較它們的優缺點。
三種方法
一般來說，將加密金鑰與身分資訊關聯的常用方法是使用公鑰基礎設施（PKI），其中核心部分是一個公鑰目錄。在這種方法中，發送訊息的人需要與一個受信任的第三方（即維護這個目錄的機構，通常是憑證授權單位）進行互動，以便發送加密訊息。
然而，在Web2 的環境中，維護這個公鑰目錄需要較高的成本以及繁瑣的作業。此外，使用者還面臨證書頒發機構可能濫用權力的風險。
密碼學家提出的一些替代方案，以解決公鑰基礎設施（PKI）存在的問題。在1984年，Adi Shamir 提出了基於身分的加密（IBE），其中一方的識別（例如電話號碼、電子郵件或ENS域名）可以直接用作公鑰。這種方法消除了維護公鑰目錄的需要，但引入了一個新的問題：必須依賴一個受信任的第三方（金鑰產生器）來產生私鑰。
2001年，Dan Boneh 和Matthew Franklin 提出了第一個實用的IBE構造，但這種技術並未廣泛採用，主要是在一些封閉的生態系統中使用，例如企業或政府的部署環境。 IBE不被廣泛使用的原因之一可能是它需要依賴一個強大的信任假設，即信任第三方產生得金鑰。
不過，正如本文後續將討論的，這種信任問題可以透過依賴一個受信任的多方（即一組參與者組成的法定人數）來解決，而區塊鏈技術可以輕鬆實現這一點。
優點和缺點
在比較這幾種加密方案時，需要考慮許多不同的因素，我對此做出兩種假設：
使用者不會更新或撤銷他們的金鑰：這意味著在討論中假設每個使用者的金鑰都是固定的，不會改變。
智能合約不使用任何鏈下的數據可用性服務（DAS）或blob 數據：也就是說，假設智能合約完全依賴鏈上數據，不涉及鏈外的數據服務或額外的數據存儲。
Public Key Directory
任何人都可以透過呼叫智能合約，將一個沒有被別人佔用的ID 也就是 (id, pk) 條目加入鏈上目錄。
去中心化的PKI 是指透過智慧合約來維護一個身分（ID）和其對應公鑰的目錄。這個目錄是公開的，並且不依賴中心化的第三方。例如，以 ENS 為例，它維護了一個網域名稱（即身分）與相關元資料的對應關係，包括該網域所解析的位址（從這些位址的交易中可以推導出公鑰）。 ENS是一個更複雜的系統，不僅記錄公鑰，還儲存了其他元資料。去中心化的PKI 的功能相對來說更簡單：智能合約只需維護一個列表，記錄每個身分對應的公鑰即可。
當使用者想要註冊一個身分得時候，首先需要產生一對金鑰（公鑰和私鑰），或使用已經產生的金鑰對，將其身分ID和公鑰傳送到智慧合約（可能還會支付一定費用），智能合約會檢查這個ID是否已經被別人註冊過。如果沒有被佔用，智能合約就會將這個ID和公鑰加入目錄。一旦註冊完成，任何人都可以透過詢問智能合約來獲取某個ID對應的公鑰，以便加密發送訊息給該用戶，如果發送者之前已經加密過訊息給這個用戶，並且已經有了該用戶的公鑰，就不需要再次向智能合約請求公鑰。有了公鑰後，發送者可以像平常一樣使用它來加密訊息，然後將加密後的訊息發送給接收者，接收者使用對應的私鑰來解密訊息，恢復原文。
讓我們來看看這個方法的優點和缺點：
優點缺點非互動解密：解密過程不需要與其他方互動，解密者可以獨立完成解密。不簡潔(Not succinct)：系統可能在某些方面不夠簡潔，可能意味著複雜性較高，資料量較大，或需要更多資源。透明性：系統可能在某些方面是透明的，這意味著操作是公開的、可以被審查的。互動式加密：加密過程可能需要與其他方進行一定的互動，增加了複雜性。任意ID ：使用者可以自由選擇或使用任意的身份ID，而不受特定格式或規則的限制。發送者非匿名：發送者的身分在系統中可能無法完全保持匿名。
基於身分的加密(IBE)
使用者的身分由他們的公鑰來表示，也就是說，公鑰不僅用於加密，還可以作為使用者的唯一識別碼。但是這種方法需要依賴一個或多個值得信賴的第三方，這些第三方負責產生並發放金鑰。此外，這些第三方還需要在系統的整個生命週期中保管一個主金鑰，這個主金鑰在某些情況下可能用於解密或其他重要操作。
在IBE系統中，使用者並不像傳統加密系統中那樣自己產生一對公鑰和私鑰。相反，用戶需要使用受信任的密鑰產生器註冊。金鑰產生器擁有一對主金鑰（包括主私鑰msk 和主公鑰mpk）。當使用者提供自己的ID 時，金鑰產生器會使用主私鑰msk 和使用者的ID來計算專屬於該使用者的私鑰。產生的私鑰需要透過一個安全的管道傳遞給用戶，一般來說都是使用金鑰交換協定來建立這個安全通道。
對於發送者來說，IBE系統簡化了加密過程。發送者只需要下載一次金鑰產生器的主公鑰（mpk），之後就可以使用ID 來加密訊息。對於接收者來說，解密也很簡單。註冊用戶可以使用金鑰產生器發給他們的私鑰來解密收到的密文。
金鑰產生器的主私鑰（msk）必須長期保留，因為它在系統運作期間需要不斷地產生新的使用者私鑰。這與某些 SNARK 系統中不同，後者在受信任的設定過程中生成，但可以在設定完成後銷毀。而在IBE系統中，主私鑰不能像SNARK中那樣在初始化後刪除。
即使主私鑰（msk）保管得當，每個註冊用戶仍然需要信任金鑰產生器不會讀取他們的訊息。這是因為金鑰產生器可以隨時保存一份使用者私鑰的副本，或是利用主私鑰重新計算出使用者的私鑰。
金鑰產生器還有可能提供使用者一個有問題或受限的私鑰，這種私鑰可以解密大部分訊息，但無法解密某些金鑰產生器設定的特定訊息。這意味著密鑰產生器有能力操控使用者的解密能力，從而可能對使用者的通訊進行某種程度的控製或限制。
優點缺點鏈上儲存恆定/最小：系統在區塊鏈上所需的儲存量很小或恆定，不會隨時間增加。強烈信任假設：系統依賴一個或多個受信任的第三方，這意味著需要對這些第三方有強烈的信任。如果這些第三方被破壞或不可靠，系統的安全性就會受到威脅。非互動式加密：加密過程不需要與其他方互動，發送者可以獨立完成加密。發送者匿名：系統可以保持發送者的身分匿名，保護隱私。任意ID：使用者可以自由選擇或使用任意的身份ID，不受特定格式或規則的限制。
基於註冊的加密(RBE)
像IBE一樣，在這個系統中，使用者的身分（例如電子郵件地址或電話號碼）直接充當他們的公鑰。但與IBE不同的是，這個系統不再依賴一個受信任的第三方或一組quorum 來管理金鑰。相反，這種受信任的第三方被一個key curator 取代。
我將在這部分討論一種高效的RBE構造方式，因為據我所知這與其他實用的RBE構造相比有一個顯著優勢，它可以在區塊鏈上部署，因為它是pairing-based，而不是lattice-based 的。
在RBE系統中，每個使用者自己產生一對金鑰（包括公鑰和私鑰）。使用者還需要基於他們的私鑰和一個公共參考字串（CRS）來計算一些更新值（圖中標記為a）。這些更新值用於系統中的進一步操作。公共參考字串（CRS）的存在意味著系統的設定並非完全不需要信任。然而，CRS的生成過程採用了一種稱為 tau 的冪的構造方法。這種構造方法可以在鏈上透過多個參與者協作計算完成。只要有至少一個參與者是誠實的，這個CRS 就是安全的。
智能合約為預期數量的用戶N 進行了設置，這些用戶被分組到不同的buckets 中，當用戶在系統中註冊時，需要向智能合約發送自己的身份ID、公鑰和更新值。智能合約會維護一組公共參數pp，這些公共參數不同於前面提到的公共參考字串（CRS）。可以將pp 理解為系統中所有已註冊使用者公鑰的簡潔摘要。智慧合約接收到使用者的註冊請求後，會對更新值進行檢查，以驗證它們的正確性。一旦驗證通過，智能合約會將該用戶的公鑰乘入到pp 中的對應buckets 中。這一步驟操作相當於將新使用者的公鑰納入系統的公共參數集合中，以便後續操作使用。
在基於註冊的加密（RBE）系統中，用戶需要在本地保存一些訊息，這些資訊用於幫助他們解密訊息。當有新用戶註冊到與他們相同的群組中時，這些資訊需要更新。用戶可以自己監控區塊鏈來手動更新這些信息，或者智能合約可以提供最近註冊的用戶信息，用戶可以定期獲取這些更新來保持他們的解密信息是最新的。
在這個系統中，發送者只需要做兩件事：
下載公共參考字串（CRS）：這只需要下載一次，之後不需要再更新。
下載公共參數：發送者需要偶爾下載最新的公共參數。對於發送者來說，重要的是這些公共參數包含了接收者的公鑰，而不必每次都下載最新版本，只要能找到接收者的公鑰就可以了。
然後，發送者使用下載的CRS、公共參數以及接收者的身分ID，就可以加密訊息並傳送給接收者。這意味著發送者不需要頻繁更新數據，只要確保公共參數中有接收者的公鑰就行。
當使用者收到一條加密訊息時，首先會檢查自己本地儲存的輔助訊息，看看是否有符合某個條件的值（例如透過某個驗證檢查的值），如果使用者在本地找不到符合條件的值，這意味著他們需要從智能合約獲取最新的更新信息，一旦用戶找到了合適的輔助資訊值，他們就可以使用這個值和自己的私鑰來解密收到的密文，從而恢復原始訊息。
顯然，該方案比其他兩個方案更複雜。但它所需的鏈上儲存比公鑰目錄少，也避免了IBE 的強烈信任假設。
簡潔的參數：
-
在鏈上儲存的參數大小與使用者數量的關係是次線性的，這比公鑰目錄所需的儲存量（線性成長）要小得多，但仍然不是常數，因此在這一點上不如IBE（基於身份的加密）系統。
有一定互動性的加密：
-
發送訊息時，發送者需要一個包含目標接收者的公共參數副本。這意味著發送者需要在接收者註冊後某個時間點更新這些參數，但不需要為每個接收者單獨更新，因為一次更新可能包含多個接收者的金鑰。整體而言，訊息發送的互動性比IBE更多，但比使用公鑰目錄少。
有一定互動性的解密：
-
和加密類似，接收者需要一份與加密時使用的公共參數版本相符的輔助資訊。當有新使用者在某個分組中註冊時，公共參數和輔助資訊會更新，能夠解密密文的值是對應於加密時所使用的公共參數版本的。使用者可以選擇定期取得輔助資訊更新，而不是每次都立即更新，除非解密失敗。與公共參數更新不同的是，更頻繁地獲取輔助資訊更新不會洩露隱私資訊。
發送者匿名：
-
與公鑰目錄的情況類似，發送者可以獨立加密訊息（只要它有最新的參數），而不需要查詢與接收者相關的特定資訊。當發送者需要從鏈上讀取資訊時，這些資訊與目標接收者無關（除非發送者只要求某個特定的參數得分組，但這樣可能會洩露部分資訊）。
透明性：
-
儘管系統需要透過信任設置（可能是分散式或外部管理的）來設置，並輸出一個修正的CRS（公共參考字串），但一旦設置完成，它不再依賴任何受信任的第三方或仲裁組。雖然它依賴於一個協調的第三方（智能合約），但這個系統是完全透明的，任何人都可以充當協調者或通過驗證狀態轉換來檢查其是否誠實運行（這也是為什麼它可以作為智能合約實現）。此外，使用者可以要求一個簡潔的（非）會員資格證明，以檢查自己或其他人是否在系統中註冊。這與IBE系統不同，在IBE中，難以讓受信任的第三方證明他們沒有秘密地洩漏解密金鑰（例如保存了一個秘密副本或洩漏給其他人）。相比之下，公鑰目錄是完全透明的。
受限的ID集合：
-
這裡描述的是RBE構造的基本版本。為了透明地決定一個ID所屬的分組，ID必須有一個公共且確定的順序。電話號碼可以簡單地排序，但對任意字串進行排序則可能非常複雜甚至不可能，因為分組的數量可能非常大或是無限的。這可以透過提供一個單獨的合約來計算這種映射，或者採用後續工作中提出的cuckoo-hashing 方法來緩解這種複雜性。
收件人匿名：
-
這種方法可以讓密文不會洩漏收件人的身分。
