a16z：解決公鑰密碼學核心難題的三種優選方案

撰文：Noemi Glaeser，a16z crypto

撰文：Chris，Techub News

在公鑰密碼學中，一直以來都有一個難題，那就是如何將加密密鑰（如公鑰）正確地與一個具體的身份（比如某個人或組織）關聯起來。這個問題的關鍵在於，要有一種公開且一致的方式來顯示身份和公鑰之間的關係，這樣大家才能放心地使用這些公鑰來加密信息。

如果沒有這樣明確的關係，別人可能無法確定某個公鑰到底屬於誰，這樣就有可能把加密信息發送給錯誤的人，導致信息洩露或其它嚴重的後果。在 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對應的公鑰，以便加密發送消息給該用戶，如果發送者之前已經加密過消息給這個用戶，並且已經有了該用戶的公鑰，就不需要再次向智能合約請求公鑰。有了公鑰後，發送者可以像平常一樣使用它來加密消息，然後將加密後的消息發送給接收者，接收者使用對應的私鑰來解密消息，恢復原文。

我們來看看這個方法的優點和缺點：

基於身份的加密 (IBE)

用戶的身份由他們的公鑰來表示，也就是說，公鑰不僅用於加密，還可以作為用戶的唯一標識符。但是這種方法需要依賴於一個或多個值得信賴的第三方，這些第三方負責生成並發放密鑰。此外，這些第三方還需要在係統的整個生命周期内保管一個主密鑰，這個主密鑰在某些情況下可能用於解密或其他重要操作。

在IBE係統中，用戶並不像傳統加密係統中那樣自己生成一對公鑰和私鑰。相反，用戶需要使用一個受信任的密鑰生成器注冊。密鑰生成器擁有一對主密鑰（包括主私鑰 msk 和主公鑰 mpk）。當用戶提供自己的 ID 時，密鑰生成器會使用主私鑰 msk 和用戶的ID來計算出一個專屬於該用戶的私鑰。生成的私鑰需要通過一個安全的渠道傳遞給用戶，一般來說都是使用密鑰交換協議來建立這個安全通道。

對於發送者來說，IBE係統簡化了加密過程。發送者只需要下載一次密鑰生成器的主公鑰（mpk），之後就可以使用 ID 來加密消息。對於接收者來說，解密也很簡單。注冊用戶可以使用密鑰生成器發給他們的私鑰來解密收到的密文。

密鑰生成器的主私鑰（msk）必須長期保留，因為它在係統運行期間需要不斷地生成新的用戶私鑰。這與某些 SNARK 係統中不同，後者在受信任的設置過程中生成，但可以在設置完成後銷毀。而在IBE係統中，主私鑰不能像SNARK中那樣在初始化後刪除。

即使主私鑰（msk）保管得當，每個注冊用戶仍然需要信任密鑰生成器不會讀取他們的消息。這是因為密鑰生成器可以隨時保存一份用戶私鑰的副本，或者利用主私鑰重新計算出用戶的私鑰。

密鑰生成器還有可能給用戶提供一個有問題或受限的私鑰，這種私鑰可以解密大部分消息，但無法解密某些密鑰生成器設定的特定消息。這意味著密鑰生成器有能力操控用戶的解密能力，從而可能對用戶的通信進行某種程度的控制或限制。

基於注冊的加密 (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 方法來緩解這種復雜性。

收件人匿名：

• 這種方法可以讓密文不會洩露收件人的身份。

内容来源：TECHUB NEWS