a16z：公開鍵暗号の核心的課題を解決する3つの優れた選択肢
TechFlow厳選深潮セレクト
a16z：公開鍵暗号の核心的課題を解決する3つの優れた選択肢
現在、3つの解決策があります：公開鍵ディレクトリ、アイデンティティベース暗号（IBE）、および登録ベース暗号（RBE）。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Noemi Glaeser，a16z crypto
執筆：Chris，Techub News
公開鍵暗号において、常に解決が難しい問題として、暗号化キー（たとえば公開鍵）を特定の身元（個人や組織など）と正しく関連付ける方法があります。この問題の鍵は、身元と公開鍵の関係を誰もが確認できる形で一貫して示す仕組みを持つことであり、これにより人々が安心してその公開鍵を使って情報を暗号化できるようになります。
このような明確な関係がない場合、ある公開鍵が実際に誰に属しているのかを第三者が判断できず、結果として誤った相手に暗号化されたメッセージを送信してしまう可能性があり、情報漏洩などの深刻なリスクが生じます。Web3の世界でも、この問題は依然として存在しています。
上記の問題に対して、現在主に三つの解決策が提案されています。それは「公開鍵ディレクトリ（Public Key Directory）」「身元に基づく暗号化（IBE）」、および「登録に基づく暗号化（RBE）」です。これら三つのアプローチは、匿名性、相互作用性、効率性といった点でそれぞれ異なる長所を持っています。たとえば、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システムとは異なります。SNARKでは信頼されたセットアップで生成されても、セットアップ後に破棄可能です。一方、IBEでは初期化後にmskを削除することはできません。
たとえmskが適切に管理されていても、各登録ユーザーは、鍵生成者が自分のメッセージを読まないことを信頼しなければなりません。なぜなら、鍵生成者はいつでもユーザーの秘密鍵のコピーを保持したり、mskを使って再計算したりできるからです。
さらに、鍵生成者はユーザーに「問題のある」あるいは「制限付き」の秘密鍵を提供する可能性があります。この鍵は大部分のメッセージを復号できるものの、鍵生成者が意図的に除外した特定のメッセージは復号できないというものです。つまり、鍵生成者はユーザーの復号能力を操作でき、通信に対して何らかの制御や制限を課すことが可能になります。
登録に基づく暗号化（RBE）
IBEと同様に、このシステムではユーザーの身元（電子メールアドレスや電話番号など）がそのまま公開鍵として機能します。しかし、RBEは信頼された第三者やquorumのグループに依存しません。代わりに、「key curator（鍵管理者）」と呼ばれる仕組みが導入されます。
ここでは、私が知る限り最も実用的で効率的なRBE構成について説明します。この構成は、lattice-basedではなくpairing-basedであるため、ブロックチェーン上に展開可能な点で他の実用的なRBE構成よりも顕著な利点を持っています。
RBEシステムでは、各ユーザーが自ら鍵ペア（公開鍵・秘密鍵）を生成します。さらに、ユーザーは自身の秘密鍵と「共通参照文字列（CRS）」を用いて、いくつかの更新値（図中では a と表記）を計算する必要があります。これらの更新値はシステム内の後続操作に使用されます。CRSの存在は、システムのセットアップが完全に信頼不要ではないことを意味します。しかし、CRSは「tauのべき乗」という方式で生成され、ブロックチェーン上で複数の参加者が協力して計算できます。少なくとも一人の参加者が誠実であれば、CRSは安全であるとみなされます。
スマートコントラクトは、予想されるユーザー数Nに対してセットアップされており、ユーザーはグループごとに分類されたバケツ（buckets）に割り当てられます。ユーザーがシステムに登録する際には、自身のID、公開鍵、および更新値をスマートコントラクトに送信します。スマートコントラクトは「共通パラメータ pp」と呼ばれる一連の公開パラメータを維持しており、これは前述のCRSとは異なります。ppは、システムに登録されたすべてのユーザーの公開鍵の簡潔な要約と理解できます。コントラクトは更新値の正当性を検証し、承認されれば、ユーザーの公開鍵を対応するバケツ内のppに掛けて統合します。この操作により、新規ユーザーの公開鍵がシステムの共通パラメータ集合に含まれるようになります。
RBEシステムでは、ユーザーはメッセージを復号するために必要な補助情報をローカルに保存する必要があります。同じグループに新しいユーザーが登録された場合、これらの情報は更新する必要があります。ユーザーはブロックチェーンを自ら監視して手動で更新してもよいですし、スマートコントラクトが最新の登録情報を提供するため、定期的に取得して補助情報を最新の状態に保つこともできます。
このシステムでは、送信者は次の二つのことを行えば十分です：
共通参照文字列（CRS）をダウンロードする：これは初回のみ必要で、以降は更新不要です。
共通パラメータをダウンロードする：送信者は時折最新の共通パラメータを取得する必要があります。重要なのは、このパラメータに受信者の公開鍵が含まれていればよく、必ずしも最新版を毎回取得する必要はありません。
その後、送信者はダウンロードしたCRS、共通パラメータ、および受信者のIDを用いてメッセージを暗号化し、受信者に送信できます。つまり、送信者は頻繁にデータを更新する必要はなく、受信者の公開鍵がパラメータに含まれていれば十分です。
ユーザーが暗号化されたメッセージを受信すると、まずローカルに保存されている補助情報の中で、特定の条件（たとえば検証チェックを通過する値）を満たすものがあるかを確認します。もし見つからない場合は、スマートコントラクトから最新の更新情報を取得する必要があります。適切な補助情報を見つけたら、それを自身の秘密鍵とともに使って暗号文を復号し、元のメッセージを復元します。
明らかに、この方式は他の二つよりも複雑ですが、オンチェーンのストレージ要件は公開鍵ディレクトリより少なく、またIBEのような強い信頼前提を回避できます。
簡潔なパラメータ：
オンチェーンに保存されるパラメータのサイズは、ユーザー数に対して準線形的です。これは、ユーザー数に比例して増加する公開鍵ディレクトリに比べて大幅に小さいですが、定数サイズではないため、IBEほどは優れていません。
ある程度の相互作用を伴う暗号化：
メッセージ送信時には、送信者が受信者の含まれる共通パラメータのコピーを持っている必要があります。つまり、受信者が登録された後のある時点でパラメータを更新する必要がありますが、各受信者ごとに個別に更新する必要はなく、一度の更新で複数の鍵を含めることができます。全体としては、IBEよりも相互作用が多いですが、公開鍵ディレクトリを使う場合よりは少ないです。
ある程度の相互作用を伴う復号：
暗号化と同様に、受信者は暗号化時に使用されたバージョンの共通パラメータに対応する補助情報を持っている必要があります。あるグループに新規ユーザーが登録されると、共通パラメータと補助情報が更新され、復号可能な値は暗号化時のパラメータバージョンに対応します。ユーザーは解読に失敗しない限り、補助情報を定期的に取得するだけでよく、即時更新を強制されるわけではありません。また、共通パラメータの更新とは異なり、補助情報を頻繁に取得してもプライバシーが漏洩することはありません。
送信者匿名性：
公開鍵ディレクトリの場合と同様に、送信者は最新のパラメータを持っていれば、受信者に関する特定の情報を照会せずに独立してメッセージを暗号化できます。送信者がチェーン上から情報を読み取る場合でも、それが目標受信者と直接関連するものではありません（特定のパラメータバケツだけを要求すると、一部の情報を漏らす可能性がありますが）。
透明性：
システムは信頼されたセットアップ（分散型または外部管理による）を必要とし、修正されたCRSを出力しますが、一旦セットアップが完了すれば、それ以降は信頼された第三者や仲裁グループに依存しません。確かに、調整役としてのスマートコントラクトに依存しますが、このシステムは完全に透明であり、誰でも調整者となり得ます。また、状態遷移の検証を通じて、その実行が誠実であるかをチェックできます（これがスマートコントラクトとして実装可能な理由です）。さらに、ユーザーは簡潔な（非）メンバーシップ証明を要求することで、自分や他人がシステムに登録されているかを確認できます。これはIBEとは対照的です。IBEでは、信頼された第三者が秘密鍵を密かに漏らしていない（例：コピーを保持したり、他者に漏らしたりしていない）ことを証明することが困難です。一方、公開鍵ディレクトリは完全に透明です。
制限されたID集合：
ここで説明しているのはRBE構成の基本形です。IDがどのバケツに属するかを透明に決定するためには、IDに公開かつ確定的な順序が必要です。電話番号は単純に並べ替え可能ですが、任意の文字列をソートするのは非常に複雑、あるいは不可能な場合があります。特にバケツの数が非常に多く、あるいは無限の場合です。この問題は、マッピングを計算する別のコントラクトを提供する、あるいは後続研究で提案されたcuckoo-hashingの手法を用いることで緩和できます。
受信者匿名性：
この方式により、暗号文が受信者の身元を漏らすことはありません。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
a16z
