[Japanese] Whisper （ウィスパー） - whilei/ethereumproject-wiki GitHub Wiki

name: Whisper category:

ユースケース

  • DApps(分散形アプリ)は、互いに少量の情報を出しあう必要があり、一定時間情報を公開したまま保持する。 例えば分散型の通貨換算所を目指すDAppでは、あるレートで通貨を売って欲しいという要求を記録するために公開された情報を利用する。 このような使い方においては、何十分何日間と情報を公開している状態が続く。 オファーは決して取引を強制するものではなく、ただ潜在的な取引の始まりを示唆しているだけである。

  • 分散形アプリは、あるトランザクションにおいて究極的に協力する関係を持つために お互いに信号を送り合う必要がある。 例えば分散形の通貨取引所アプリは、1つの取引を作成する前に（交換所に依っては２つの取引）、 オファーを調整するためにお互いの信号を利用する必要がある。

  • リアルタイムではない情報を提供する必要がある、もしくは互いに 一般的な通信を行う必要がある分散形のアプリの例は、例えば小さなチャットルームの部屋だ。

  • 分散形のアプリは、お互いのことを何も分からないがハッシュだけは分かる2つの通信者に対して 見えない通信を提供する必要がある。(全体のネットワークを通じた解析に対して合理的な拒否を行う) 不正告発者が、著名なジャーナリストにコンタクトをとり、少量の証明可能な情報をやりとりし、 そして、何か他のプロトコル(Swarm, かもしれない)によって、大量の通信を出来るようにするある分散形のアプリかもしれない。

一般的にトランザクションを考えると、出来事が記された記録がなかったとしても、 あらゆる必要な物事は、言ったことや、自動執行や、状態の変更に結びついている。

仕様

  • Low-level 低位のAPIは分散形アプリにのみ提供され、ユーザーには決して提供されない。
  • Low-bandwidth 低位の通信帯は大きなデータの通信には利用されない。
  • Uncertaing-latency 不確実な遅れはRTCには利用されない
  • Dark　パケットを追跡するための方法は無い。
  • Typical Usage: ** Low-latency 遅延の少ないメッセージは1対1や、1対Nでのメッセージを送る際に使われる。 ** High-latency 遅延は大きいが、生存時間(TTL)の長いメッセージは、メッセージを公開する際に使用される。 メッセージは64Kバイト未満であり、一般的には約256バイトである。

既存の解決策

  • UDP: APIレベルでよく似ていて、ネイティブのマルチキャスティング。生存時間は設定されておらず、セキュリティや、プライバシーの保護もない。
  • 0MQ: 分散形のメッセージシステム。何もプライバシーの保護機能は備わっていない。
  • Bitmessage: P2Pのネットワーク上でのメッセージ交換システムと似ている。 高位のプロトコルで、決まった生存期間(TTL)を持ち、スループットに対しての調整機能を持たない。
  • TeleHash: 安全な通信を目指したRTC通信。Bittorrentの方法と似ている。（修正版Kademila Techを使用), だが与えられたハッシュのピアーを見つけるよりも、与えられたハッシュの受信者を見つける。 DHTを使って決定論的なルーティングを行うため、それゆえに大規模な攻撃に対しての単純で解析的なパケット解析攻撃に脆弱である、 接続を主目的としているため、生存期間(TTL）や、非同期的な通信の公開のために作られていない。
  • Tox: 高位(IM & AV チャット)の補完を目的として作られた。

基本的なデザイン

Uses the "shh" protocol string of ÐΞVP2P.

残りはもうじき公開される。一度プロトタイピングは完了した。by Gav

トラフィック解析を出来なくすることが考慮されている。

（Lokiverloren より） 既に存在する位置情報が覆い隠されているインスタントメッセージサービスを目的としている全てのプロトコルは、 ルーティングに対処するための複雑な問題を抱えている。

Bitmessageプロトコルでは、メッセージを匿名でネットワークに公開するが、 適切な受信者がどうやって復号化して受け取るのかを知る必要がある（他のメッセージツールと丁度同じように）。 だが、メッセージを保存後、ユーザーが新しいメッセージを得られたことを知る事が出来る。 問題は全体のネットワークに公開される情報量が著しく増えるに連れて、 理想的な状態では用意にアクセスされるべきではない暗号化された通信が全体のネットワークに公開されることだ。

上記のどの通信プロトコルもとりわけメッセージの出処とその行き先を隠すということについての方法がない。 そのため、私はウィスパープロトコルの1つの主目的は送信者と受信者の位置情報を匿名化して、 中継点からにその他、もしくは双方との接続を不可能ではないにしても難しくすることである。

Tor システムは2つのノードの間でお互いの位置情報を知ること無く接続を確立する事が出来るプロトコルを持っている。 それは隠されたサービスを提供するために使われているランデブープロトコルによるものである。 この記事の読者の大半は、既にどのようにして動くかを知っているだろう。 だがどのようにして動いているかといえば、隠されたサービス（TCP/IP通信中のポートを聞くサーバーと同様のサービス) が通信紹介者のノード達の間からランダムな番号を選び出す（通常は6であると筆者は思う）。 そのためには、一般的な3-hopで届く導入者への接続を確立し、 ユーザーが隠されたサービスとのコネクションを確立しようと望んだ時には、 特定の公開鍵と組となる隠されたサービスへと接続しようとするリクエストを発信する必要がある。

どのようにしてリクエストが伝播するのかについては確かな確信が無いが、 明らかに円形の回線かランデブー型のTor導入者のノードが、 どのノードが回線を創りだそうとしているのかを知っていることによって、 隠されたサービスへの接続のためのリクエストの伝播が為されている。 一旦クライアントが有効な接続可能なランデブーノードを知れば、コネクションを確立し、 隠されたサービスへランデブーノードを中継して、トラフィックを持つことが出来るようにリクエストを送る

通信接続のプロトコルを隠すための実装としてあまり良いもので内容に思う。 何故ならば、クライアントのノードとしてノード間を伝わっていくために異なるIDが必要となるためだ。 同様の原理はEthereum にも当てはまる。

しかしながらランデブーを使用することによって、再度互いのことを知っているノード間の接続 （たとえお互いのアカウントやIDや通信開始者を知らないにしても）が出来るようにし、 3hop 回線を形成するよりも何か。

Tor上の出口となるノードへと繋がる回線を形成するためには、クライアントが通信中のホップのリレーのIDを知る事が危険でない だが、そのためには、"ネットワーク内で" 位置情報を難読化するセキュリティに対しての脆弱性がある。 貴方のルーターのIDと、貴方のEthereumのIDを結びつける（筆者は明白にイーサリウムのノードが実行する、ルーティングの機能を公開する必要があると考える。）ランデブーノードに接続する際に、あなたの位置情報をランデブーに対して公開しない。 そしてランデブーノードは隠されたサービスの位置情報を知ることもない。 そして、ルーターが創りだされる公開ディレクトリの情報だけを必要とするこれらの通信を確立する。

攻撃者にとって結果として手に入る情報ではなく、 貴方のIPアドレスに関係するサーバーを直接調べることによって明かされてしまうかもしれない。

この議論に対して私は下記を述べたい。

  1. ウィスパーのプロトコルはTorのような位置情報を匿名化するシステムを通して動く必要があると、上記の事実は示唆している。 それだけでなく、Torが隠されたサービスのために用いているランデブープロトコルを形成する形式を用いなければならない。

  2. しかしながら、Torは元来ウェブサーバーが貴方のIPアドレス（セッションのクッキーと記録と関連する）を記録することを防ぐための手段を第一義として設計された。そして第二義的に、TCP/IPルーティング（ポート）の通信の同様の手段を実装するための機能が付け加えられた。ランデブープロトコルを形成して位置情報を匿名化するという文脈の中で最初の目的を達成するために残った中間生成物が、3hop ノードとコネクションを利用する方法の形成へと繋がった。そしてコネクションが無いセッションのようなHTTPで使われているプロトコルよりもむしろオープンなまま残っている。 そこで私が提言したいことは、特定のコネクションが必要であるために、そこには匿名化のプロセスを混ぜあわせる機会がある。その機会を使うことによって、悪意あるノードが攻撃者に対してデータを集めるためのトラフィックの解析があった場合に、 コネクションを一層隠されたものに出来るのではないかということだ。

例えば、ブラウザとサーバー間のような通常の通信では再び接続を確立するために遅れが生じるので、通信は開いたままで 更にリクエストを送る場合にはセッションのクッキーを保管しておく。セッションのクッキーを保存しておく代わりに、クライアントが隠され隠されたノードへのコネクションの方法を変更することが出来る。 そのコネクションでは秘密鍵を共有して通信する代わりに、多数の異なる回線を通ったデータの断片、そして受信者は断片がオリジナルのパケットを構成できる様になるまで待たなければならない。確かに(ウィスパーに関連しているだけでなく他の分散形のデータストレージプロトコルにおいても)大きな通信や、様々なパートに分かれた通信においてプロセスを取った匿名化の方法を変えることによって、一層トラフィック解析データを難読化するだろう。

メッセージシステムであっても、分散形のファイルシステムであっても、 只送信されるデータの大きさに対処する必要がある違いだけで、本質的に同様の考察が当てはまる。

どのようにしてルーティングを進めるかを決定するための評価指標は、通信遅延だ。 幾つかの目的に対しては通信遅延が少ないことが求められる、他のいくつかの目的に対しては、 セキュリティが高いことの方が重要である。 プロセスの流れの中でパーツに分類された際に、パーツから全体のパッケージへとコンバートするためには、 全てのパーツが揃っている際にだけ出来るとすることによって、セキュリティを一層向上させる事が出来る。 一部のパートが傍受されて、完全なメッセージでなかった際には、 データを組み合わせることは不可能で暗号解析の目的にさえも使用することが出来ない。