プライベートメッセージ機能の提案の調査

⚠︎ この記事は執筆中です。

プライベートメッセージ(DM、グループチャット、大人数のグループ向けを含む)に対して提案されているアプローチを要約する試み。安全で多機能な相互運用可能なソリューションを構築することを目的としている。

要約と解説

問題点

現状のDM実装であるNIP-4は、アカウントの秘密鍵をそのまま使ってDH鍵共有(相手の公開鍵と自分の秘密鍵を使って暗号化のための共通鍵を作る技術)を行っており、以下のような問題を抱えている。

秘密鍵が漏洩した場合に、全てのメッセージが復号されてしまう

メッセージの送信も同様

現実的に秘密鍵の生成アルゴリズム等に脆弱性が見つかった場合に、このような状況に陥る可能性がある。

contentフィールド以外のメタデータが漏洩している

送信者、受信者、タグ、timestamp等のデータが秘匿化できていない

グループチャットがサポートされていない

DH鍵共有を使用する場合の実装

グループチャットの参加者全員に対して鍵を生成し、メッセージ暗号化し送信する

問題点: N+1問題(参加者全員分の鍵生成、メッセージ暗号化をするとなると人数が増えると現実的ではない)

グループ鍵を生成する

問題点: 鍵自体は一つで済むが、メンバーが変わるたびに鍵を再度生成しなければならない。

提案

⚠︎ 執筆中

まだ解決していない問題

⚠︎ 執筆中

リファレンス

contentフィールド以外のメタデータが漏洩している

将来に渡って機密とは限らない

グループチャットがサポートされていない

その他のkindのサポートがされていない

貧弱な暗号化技術

共通のテーマ

一時的なキー (59、24b、107)

鍵交換（101、76、24a、31）

BIP-32 キーの導出 (31、76)

複数のDMとしてグループ チャットを実装 (31、112)

共有シークレットを使用するグループチャット (38、112、76)

強固な暗号基盤としての NIP 44 への依存 (59、24b、107)

メタデータ漏洩を最小限に抑えながら、ラップされたイベントをREQする機能 (59、b1)

タイミングによるを解析を困難にするためのcreated_at フィールドのランダム化 (24b)

オニオンルーティングによる複数のラッパー (103、24b)

リレー連携で有効期限を使用して前方機密性を向上させる (112)

nsec バンカーを組み込んで、取り消し可能で制限付きの認証によるキー共有を実装 (b1)

sigを削除することでメッセージの漏洩を防止する (コンテンツが共有されても署名が共有できない) (24b)

複数の公開鍵にメッセージを送信して、真の受信者を秘匿する (17)

モデレーター/メンバーリスト (29、b1、172)

Zapを使用してDMをはじめる (107)

1:1のDMではグループにはできないECDHの共有秘密を利用してメタデータを隠蔽することができるが、知らない人に DM を送信することはできない。(107)

実装

まとめ

現時点でのコンセンサス

1. NIP 44で説明されている暗号化(注意: NIP 全体ではない) は、NIP 04よりも優れているため、今後も使用するべき。

2. ギフトラップは、送信者と受信者を区別するための便利な汎用プリミティブです。多くの提案は、特に NIP 59 に従っていない場合でもこの考え方を使用している。

NIP 112 および 24b は、上記のコンセンサスに最も近い実装と思われる。

NIP 112 にはキーの交換とローテーション(交替)のための方法が含まれているという利点があり、24b はグループ全体に対するキー漏洩の影響を軽減するという利点がある。

その他

NIP 103 は、ボットによって制御される他のキーを介してメッセージをルーティングすることにより、配信性に影響を与えるような不要な間接性を導入する。 NIP 24b に従って二重ラッピングすると、この問題がより簡潔に解決できる。

BIP-32 の派生 (NIP 76、31) は不必要な複雑さをもたらすが、前方機密性は解決されない。

単純な共有シークレット (NIP 38、112、76) は前方秘密保持を提供できず、これは特に大規模なグループの場合に問題となる。共有秘密が使用される場合、NIP 112 で説明されているように、無効化はプロトコルの一部でなければならない。

NIP 24a、18 などは初期の提案であり、部分的な解決策しか提示していない。

NIP 101 は部分的な解決策でしかないが、より完全な解決策に適応できる堅牢な鍵交換プロトコルを提供している。

NIP 29 のリレー中心のアプローチは比較的人気がなく、リレーの選択は(いくつかの提案のように) ライバシーを向上させるための推奨事項にはなり得るが、これだけでは十分とはいえない。

NIP 172 は、29 や b1 と同様に、モデレーションに関する提案を除いて、プライベートメッセージの議論とはあまり関係がない。しかし、モデレーションは暗号化されたグループ チャットの多くの使用例に望ましい機能である。

未解決の問題

前方秘匿性

前方機密性を解決する解決策は提案されていない。それを解決するには、次のことが必要。

キーの取り消し

これは、無効化/ローテーション スキームのない有効期間の長いキー (共有キーかどうかには関係なく) は使用できないことを意味する。

ラチェット

自分自身のイベント、または他のパーティから受信したイベントのいずれかを復号化することによってセッション キーを発見できる限り、キーのローテーションのチェーンを時間の経過とともに追跡することができてしまう。

同様に、セッション キーの漏洩が漏洩した場合、時間を遡って他のセッション キーが漏洩する可能性がある。

前方秘匿性 は、情報の破棄または帯域外の保存のいずれかに依存する。

NIP 112 が提案するイベントの有効期限は、キー交換のチェーンを切断するため部分的な解決策ではあるが、協力を拒否する敵対的なリレーがいた場合の解決策にはならない。

NIP 24b の二重ラッピングにより、クライアントが自分自身にラッパーを送信する代わりにメッセージをローカルに保存するだけであれば、前方秘匿性に近づくことができる。

これにより、クライアント インスタンス間のメッセージ共有はできなくなるが、(注意: 自分のキーではない) 通信相手のキーが漏洩した場合にのみ、その人のメッセージ履歴を回復できるようになる。

この制限は、ユーザーがメッセージ履歴を帯域外に転送できるようにすることで克服できる可能性がある (例: アニメーション化された QR コード、エクスポート/インポート、または帯域外で共有される一時的なキーで署名された別のイベント)

24b の二重ラッピング手法に鍵交換を追加すると、攻撃者が中間イベントを取得できない場合に、漏洩した鍵の影響をさらに制限できる可能性がある。

もう 1 つの改善策は、P2Pの暗号化チャネル、QRコード、またはその他の方法を使用して、プロトコル外でキー (または共有のnonce) を交換すること。こうすることでユーザーの秘密鍵が漏洩してもセッションキーは読み取れない。

詳細:

大規模なグループチャット

暗号化されたグループチャットの重要な使用例の 1 つとして、非常に大規模なグループ (1000 以上) がある。このような場合、共有シークレットの漏洩リスクは、小規模なグループに対して格段に上がる。

また、NIP 24b のアプローチ (すべてのメッセージを各メンバーに送信する) によるグループチャットのコストは O(メンバー * メッセージ) になる。さらに、グループの識別子はそのメンバーの公開鍵によって定義されるため、24b のグループ メンバーシップは動的にできない。

24b にキー交換を追加することで、すべてのメンバー間で n 個のキーを共有することで大きなグループを n 個のグループに分割し、キーの無効化を導入できる。

これにより、そのようなグループチャットのコストが O(メンバー/n * メッセージ) まで低くなる。

リレーベースの攻撃

リレーはIPアドレスを介してセッションキーを実際のキーと関連付けることができるため、メタデータが漏洩する可能性は十分にある。

リレーは、暗号化されたメッセージの保存を拒否することも可能。ラッパーに POW を追加すると、送信者にとってコンテンツに価値があることが証明され、リレーにそれらのメッセージを保存するよう促すことができる。また、特殊用途のリレーは、暗号化されたデータのみを保存し、そのようなリスクの高いストレージに課金するビジネスモデルを構築できる。

コンポーネントの分離化

今後の提案では、この問題がどの層に分類できるかを特定し、さまざまな実装とほぼ互換性のある特定のトレードオフのセットをサポートするために、これらを再組み立てするべきだと考えられる。

新しいNIP (NIP A) は、NIP 44の暗号化に関する詳細と、NIP 59および24b で定義されたラッピング スキーマを組み合わせる必要がある。

二重包装されたイベントは、1059 よりもはるかに柔軟性とプライバシーが提供されるため、ギフト包装の標準であるべき。

このNIP には、特定の使用例 (つまり、kind: 44、「グループ」の定義など) に関する詳細を含めるべきではない。ただし、nostr-in-nostr を達成するためにあらゆる種類をラップできることに言及する必要がある。

新しいNIP (NIP B) は、NIP 101 と同様の鍵交換プロトコルを定義する必要がある。

AとBを組み合わせてDMを実装する方法を説明する新しいNIP (NIP C)の提案を作成する。

新しい NIP (NIP D) は、グループ チャット (24bのような) を実装するために A と B を一緒に使用する方法を説明する提案を作成する。

新しい NIP (NIP E) は、AとB を一緒に使用して大規模なグループ(112のような)を実装する方法を説明する提案を作成する。

これにより、暗号化されたさまざまなユースケース間で、疎結合に共通のコンポーネントを利用することができるようになる。ラッパーに k タグを追加するなどのアフォーダンス は、コアのNIPではなく、ユースケースに基づいて C/D/E によって推奨されるかどうかで決まる。