暗号キーをアイデンティティにリンクすることは、以来問題となっています技術の導入. 課題は、アイデンティティと公開鍵（そのアイデンティティにプライベートキーがある公開鍵）の間の一貫したマッピングを提供し、維持することです。このようなマッピングがないと、秘密にすべきメッセージがうまくいかないことがあります。同じ課題はweb3でも存在します。

現在、考えられる解決策は 3 つあります。古典的なアプローチは、公開キー ディレクトリと ID ベースの暗号化の 2 つです。3つ目はレジストレーションベースの暗号化で、最近までは完全に理論上のものでした。3つのアプローチは、匿名性、双方向性、効率性の間で異なるトレードオフを提供し、最初は明らかに思えるかもしれませんが、ブロックチェーンの設定は新しい可能性と制約をもたらします。したがって、この投稿の目的は、この設計空間を探索し、ブロックチェーンに展開した場合のこれらのアプローチを比較することです。ユーザーがオンチェーンで透明性と匿名性を必要とする場合、実用的なRBEスキームが明らかに勝者であり、IDベースの暗号化の強力な信頼性の前提を克服しますが、コストがかかります。

簡単に説明すると、3つのアプローチ

暗号化キーを ID にリンクする従来のアプローチは、公開キー ディレクトリを中心とする公開キー基盤 (PKI) です。このアプローチでは、潜在的な送信者が信頼できるサード パーティ (ディレクトリのメンテナーまたは認証局) と対話してメッセージを送信する必要があります。さらに、web2 の設定では、このディレクトリを維持するのはコストがかかり、面倒で、エラーの発生しやすさ、そしてユーザーはリスクを冒す可能性があります証明書発行局による悪用.

暗号学者はPKIの問題を回避するための代替手段を提案しています。1984年に、Adi Shamir suggestedアイデンティティベースの暗号化（IBE）は、当事者の識別子（電話番号、メール、ENSドメイン名）が公開鍵として機能する方式である。これにより、公開鍵ディレクトリを維持する必要がなくなるが、信頼できる第三者（鍵ジェネレータ）が導入されるため、コストがかかる。Dan BonehとMatthew Franklinが提供した。 Gate.io最初の実用的なIBE構築2001年には考案されましたが、IBEは企業内などの閉じたエコシステム以外での広範な採用は受けていません。政府の展開おそらく強い信頼の前提によるものです。(後で見るように、この前提は部分的に緩和される可能性があります。代わりに信頼できる当事者のコーラムに依存することで、これはブロックチェーンが容易に促進できます。)

第3のオプションである登録ベースの暗号化（RBE）は、提案された2018年、RBEはIBEと同じ一般的なアーキテクチャを維持していますが、信頼できる鍵ジェネレーターを透明な「鍵キュレーター」で置き換えることで、公開データ上での計算のみを行います（具体的には、公開鍵を一種の公開可能な「ダイジェスト」に累積します）。この鍵キュレーターの透明性により、スマートコントラクトがキュレーターの役割を果たすことができるブロックチェーン設定は、RBEにとって自然な適合となります。私たちの共同著者と私が導入した2022年まで、RBEは理論的なものでした。最初の実用的な有効なRBE構築.

トレードオフの評価

このデザインスペースは複雑であり、これらのスキームを比較するには多くの要素を考慮する必要があります。簡単にするために、2つの仮定をします:

1. ユーザーは、キーを更新したり取り消したりしません。
2. スマートコントラクトは、オフチェーンデータ可用性サービス（DAS）やblobデータを使用しません。

これらの追加の考慮事項が、私たちの3つの潜在的な解決策にどのように影響するかについては、最後に議論します。

公開鍵ディレクトリ

要約：誰でも、IDがまだ請求されていない場合は、スマート契約を呼び出すことで、（id、pk）エントリをオンチェーンテーブル（ディレクトリ）に追加できます。

分散型PKIは、本質的には、アイデンティティとそれに対応する公開鍵のディレクトリを維持するスマートコントラクトです。例えば、イーサリアムネームサービス（ENS）レジストリドメイン名 (「ID」) とそれに対応するメタデータ (解決先のアドレス (公開鍵を派生させることができるトランザクション) を含む) のマッピングを維持します。分散型PKIは、さらにシンプルな機能を提供します:コントラクトによって維持されるリストは、各IDに対応する公開鍵のみを格納します。

登録するために、ユーザーは鍵ペアを生成する（または以前に生成された鍵ペアを使用する）と、そのIDと公開鍵を契約に送信します（おそらくいくらかの支払いとともに）。契約は、IDがまだ要求されていないことを確認し、要求されていない場合は、IDと公開鍵をディレクトリに追加します。この時点で、登録されたユーザーへのメッセージを暗号化するために、誰でもIDに対応する公開鍵を契約に問い合わせることができます（送信者が以前にこのユーザーに何かを暗号化している場合、再度契約に問い合わせる必要はありません）。公開鍵を使用して、送信者は通常通りメッセージを暗号化し、暗号文を受信者に送信することができます。受信者は対応する秘密鍵を使用してメッセージを復号化することができます。

このメソッドのプロパティを見てみましょう。

負の面では、

• 簡潔ではありません。完全なキー ディレクトリをオンチェーンに保存する必要があります。これにより、常に誰にでも利用可能になります（今のところ、DAS はないと仮定しています）。約 900K この記事の執筆時点でENSに登録されている一意のドメイン名これは、ほぼ90MBの永続的なストレージを意味します。登録する各当事者は、エントリが占めるストレージに対して支払いをする必要があります。約65Kガス（現在のところおよそ$1 - パフォーマンス評価を参照）。
• ややインタラクティブな暗号化。送信者は、ユーザーの公開キーを取得するためにチェーンを読み取る必要がありますが、送信者がその特定のユーザーへのメッセージを暗号化するのが初めての場合に限ります。(ユーザーがキーを更新したり取り消したりしないことを前提としています。
• 送信者匿名ではありません。誰かの公開鍵を取得すると、それは受信者とあなた自身を関連付け、あなたが彼らと何らかの関係を持っていることを示します。例えば、WikiLeaksの公開鍵を取得した場合、これは機密文書を漏洩している可能性があるという疑いを生む可能性があります。この問題は、「カバートラフィック」（使用するつもりのない大量の鍵を取得する）やフルノードの実行、またはプライベート情報検索（PIR）によって緩和することができます。

ポジティブな側面では:

• 非対話型の復号化。ユーザーはローカルに保存された秘密鍵でメッセージを復号化するため、相互作用は必要ありません。
• 透明です。ユーザーとキーのリストは完全に公開されているため、誰でも正しく登録されたかどうかを確認できます。
• 任意のIDセット。構築に先立ってIDのドメインは理論上制限されていません。理論上、IDは任意の文字列(特定のコントラクトの実装とストレージによって課せられる制約まで)。

公開鍵ディレクトリを使用したい場合はいつですか？ 分散型の公開鍵ディレクトリは設定と管理が簡単なため、それが良いベースラインの選択肢です。ただし、ストレージコストやプライバシーに関心がある場合は、以下の他のオプションの1つがより良い選択肢になるかもしれません。

(閾値) Identity-Based Encryption (IBE)

概要: ユーザーの ID は公開鍵です。鍵を発行し、システムの存続期間中、マスターシークレット(トラップドア)を保持するには、信頼できる第三者が必要です。

IBE では、ユーザーは独自のキー ペアを生成せず、代わりに信頼できるキー ジェネレーターに登録します。キージェネレータには、「マスター」キーペア(図のmsk、mpk)があります。ユーザーのIDが与えられると、キージェネレータはマスター秘密鍵mskとIDを使用してユーザーの秘密鍵を計算します。その秘密鍵は、安全なチャネルを介してユーザーに伝達する必要があります (鍵交換プロトコル).

IBEは送信者の体験を最適化します：送信者はキージェネレータのmpkを一度ダウンロードすると、ID自体を使用して任意のIDにメッセージを暗号化できます。復号も簡単です：登録ユーザーはキージェネレータから発行された秘密鍵を使用して暗号文を復号化することができます。

鍵生成器のマスターシークレットキーは、より持続的です「信頼性のあるセットアップの儀式」で生成される「有害廃棄物」SNARKの一部で使用されます。キー生成器は、新しい秘密キーを発行するためにそれが必要ですので、SNARKセレモニーの参加者が行うようにキー生成器はそれをセットアップ後に消去することはできません。また、これは危険な情報でもあります。mskを持つ人は、システム内の任意のユーザーに送信されたすべてのメッセージを復号化することができます。これは、壊滅的な結果をもたらすデータの持ち出しの恒常的なリスクを意味します。

mskが安全に保管されていても、システムに登録するすべてのユーザーは、キージェネレータがメッセージを読まないように信頼する必要があります。なぜなら、キージェネレータはユーザーの秘密鍵のコピーを保持したり、いつでもmskから再計算したりすることができます。また、キージェネレータがユーザーに誤ったまたは「制約された」秘密鍵を発行して、キージェネレータによって決定された一部の禁止されたメッセージを除くすべてのメッセージを復号化する可能性さえあります。

この信頼は、代わりに鍵生成者のクォーラムの間で分散することができます。その場合、ユーザーはしきい値の数のみを信頼する必要があります。この場合、わずかな数の悪意のある鍵生成者は秘密鍵を回復したり、悪い鍵を計算したりすることはできず、攻撃者は完全なマスターシークレットを盗むために複数のシステムに侵入する必要があります。

もしユーザーがこの信頼の前提を受け入れることができるなら、(閾値) IBEには多くの利点があります。

• Constant/minimal on-chain storage. Only the master public key (a single group element) needs to be stored on-chain. This is much less than the storage required by an on-chain public key directory. For the Boneh-Franklin IBE over the BN254 curve, this means adding 64 bytes of persistent on-chain storage once during the setup phase, requiring the service to spend only 40K gas.
• 非対話型の暗号化。送信者は、メッセージを暗号化するために、マスター公開鍵 (最初に一度ダウンロードします) と受信者の ID のみを必要とします。これは、通信する新しいユーザーごとにキーを取得する必要がある公開キーディレクトリとは対照的です。
• Non-interactive decryption. Again, users use their locally-stored secret keys to decrypt messages.
• Sender-匿名。送信者は、チェーンから受信者ごとの情報を取得する必要はありません。一方、公開鍵レジストリの場合、送信者は受信者に依存する方法で契約とやり取りする必要があります。
• 任意の ID が設定されています。公開鍵レジストリと同様に、ID は任意の文字列にすることができます。

でも!

• 強い信頼の前提。ユーザーが独自の鍵を生成する公開鍵レジストリとは異なり、IBEでは、鍵を発行するには、マスターシークレット(トラップドア)を持つ信頼できるパーティまたはパーティのクォーラムが必要です。マスターシークレットは、システムの存続期間全体にわたって保持する必要があり、リークまたは誤用された場合、すべての登録ユーザーのメッセージを危険にさらす可能性があります。

いつ(しきい値)IBEを使用したいと思うか？信頼できる第三者または複数の第三者が利用可能で、ユーザーがそれらを信頼することができる場合、IBEはオンチェーンのキーレジストリと比較して、よりスペース効率の良い（したがってより安価な）オプションを提供します。

登録ベースの暗号化（RBE）

概要：IBEに類似し、ユーザーのアイデンティティが彼らの公開鍵として機能しますが、信頼できる第三者/クオーラムは透明なアキュムレーター（「キーキュレーター」と呼ばれる）に置き換えられます。

このセクションでは、「」から効率的なRBE構築について説明します。私の論文(私の知る限り)とは異なり、唯一の他の実用的な構築、現在ブロックチェーン上に展開可能です(格子ベースではなくペアリングベース)。私が「RBE」と言うときはいつでも、この特定の構造を意味しますが、いくつかの記述は一般的にRBEに当てはまるかもしれません。

RBEでは、ユーザーは独自のキーペアを生成し、秘密鍵と共通参照文字列（CRS）から導出された「更新値」（図中のa）を計算します。CRSが存在することは、セットアップが完全に信頼できないことを意味しますが、CRSは暗号化されます。powers-of-tau建設は、オンチェーンで共同計算されたそして、少なくとも1つの正直な貢献がある限り、それは安全です。

スマートコントラクトは、予想されるユーザー数Nに設定され、バケツにグループ化されます。ユーザーがシステムに登録すると、そのID、公開鍵、および更新値をスマートコントラクトに送信します。スマートコントラクトは、公開パラメータpp（CRSとは異なる）のセットを維持し、これはシステムに登録されたすべての当事者の公開鍵の簡潔な「ダイジェスト」と考えることができます。登録リクエストを受信すると、更新値に対してチェックを行い、公開鍵をppの適切なバケツに乗算します。

登録されたユーザーは、ローカルにいくつかの「補助情報」を保持する必要もあります。これは復号を支援するために使用され、新しいユーザーが同じバケットに登録するたびに追加されます。ユーザーは、自分のバケット内の登録情報を監視することでこれを自分で更新することができます。または、スマートコントラクトは、最新の登録から受信した更新値のリストを保持することでユーザーを支援することができます（たとえば、過去1週間以内の登録）。ユーザーは定期的に（少なくとも1週間に1回）これを取得できます。

このシステムの送信者は、一度CRSをダウンロードし、時折最新バージョンの公共パラメータをダウンロードします。公共パラメータについては、送信者の視点から重要なのは、意図された受信者の公開鍵が含まれていることだけで、最新バージョンである必要はありません。送信者はその後、CRSと公共パラメータ、受信者IDを使用して、受信者にメッセージを暗号化することができます。

メッセージを受信すると、ユーザーはローカルに保存されている補助情報をチェックして、何らかのチェックに合格した値を確認します。(何も見つからない場合は、コントラクトから更新を取得する必要があることを意味します)。この値とその秘密鍵を使用して、ユーザーは暗号文を復号化できます。

明らかに、このスキームは他の2つよりも複雑です。しかし、公開鍵ディレクトリよりもオンチェーンストレージが少なくて済み、同時にIBEの強い信頼前提を回避しています。

• 簡潔なパラメータ。オンチェーンに保存されるパラメータのサイズは、ユーザー数ではサブリニアです。これは、公開キー ディレクトリに必要な合計ストレージ (ユーザー数で直線的) よりもはるかに小さいですが、それでも一定ではないため、IBE と比較すると劣ります。
• ややインタラクティブな暗号化。メッセージを送信するには、送信者が意図した受信者を含む公開パラメータのコピーが必要です。つまり、意図した受信者が登録した後のある時点でパラメータを更新する必要がありますが、登録する受信者ごとに必ず更新する必要はありません。なぜなら、1つの更新に複数の受信者のキーを含めることができるからです。全体的に、メッセージの送信はIBEよりもインタラクティブ性が高く、ディレクトリよりもインタラクティブ性が低いです。
• ややインタラクティブな復号化。暗号化の場合と同様に、受信者は、暗号化に使用されるパブリックパラメータのバージョンと「一致」する補助情報のコピーを必要とします。具体的には、public パラメータと aux バケットの両方が、そのバケットに新しいユーザーが登録されるたびに更新され、暗号文を復号できる値 a は、暗号化に使用された pp バージョンに対応する値です。パブリック パラメーターの更新と同様に、ユーザーは、復号化が失敗した場合を除き、定期的にのみ aux 更新を取得することを決定できます。パブリック パラメーターの更新とは異なり、補助更新プログラムをより頻繁に取得しても、本質的に情報が漏洩することはありません。
• 送信者は匿名です。ディレクトリの場合と同様に、送信者は受信者固有の情報を問い合わせることなく、独自にメッセージを完全に暗号化できます（最新のパラメータを持っている場合）。必要に応じてチェーンから読み取られる情報は、意図された受信者に独立しています。（通信を減らすために、送信者は特定のppバケットのみを要求して、部分的な情報を漏らすことができます。）
• 透明。システムは、パンクしたCRSを出力する(潜在的に配布および/または外部で管理される)信頼できるセットアップセレモニーを使用してセットアップする必要がありますが、セットアップが完了すると、信頼できるパーティやクォーラムに依存しません:調整する第三者(コントラクト)に依存していますが、完全に透過的であり、誰でもコーディネーターになることができ、その状態遷移を確認することで正直に振る舞っていることを確認できます(そのため、スマートコントラクトとして実装されます)。さらに、ユーザーは、自分(または他の誰か)がシステムに登録されているかどうかを確認するために、簡潔な(非)メンバーシップの証明を求めることができます。これは、信頼できる当事者が(秘密のコピーを作成することによって自分自身に、または他の誰かに)復号化キーを秘密裏に明らかにしなかったことを実際に証明することが困難であるIBEのケースとは対照的です。一方、公開鍵ディレクトリは完全に透過的です。
• 制限付き ID が設定されています。ここまで、RBE構造の「基本」バージョンについて説明しました。ID がどのバケットに分類されるかを透過的に判断するには、ID にパブリックで決定論的な順序付けが必要です。電話番号は簡単に順番に並べることができますが、バケットの数が極端に多かったり、無制限だったりする可能性があるため、任意の文字列を並べ替えることは不可能ではないにしても扱いにくいです。これは、そのようなマッピングを計算する別のコントラクトを提供するか、 で提案されているカッコウハッシュアプローチを採用することによって軽減できます。このフォローアップ作業.

拡張機能を使用して:

• 受信者匿名。このスキームは、暗号文が受信者の身元を明らかにしないように拡張できます。

RBEを使用するタイミングはいつですか？ RBEはオンチェーンのレジストリよりも少ないオンチェーンのストレージを使用し、同時にIBEに必要な強力な信頼の前提条件を回避します。レジストリと比較して、RBEは送信者により強力なプライバシー保証を提供します。ただし、RBEはキー管理のための実用的なオプションとして現在できたばかりなので、どのようなシナリオがこれらの特性の組み合わせから最も利益を得るかはまだわかりません。お願いします 教えてくださいもし何かアイデアがあれば。

パフォーマンス比較

2024年7月30日現在、これら3つのアプローチをそれぞれオンチェーンで展開するためのコストを見積もってみました。このColabノートブックシステム容量が約900Kユーザー（「」の数）の結果この執筆時点でENSで登録されているユニークなドメイン名）は、以下の表に示されています。

PKIのセットアップコストはなく、ユーザーごとの登録コストも低いですが、IBEは小さなセットアップコストと実質的に無料のユーザーごとの登録コストがあります。RBEはセットアップコストが高く、オンチェーンストレージが必要ないにもかかわらず、予想外に高い登録コストがあります。

登録コストの大部分は（計算がL2上で行われる場合）当事者が永続的なストレージにパブリックパラメータの一部を更新する必要があるためであり、これにより高い登録コストになっています。

RBEは他の代替手段よりも高価ですが、この分析では、PKIまたはIBEの潜在的にリスキーな信頼仮定を必要とせずに、現在のEthereumメインネットに実装することが可能であることが示されています。さらに、複数のより小さな（したがってより安価な）インスタンスの展開やブロブデータの使用などの最適化を行うこともできます。公開鍵ディレクトリとIBEに比べて、RBEはより強い匿名性と信頼仮定の減少という利点があり、プライバシーや信頼性を重視する人々に魅力的なものとなる可能性があります。

Noemi Glaeserメリーランド大学とマックス・プランク・セキュリティ&プライバシー研究所でコンピューターサイエンスの博士号を取得しており、23年の夏にはa16z cryptoで研究インターンを務めていました。NSF Graduate Research Fellowshipの受賞者であり、以前はNTTリサーチでリサーチインターンを務めていました。

付録：追加の考慮事項

鍵の更新/取り消しに対処する

公開鍵ディレクトリの場合、鍵の更新と失効処理は簡単です。鍵を失効させるには、当事者は契約にディレクトリから削除するように要求します。鍵を更新するには、エントリ（id、pk）は新しい鍵（id、pk'）で上書きされます。

IBEでの失効について、BonehとFranklinは、ユーザーが定期的に(例えば、毎週)鍵を更新し、送信者が暗号化時にID文字列に現在の期間を含めることを提案しました(例:「Bob 」)。暗号化の非対話型の性質により、送信者はユーザーがいつキーを取り消すかを知る方法がないため、一部の期間更新が本質的に行われます。Boldyreva、Goyal、Kumarは、より効率的な失効メカニズムに基づいて「Fuzzy」IBE暗号化には「アイデンティティ」キーと追加の「時間」キーの2つが必要です。これにより、定期的に更新する必要があるのは時間キーだけです。ユーザーの時間キーはバイナリツリーに蓄積され、ユーザーはパス上の任意のノードを使用できます（基本的な場合、ルートのみが必要で、キー生成器によって公開される唯一の部分です）。キーの取り消しは、特定のユーザーのために更新を公開しなくなることによって達成されます（そのユーザーのパスに沿ったノードをツリーから削除する）、この場合、更新のサイズは増加しますが、ユーザー数の対数にすぎません。

私たちの効率的なRBE構築では、更新と失効は考慮されていませんでした。フォローアップ作業これらの機能を追加するために、私たちのスキームを「アップグレード」できるコンパイラを提供します。

DASを使用して、データをオフチェーンに移動する

オンチェーンストレージをオフチェーンに移動するためにデータ可用性ソリューション（DAS）を使用すると、公開鍵ディレクトリとRBEの計算のみに影響を与え、両方を同じオンチェーンストレージ量に減らすだけです。 RBEは、アクセスパターンを介した受信者のアイデンティティの漏洩を回避するため、送信者にとってよりプライベートであるという利点を維持します。 IBEは既に最小限のオンチェーンストレージを持っており、DASの恩恵を受けることはありません。

免責事項：

1. この記事は[a16zcrypto], すべての著作権は元の作者に帰属します [ Noemi Glaeser]. この転載に異議がある場合は、お問い合わせください。ゲート学習チーム、そして彼らはそれを迅速に処理します。
2. 免責事項：本記事に表明された見解や意見は、著者個人のものであり、投資助言を提供するものではありません。
3. 他の言語への翻訳は Gate Learn チームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。