從那以後，將加密金鑰連結到身份一直是一個問題技術的介紹挑戰在於提供和維護一個公開且一致的映射，將身份和公鑰（與這些身份相對應的私鑰）對應起來。如果沒有這樣的映射，意圖保密的消息可能會出現問題 - 有時會產生災難性的後果。在 web3 中也存在這樣的挑戰。

目前存在三種可能的解決方案。 兩種經典方法是公鑰目錄和基於身份的加密。 第三種是基於註冊的加密，直到最近都是完全理論性的。 這三種方法在匿名性，互動性和效率之間提供了不同的權衡，起初可能似乎很清楚，但區塊鏈環境引入了新的可能性和限制。 因此，本文的目標是探索這個設計空間，比較這些方法在區塊鏈上部署時的情況。 當用戶需要在鏈上透明度和匿名性時，實用的RBE方案是明顯的贏家-克服了基於身份的加密的強烈信任假設，但代價高昂。

簡述三種方法

將加密金鑰與身份關聯的經典方法是使用公鑰基礎設施（PKI），其核心是公鑰目錄。這種方法需要潛在發送者與可信任的第三方（目錄的維護者或證書頒發機構）互動才能發送消息。此外，在web2環境中，維護該目錄可能會很昂貴、繁瑣且容易出錯, 而用戶面臨著風險,憑證機構的濫用.

密碼學家提出了繞過 PKI 問題的替代方案。在 1984 年，Adi Shamir建議基於身份的加密（IBE），其中一方的識別符號——電話號碼、電子郵件、ENS 域名——作為公鑰。這消除了維護公鑰目錄的需要，但代價是引入了一個可信任的第三方（密鑰生成器）。丹·鮑內和馬修·富蘭克林提供了第一個實用的IBE構造2001年，國際教育局除了在封閉的生態系統中，如公司或政府部署也許是由於強烈的信任假設。(正如我們將在下面看到的，這種假設可以通過依賴一個可靠的當事方小組來部分緩解，而區塊鏈可以很容易地實現這一點。)

第三個選擇，基於註冊的加密（RBE），提議在2018年，RBE保持了與IBE相同的一般架構，但將可信密鑰生成器替換為透明的“密鑰管理員”，該管理員僅對公共數據進行計算（具體而言，它將公鑰累積到一種公開可用的“摘要”中）。這個密鑰管理員的透明性使得區塊鏈環境（智能合約可以擔任管理員角色）非常適合RBE。RBE在2022年之前一直是理論上的，那時我和我的合著者們引入了...第一個實際有效的RBE建構.

評估權衡

這個設計空間很複雜，比較這些方案需要考慮許多維度。為了讓事情變得更簡單，我會做兩個假設：

1. 用戶不更新或撤銷他們的金鑰。
2. 智能合約不使用任何離鏈資料可用性服務（DAS）或 blob 資料。

我将在最后讨论每个附加考虑因素如何影响我们三种潜在的解决方案。

公鑰目錄

摘要: 任何人都可以通過調用智能合約將（id，pk）條目添加到鏈上表（目錄），前提是該ID尚未被索取。

一個去中心化的PKI基本上是一個智能合約，用於維護身份和它們對應的公鑰目錄。例如，以太坊名稱服務（ENS）註冊維護域名（“身份”）及其對應的元數據的映射，包括它們解析到的地址（從其交易可以派生公鑰的地址）。去中心化的PKI將提供更簡單的功能：合約維護的列表將僅存儲與每個ID相對應的公鑰。

要註冊，使用者生成一個金鑰對（或使用先前生成的密鑰對），並將其ID和公鑰發送到合約（可能與一些付款一起）。合約會檢查 ID 是否尚未被聲明，如果沒有，它將 ID 和公鑰添加到目錄中。此時，任何人都可以通過向合同請求與ID對應的公鑰來加密發送給註冊使用者的消息。 （如果寄件者之前對此使用者進行了加密，則不必再次詢問合同。使用公鑰，發送者可以像往常一樣加密其消息並將密文發送給收件者，收件者可以使用相應的密鑰來恢復消息。

讓我們來看看這個方法的屬性。

在賬簿的負面方面：

• 不夠簡潔。完整的金鑰目錄需要存儲在鏈上，因此始終對每個人都可用（請記住，目前我們假設沒有DAS）。對於大約 900K 在撰寫本文時，ENS 中註冊的獨特域名數量這意味著近90MB的持久性存儲。 註冊方需要支付其條目佔用的存儲空間，約65K gas（目前約為1美元-請參見下面的性能評估）。
• 有些互動式加密。發件人需要讀取鏈條以檢索用戶的公鑰，但僅在發送者首次對該特定用戶加密消息時才需要。 （請記住，我們假設用戶不會更新或撤銷其密鑰。）
• 不是寄件者匿名。當您檢索某人的公鑰時，您將自己連結到收件者，表明您與他們有某種關係。例如，想像一下你檢索維琪解密的公鑰：這可能會讓人懷疑你正在洩露機密檔。此問題可以通過「覆蓋流量」（檢索大量密鑰，其中大部分您不打算使用）或類似的方式通過運行完整節點或私有資訊檢索 （PIR） 來緩解。

在积极的一面：

• 非交互式解密。使用者使用本地存儲的秘密金鑰解密消息，因此不需要任何交互。
• 透明的。用户和密钥列表完全公开，因此任何人都可以检查它们是否正确注册。
• 任意ID設置。構建並未事先限制ID的範圍；理論上，ID可以是任何內容。任意字符串（受特定合約實施和存儲的限制所限）。

何時可能要使用公鑰目錄？去中心化的公鑰目錄易於設置和管理，因此它是一個很好的基線選擇。但是，如果存儲成本或隱私是一個問題，下面的其他選項之一可能是更好的選擇。

(閾值)身分證加密(IBE)

摘要：用户的身份是他们的公钥。需要信任的第三方或多方来发放密钥，并持有系统的生命周期内的主秘钥（陷门）。

在IBE中，用戶不生成自己的密鑰對，而是向可信的密鑰生成器註冊。密鑰生成器擁有一對“主”密鑰（圖中的msk，mpk）。根據用戶的ID，密鑰生成器使用主秘密鑰msk和ID來計算用戶的秘密鑰。該秘密鑰必須通過安全通道與用戶通信（可以通過建立一個安全通道來實現），金鑰交換協議).

IBE 優化了發送者的體驗：一旦下載了密鑰生成器的 mpk，它就可以使用 ID 本身將消息加密給任何 ID。解密也很簡單：註冊用戶可以使用密鑰生成器發放的密鑰來解密密文。

產生金鑰的主秘密金鑰比較持久由可信设置仪式产生的“有毒废料”用於某些SNARKs。 金鑰生成器需要它來發行任何新的秘密金鑰，因此金鑰生成器在設置後無法刪除它，就像SNARK儀式中的參與者所做的那樣。 這也是一個危險的信息。 擁有msk的任何人都可以解密發送給系統中任何用戶的所有消息。 這意味著存在常態性的外洩風險，並帶來災難性後果。

即使msk保持安全，系统中的每个注册用户也需要信任密钥生成器不会读取其消息，因为密钥生成器可以随时保留用户的密钥副本或从msk重新计算密钥。甚至可能密钥生成器向用户发出有故障或“受限制”的密钥，解密除密钥生成器确定的某些禁止消息之外的所有消息。

這種信任可以分散在一個關鍵生成器的法定人數之間，因此用戶只需信任其中一個閾值數量的生成器。在這種情況下，少數惡意的生成器無法恢復秘密鑰匙或計算出錯誤的鑰匙，攻擊者必須入侵多個系統才能竊取完整的主秘密。

如果使用者對這種信任假設感到滿意，（閾值）IBE 會帶來很多好處：

• 在鏈上存儲恆定/最小化。只需要在鏈上存儲主公鑰（一個單一的群元素）。這比在鏈上公鑰目錄所需的存儲要少得多。對於BN254曲線上的Boneh-Franklin IBE，這意味著在設置階段僅需增加64字節的持久在鏈存儲，服務僅需要花費40K gas。
• 非互動式加密。寄件者只需要主公鑰（在開始時下載一次）和收件者的ID來加密消息。這與公鑰目錄形成鮮明對比，在公鑰目錄中，它需要為每個要與之通信的新使用者檢索一個密鑰。
• 非互動式解密。用戶再次使用本地存儲的秘密金鑰解密消息。
• 寄件者匿名。寄件者不需要從鏈中檢索任何每個收件者的資訊。相比之下，在公鑰註冊表的情況下，發送方必須以依賴於接收方的方式與合約進行交互。
• 任意ID集。與在公鑰註冊表中一樣，ID 可以是任意字串。

但是！

• 強大的信任假設。與使用者生成自己的金鑰的公鑰註冊表不同，IBE 需要具有主密鑰（活板門）的受信任方或仲裁方來頒發密鑰。主密鑰必須在系統的整個生命週期內保留，如果洩露或濫用，可能會危及所有註冊使用者的消息。

您希望何時使用（閾值）國際教育局？如果有受信任的第三方或多方可用，並且用戶願意信任他們，與鏈上密鑰註冊管理機構相比，IBE 提供了更節省空間（因此更便宜）的選擇。

註冊式加密（RBE）

摘要：類似於IBE，用戶的身份作為其公鑰，但信任的第三方/法定人數被透明累加器（稱為“密鑰管理者”）取代。

在本節中，我將討論從有效的RBE構建我的論文, 由於不像(據我所知) 只有其他實用建設，它目前可以部署在區塊鏈上（採用基於配對而非晶格的方式）。每當我提到“RBE”時，我指的是這個特定的結構，儘管某些語句可能適用於一般的RBE。

在RBE中，用戶生成自己的密鑰對並計算一些從秘密鑰匙和共同參考字符串（CRS）派生的“更新值”（圖中的a）。儘管CRS的存在意味著設置並非完全不可信，但CRS是powers-of-tau施工，可以是在鏈上協作計算並且只要有一個誠實的貢獻，它就是安全的。

智慧合約是為預期數量的使用者 N 設置的，這些使用者分組到存儲桶中。當使用者在系統中註冊時，它會將其ID、公鑰和更新值發送到智能合約。智慧合約維護了一組公共參數pp（與CRS不同），可以認為它是系統中註冊的所有各方的公鑰的簡潔“摘要”。當它收到註冊請求時，它會對更新值執行檢查，並將公鑰乘以適當的pp桶。

註冊使用者還需要在本地維護一些「輔助資訊」，這些資訊用於説明解密，並在新使用者在同一存儲桶中註冊時附加這些資訊。他們可以通過監控區塊鏈在其存儲桶中的註冊來自行更新此值，或者智慧合約可以通過維護從最新註冊（例如，上周內）收到的更新值清單來提供説明，使用者可以定期（至少每週一次）提取。

在這個系統中，發送者只需下載CRS一次，偶爾下載公共參數的最新版本。對於發送者而言，公共參數中唯一重要的是包含了預期接收者的公鑰；它不必是最新版本。然後，發送者可以使用CRS和公共參數以及接收者ID，將消息加密給接收者。

接收到消息後，使用者會檢查其本地存儲的輔助信息，以確定是否通過某些檢查。 （如果沒有找到，則意味著需要從合約中獲取更新。）使用此值和其密鑰，使用者可以解密密文。

明顯地，這個方案比其他兩個更複雜。但是它需要的鏈上存儲比公鑰目錄少，同時避免了IBE的強信任假設。

• 簡潔的參數。要存儲在鏈上的參數的大小在用戶數量上是次線性的。這比公鑰目錄所需的總存儲空間（用戶數量呈線性）小得多，但仍然不是恆定的，因此與 IBE 相比更差。
• 有點互動式加密。要發送郵件，寄件者需要包含預期收件者的公共參數的副本。這意味著它需要在預期收件人註冊后的某個時間點更新參數，但不一定是針對註冊的每個預期收件者更新參數，因為一次更新可能包含多個收件者的密鑰。總體而言，消息發送比 IBE 更具交互性，但比目錄的交互性更差。
• 稍微互動式解密。與加密情況類似，收件人需要一份“匹配”用於加密的公共參數版本的輔助信息副本。更具體地說，每當新用戶在該存儲桶中註冊時，公共參數和輔助存儲桶都會更新，能夠解密密文的值是對應於用於加密的pp版本的值。與公共參數更新不同，用戶可以決定僅定期檢索輔助更新，除非解密失敗。與公共參數更新不同，更頻繁地檢索輔助更新不會本質上洩露信息。
• 發件人-匿名。就像在目錄案例中一樣，發件人可以在沒有查詢特定收件人信息的情況下完全自行加密消息（前提是擁有最新參數）。必要時從鏈中讀取的信息與預期收件人無關。（為了減少通信，發件人可以僅請求特定的pp存儲桶，從而泄露部分信息。）
• 透明的。儘管系統需要使用（可能分散式和/或外部管理的）受信任的設置儀式來設置，輸出被刺穿的CRS，但一旦設置完成，它就不依賴於任何受信任的一方或仲裁：儘管它依賴於協調的第三方（合同），但它是完全透明的，任何人都可以成為協調員或通過確認其狀態轉換來檢查他們的行為是否誠實（這就是為什麼它可以作為智慧合約實現）。此外，使用者可以要求提供簡潔（非）會員資格證明，以檢查他們（或其他任何人）是否在系統中註冊/未註冊。這與 IBE 案例形成鮮明對比，在 IBE 案例中，受信任方很難實際證明他們沒有秘密透露解密密鑰（通過製作秘密副本對自己或向其他人洩露）。另一方面，公鑰目錄是完全透明的。
• 設置受限ID。我已經描述了 RBE 結構的“基本”版本。要透明地確定ID屬於哪個存儲桶，ID必須具有公共和確定性排序。電話號碼可以簡單地按順序排列，但對任意字串進行排序即使不是不可能，也是笨拙的，因為存儲桶的數量可能非常大或不受限制。這可以通過提供計算此類映射的單獨合約或採用這項後續工作.

帶有擴展功能：

• 接收者匿名。該方案可以擴展，使得密文不會揭示接收者的身份。

什麼時候要使用 RBE？與鏈上註冊管理機構相比，RBE 使用的鏈上存儲更少，同時避免了 IBE 要求的強信任假設。與註冊管理機構相比，RBE還為寄件者提供了更強大的隱私保證。但是，由於 RBE 剛剛成為金鑰管理的可行選項，因此我們還不確定哪些方案將從這種屬性組合中受益最大。請讓我知道如果您有任何想法。

性能比較

我估計了在鏈上部署這三種方法的成本（截至 2024 年 7 月 30 日）這個Colab筆記本. 系統容量為約900K用戶的結果在撰寫本文時，ENS 註冊了獨特的域名）如下表所示。

PKI沒有設置成本，每個用戶的註冊成本很低，而IBE的設置成本很小，每個用戶幾乎免費註冊。儘管所需的鏈上存儲較低，但 RBE 具有更高的設置成本和出乎意料的高註冊成本。

註冊費用的大部分（假設計算在L2上完成）來自於各方必須更新一個公共參數的片段至持久性儲存，這導致了高昂的註冊費用。

儘管RBE比替代方案更昂貴，但該分析表明，它可以在當今的乙太坊主網上部署，而無需PKI或IBE的潛在風險信任假設。這是在優化之前，例如部署多個更小（因此更便宜）的實例或使用 blob 數據。鑒於 RBE 比公鑰目錄和 IBE 具有更強的匿名性和更少的信任假設的優勢，它可能對那些重視隱私和無信任設置的人有吸引力。

Noemi Glaeser是馬里蘭大學和馬克斯普朗克安全與隱私研究所的計算機科學博士候選人，並在 16 年夏天在 a23z 加密公司擔任研究實習生。她是NSF研究生研究獎學金的獲得者，之前曾在NTT Research擔任研究實習生。

附錄：其他注意事項

處理關鍵更新/撤銷

對於公鑰目錄，處理金鑰更新和吊銷很簡單：要撤銷金鑰，一方要求合約將其從目錄中刪除。要更新金鑰，條目 （id， pk） 將被 （id， pk'） 的新金鑰覆蓋。

在IBE中撤銷，Boneh和Franklin建議用戶定期更新他們的金鑰（例如，每週一次），並且在加密時發送者將當前時間段包含在身份字符串中（例如，“Bob ”）。由於加密的非交互性，發送者無法知道用戶何時撤銷其金鑰，因此一些時間段的更新是內在的。Boldyreva，Goyal和Kumar提出了一個更有效的撤銷機制基於“模糊”IBE解密需要兩個密鑰：一個“身份”密鑰和一個額外的“時間”密鑰。這樣，只需要定期更新時間密鑰。用戶的時間密鑰在一個二叉樹中積累，用戶可以使用路徑上的任何節點（在基本情況下，只需要根節點，並且它是由密鑰生成器發布的唯一部分）。密鑰撤銷通過不再為特定用戶發布更新（從樹中刪除該用戶的路徑上的節點）來實現，此時更新的大小增加，但永遠不會超過用戶數的對數。

我們高效的RBE構造並未考慮更新和撤銷，一個后续工作提供了一個編譯器，可以“升級”我們的方案以添加這些功能。

使用DAS將數據移出鏈外

使用數據可用性解決方案（DAS）將鏈上存儲移至鏈外只會影響公鑰目錄和RBE的計算，將兩者都減少到相同的鏈上存儲量。RBE仍然保持了對發件人更為私密的優勢，因為它仍然避免通過訪問模式洩露接收者的身份。IBE已經具有最小的鏈上存儲並不會從DAS中受益。

免責聲明：

1. 本文轉載自 [A16Z加密]，所有版權歸原作者所有[諾埃米·格萊澤 ]. 如果有對此轉載的異議，請聯繫Gate Learn團隊，他們會及時處理。
2. 免責聲明: 本文所表達的觀點和意見僅代表作者個人觀點，並不構成任何投資建議。
3. 由 Gate Learn 團隊負責將文章翻譯成其他語言。除非另有提及，禁止複製、分發或剽竊翻譯的文章。