a16zが公開鍵暗号学の中核的な難題を解決するための3つの選択肢

ソース: Noemi Glaeser, a16z crypto

公開鍵暗号技術では、常に一つの問題があります。それは、暗号化された秘密鍵（公開鍵など）を具体的な身元（個人や組織など）と正しく関連付ける方法です。この問題の鍵は、身元と公開鍵の関係を公開かつ一貫して表示する方法が必要であり、これによって皆が安心してこれらの公開鍵を使用して情報を暗号化できるようになります。

もし明確な関係がない場合、他の人はどの公開鍵が誰のものかを確定できない可能性があり、そのために誤った人に暗号化された情報を送ってしまい、情報漏洩やその他の深刻な結果を引き起こす可能性があります。Web3でも、この問題は依然として存在しています。

上記の問題に対して、現在はPublic Key Directory、身元ベースの暗号化（IBE）、および登録ベースの暗号化（RBE）の3つの解決策があります。これら3つの方法には、匿名性、相互作用性、および効率面でそれぞれ利点があります。例えば、IBEは強力な信頼基盤を必要としますが、一部の場合においては、IBEが匿名性と効率性において優れた性能を発揮することがあります。本稿では、これら3つの方法がブロックチェーンにおいてどのように適用されるかを探求し、それらの利点と欠点を比較します。

三つの方法

一般的に、暗号化秘密鍵と身元情報を関連付ける一般的な方法は、公開鍵基盤（PKI）を使用することです。その中心部分は公開鍵ディレクトリです。この方法では、情報を送信する人は、信頼できる第三者（つまり、このディレクトリを維持する機関、通常は証明書発行機関）とやり取りして、暗号化情報を送信する必要があります。

しかし、Web2の環境では、この公開鍵ディレクトリを維持するには高いコストと手間がかかります。さらに、ユーザーは証明書発行機関が権力を乱用する可能性にも直面しています。

暗号学者たちが公開鍵基盤（PKI）の問題を解決するために提案した代替案があります。1984年、Adi Shamirは基于IDの暗号化（IBE）を提案しました。この方法では、一方のID（例：電話番号、電子メール、またはENSドメイン名）が直接公開鍵として使用されます。このアプローチにより、公開鍵ディレクトリの維持が不要になりますが、新しい問題が発生します：信頼できる第三者（秘密鍵ジェネレータ）に依存して秘密鍵を生成する必要があります。

2001年、Dan BonehとMatthew Franklinは初めて実用的なIBE構造を提案しましたが、この技術は広く採用されていません。主に企業や政府の展開環境など、閉鎖された生態系で使用されています。IBEが広く使用されていない理由の1つは、第三者が生成した秘密鍵に信頼が必要であるという強力な信頼仮定に依存する必要があるためです。

しかし、この記事で後で議論されるように、この信頼の問題は信頼できる一定数の参加者（すなわち、法的な人数）に依存することで解決でき、ブロックチェーン技術でこれを簡単に実現できます。

優れた点と欠点

これらの暗号化方式を比較する際には、多くの異なる要素を考慮する必要があります。私はこの点で2つの仮定を立てています:

ユーザーは彼らの秘密鍵を更新または取り消さない：これは、議論の中で各ユーザーの秘密鍵が固定されており、変更されないと仮定されることを意味します。

スマートコントラクトはオフチェーンのデータ可用性サービス（DAS）やblobデータを使用しません：つまり、スマートコントラクトが完全にオンチェーンデータに依存し、オフチェーンデータサービスや追加のデータストレージは関与しません。

公開鍵ディレクトリ

誰でもスマートコントラクトを呼び出すことで、他の人が使用していないID、つまり（id、pk）エントリをオンチェーンディレクトリに追加することができます。

分散化のPKIは、スマートコントラクトを使用して、IDと対応する公開鍵のディレクトリを維持することを指します。このディレクトリは公開されており、中央集権の第三者に依存しません。例えば、ENSの場合、ドメイン（つまりID）と関連するメタデータのマッピング関係を維持しており、そのドメインが解決されるアドレス（これらのアドレスのトランザクションから公開鍵を推測できます）を含みます。ENSはより複雑なシステムであり、公開鍵だけでなく他のメタデータも保存されています。分散化のPKIの機能は比較的シンプルであり、スマートコントラクトは各IDに対応する公開鍵を記録するリストを維持するだけです。

ユーザーが身分を登録したい場合、最初に秘密鍵のペア（公開鍵と秘密鍵）を生成するか、既に生成された秘密鍵を使用して、その身分IDと公開鍵をスマートコントラクトに送信します（一定の料金を支払うかもしれません）。スマートコントラクトは、そのIDがすでに他の人によって登録されていないかをチェックします。占有されていない場合、スマートコントラクトはそのIDと公開鍵をディレクトリに追加します。登録が完了すると、誰でもスマートコントラクトにそのIDに対応する公開鍵を問い合わせることで、そのユーザーに暗号化されたメッセージを送信できます。送信者が以前にそのユーザーにメッセージを暗号化し、そのユーザーの公開鍵を持っている場合は、再度スマートコントラクトに公開鍵を要求する必要はありません。公開鍵を取得した後、送信者は通常どおりそれを使用してメッセージを暗号化し、暗号化されたメッセージを受信者に送信し、受信者は対応する秘密鍵を使用してメッセージを復号化し、元の文を復元できます。

私たちはこのメソッドの利点と欠点を見てみましょう：

利点欠点非交互式復号化：復号化プロセスは他の当事者との対話を必要とせず、復号者は独自に復号化を完了することができます。簡潔でない（Not succinct）：システムはある面で簡潔でないかもしれず、それは複雑さが高い、データ量が大きい、またはより多くのリソースが必要であることを意味するかもしれません。透明性：システムはある面で透明であり、操作が公開され、検査可能であることを意味するかもしれません。インタラクティブな暗号化：暗号化プロセスは他の当事者との一定の対話を必要とするため、複雑さが増します。任意のID：ユーザーは特定の形式や規則に制約されることなく、自由に身分IDを選択または使用することができます。送信者は匿名ではありません：送信者の身元はシステム内で完全に匿名に保たれない可能性があります。

ID ベースの暗号化 (IBE)

ユーザーの身元は、彼らの秘密鍵で表されます。つまり、秘密鍵は暗号化だけでなく、ユーザーの唯一の識別子としても使用されます。ただし、この方法では、1つまたは複数の信頼できる第三者に依存する必要があります。これらの第三者は秘密鍵を生成し、配布する責任を負います。さらに、これらの第三者はシステムのライフサイクル全体でメインの秘密鍵を保管する必要があります。このメインの秘密鍵は、解読や他の重要な操作に使用されることがある場合があります。

IBEシステムでは、ユーザーは従来の公開鍵暗号化システムとは異なり、自分自身で公開鍵と秘密鍵のペアを生成しません。代わりに、信頼できる秘密鍵ジェネレーターを使用して登録する必要があります。秘密鍵ジェネレーターには、マスターシークレットキー（msk）とマスターパブリックキー（mpk）のペアがあります。ユーザーが自分のIDを提供すると、秘密鍵ジェネレーターはマスターシークレットキー（msk）とユーザーのIDを使用して、そのユーザー専用の秘密鍵を計算します。生成された秘密鍵は、安全なチャネルを介してユーザーに送信する必要があります。通常、これには秘密鍵交換プロトコルが使用されます。

送信者にとって、IBEシステムは暗号化プロセスを簡略化しています。 送信者は主公開鍵（mpk）を1回ダウンロードするだけで、その後はIDを使用してメッセージを暗号化できます。 受信者にとっても、復号は簡単です。 登録ユーザーは、秘密鍵生成器から送られてきた秘密鍵を使用して受け取った暗号文を復号できます。

鍵生成器の主秘密鍵（msk）は01928374656574839201長期保持する必要があります。なぜなら、システムが稼働している間には、常に新しいユーザーの秘密鍵を生成する必要があるからです。これは、一部のSNARKシステムとは異なります。後者は信頼された設定プロセス中に生成されますが、設定が完了した後に破棄することができます。その一方でIBEシステムでは、主秘密鍵を初期化後に削除することはできません。

主の秘密鍵（msk）を適切に保管していても、登録ユーザーは依然としてキーペア生成器が彼らのメッセージを読み取らないことを信頼する必要があります。これは、キーペア生成器がいつでもユーザーの秘密鍵のコピーを保存したり、主の秘密鍵を使用してユーザーの秘密鍵を再計算したりできるためです。

秘密鍵生成器は、ユーザーに問題のあるか制限された秘密鍵を提供する可能性があります。このような秘密鍵は、ほとんどのメッセージを復号化できますが、特定のメッセージを復号化できない可能性があります。つまり、秘密鍵生成器はユーザーの復号能力を操作する能力を持ち、ユーザーの通信をある程度制御または制限する可能性があります。

利点欠点オンチェーンストレージ恒定/最小：システムが必要とするストレージ量が非常に少ないか、恒定であり、時間の経過に伴って増加しません。強い信頼仮定：システムは1つまたは複数の信頼できる第三者に依存しており、これらの第三者に対して強い信頼が必要です。これらの第三者が破壊されたり、信頼できなくなったりすると、システムの安全性が脅かされる可能性があります。非対話型の暗号化：暗号化プロセスに他の当事者との対話は必要ありません。送信者は独自に暗号化を完了できます。送信者の匿名性：システムは送信者の身元を匿名に保つことができ、プライバシーを保護します。任意のID：ユーザーは自由に任意の身元IDを選択または使用でき、特定のフォーマットやルールに制限されません。

登録された暗号化(RBE)に基づく

IBEのように、このシステムでは、ユーザーの身元（例えば電子メールアドレスまたは電話番号）が直接彼らの公開鍵として機能します。ただし、IBEと異なるのは、このシステムが信頼できる第三者やquorumグループに秘密鍵を管理させる必要がないことです。代わりに、このような信頼できる第三者はkey curatorによって取って代わられます。

私はこのセクションで効率的なRBE構造の一つについて話し合います。私の知る限り、他の実用的なRBE構造と比較して著しい利点があります。それはブロックチェーン上で展開できることです。なぜなら、それはブロックオンチェーン部署において、lattice-basedではなくpairing-basedであるからです。

RBEシステムでは、各ユーザーは自分自身で秘密鍵（公開鍵と秘密鍵を含む）を生成します。また、彼らの秘密鍵と共通参照文字列（CRS）に基づいて、いくつかの更新値（図で a とマークされています）を計算する必要があります。これらの更新値はシステム内でのさらなる操作に使用されます。共通参照文字列（CRS）の存在は、システムの設定に完全に信頼が不要であることを意味します。ただし、CRSの生成プロセスは tau の冪と呼ばれる構築方法を採用しています。この構築方法は、オンチェーンで複数の参加者が協力して計算することができます。少なくとも1人の参加者が正直であれば、このCRSは安全です。

スマートコントラクトは予定された数のユーザーNを設定し、これらのユーザーを異なるバケツにグループ化します。ユーザーがシステムに登録する際には、スマートコントラクトに自分のID、公開鍵、および更新値を送信する必要があります。スマートコントラクトは一連の共通パラメータppを維持し、これらの共通パラメータは以前に言及された共通参照文字列（CRS）とは異なります。ppはシステム内のすべての登録済みユーザーの公開鍵の簡潔な要約と見なすことができます。スマートコントラクトはユーザーの登録要求を受け取ると、更新値をチェックして正当性を検証します。検証が通ると、スマートコントラクトはそのユーザーの公開鍵をppの対応するバケツに乗算します。この手順は新規ユーザーの公開鍵をシステムの共通パラメータセットに組み込むことに相当し、後続の操作で使用できるようにします。

登録ベースの暗号化（RBE）システムでは、ユーザーはメッセージを復号化するために必要ないくつかの情報をローカルに保存する必要があります。同じグループに新しいユーザーが登録すると、これらの情報を更新する必要があります。ユーザーはブロックチェーンを監視して、これらの情報を手動で更新することができます。または、スマートコントラクトは最近登録されたユーザー情報を提供し、ユーザーはこれらの更新を定期的に取得して復号化情報を最新の状態に保つことができます。

このシステムでは、送信者は2つのことだけをする必要があります：

公共参照文字列（CRS）のダウンロード：これは1回のみのダウンロードであり、それ以降は更新する必要はありません。

ダウンロード公共パラメータ：送信者は時々最新の公共パラメータをダウンロードする必要があります。送信者にとって重要なのは、これらの公共パラメータに受信者の公開鍵が含まれていることであり、毎回最新バージョンをダウンロードする必要はありません。受信者の公開鍵が見つかれば十分です。

次に、送信者はダウンロードしたCRS、公共パラメータ、および受信者のIDを使用してメッセージを暗号化し、受信者に送信できます。これは、送信者がデータを頻繁に更新する必要がないことを意味し、公共パラメータに受信者の公開鍵があることを確認するだけで十分です。

ユーザーが暗号化されたメッセージを受け取った場合、まずはローカルに保存されている補助情報を確認し、特定の条件を満たす値が存在するかどうかを確認します（たとえば、特定の検証チェックを通過した値など）。ユーザーがローカルで条件に合致する値を見つけられない場合、それは最新の更新情報をスマートコントラクトから取得する必要があることを意味します。ユーザーが適切な補助情報値を見つけたら、その値と自身の秘密鍵を使用して受け取った暗号文を復号化し、元のメッセージを回復することができます。

明らかに、この案は他の2つの案よりも複雑です。しかし、公開鍵ディレクトリよりも少ないオンチェーンのストレージが必要であり、IBEの強い信頼仮定を回避しています。

シンプルなパラメーター:

・オンチェーンに格納されるパラメータのサイズとユーザー数の関係は、公開鍵ディレクトリで必要なストレージ量（線形上昇）よりもはるかに小さいサブリニアであるが、定数ではないため、この点ではIDベースの暗号化（IBE）システムには及ばない。

ある程度のインタラクティビティを備えた暗号化:

• メッセージを送信する際に、送信者は受信者の公開パラメータのコピーを持つ必要があります。これは、送信者が受信者が登録後にこれらのパラメータを更新する必要があることを意味しますが、個々の受信者を個別に更新する必要はありません。なぜなら、1回の更新には複数の受信者の秘密鍵が含まれる可能性があるからです。全体的に、メッセージの送信はIBEよりも対話的であり、公開鍵ディレクトリを使用するよりも少なくなります。

ある程度の対話性を備えた復号化:

• 暗号化と同様に、受信者は、暗号化時に使用された公共パラメータのバージョンに一致する補助情報のコピーが必要です。特定のグループに新しいユーザーが登録すると、公共パラメータと補助情報が更新され、暗号文を復号化するための値は、暗号化時に使用された公共パラメータのバージョンに対応します。ユーザーは、補助情報の更新を定期的に取得するか、復号化に失敗した場合を除いて、すぐに更新するかどうかを選択できます。公共パラメータの更新とは異なり、補助情報の更新をより頻繁に取得することはプライバシー情報を漏洩させません。

送信者は匿名です：

• 公開鍵ディレクトリの場合と同様に、送信者は最新のパラメータを持っていれば、特定の情報をクエリする必要なく、メッセージを独自に暗号化することができます。送信者がオンチェーンから情報を読み取る必要がある場合、その情報はターゲットの受信者には関係ありません（送信者が特定のパラメータのみを要求する場合を除き、しかし、これにより一部の情報が漏洩する可能性があります）。

透明性：

• システムは信頼設定（分散型または外部管理）を介して設定し、修正されたCRS（共通参照文字列）を出力する必要がありますが、一旦設定されると、信頼された第三者または仲裁者グループに依存しなくなります。協調された第三者（スマートコントラクト）に依存していますが、このシステムは完全に透明であり、誰もが調整者として機能したり、状態の変化を検証して正直に動作しているかどうかを確認することができます（これはスマートコントラクトとして実装できる理由でもあります）。さらに、ユーザーは自分自身または他の人がシステムに登録されているかどうかを確認するために、簡潔な（非）メンバーシップ証明を要求することができます。これはIBEシステムとは異なり、IBEでは、信頼された第三者に秘密鍵を漏洩していないことを証明するのが困難です（たとえば、秘密のコピーを保存したり他の人に漏洩したりすること）。一方、公開鍵ディレクトリは完全に透明です。

制限されたIDのセット：

• ここで説明されているのは、RBE構築の基本バージョンです。 IDが所属するグループを透明に確定するために、IDには共通して確定された順序が必要です。 電話番号は簡単に並べ替えることができますが、任意の文字列を並べ替えることは非常に複雑であり、グループの数が非常に多いまたは無限である可能性があるため、不可能です。 このマッピングを計算するための個別の契約を提供するか、後続の作業で提案されるcuckoo-hashing方法を採用して、この複雑さを緩和することができます。

受信者の匿名性:

• この方法により、暗号文が受信者の身元を漏らさないようにすることができます。