仕様

「仕様」の編集履歴(バックアップ)一覧はこちら

仕様」(2014/03/26 (水) 23:36:18) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*P2P掲示板の仕様 ・TODO: 後で書く → 仕様なんて一発で決まるわけ無いだろ、いい加減にしろ! 少なくとも、HTMLを生成する部分と掲示板を管理するロジック、そしてP2P通信を行う部分で分けることになりそう *課題 and 機能要件 ・(1) &bold(){荒らし対策}:荒らしを抑えるために書き込みを(頻度的に/内容的に)制限しなくてはならない ・(2) &bold(){プロトコルによる制限}:自己に制限を掛ける形式だとプログラムを改造して不正利用される恐れがあるため使えない(※クライアント側のプログラムは制限をかけられない) ・(3)&bold(){ 匿名性保証と同一ノード情報取得の両立}:そのため外部から制限を掛ける必要があるが、ノードと書き込み内容の一致がなければならず、匿名性を危うくする(※ 匿名性は保証しつつ同一投稿者であることも保証したい) *P2Pで掲示板を実装するアプローチ P2Pで掲示板を実装するにはいくつかのアプローチがある。掲示板のデータがネットワークを伝播するようにしてもいいし、掲示板のデータはDHTに保管し、その更新情報だけをネットワークに流してもいい。直接掲示板のデータを流すのではなく、抽象化してデータの保存部分と掲示板としての機能を分離してもいい。 *オニオンルーティングのアプローチ オニオンルーティング(Onion routing)は、米海軍調査研究所(United States Naval Research Laboratory)の出資で開発されたシステムである。 → [[Tor>http://ja.wikipedia.org/wiki/Tor]] &bold(){オニオンルーティングの肝要は、誰かが情報を送ってきても、その人が発信者なのか中継者なのかを秘匿していることである。} ← それどこ情報よ〜、俺にも教えてくれよな → しかし中継者が発信者のIDを付与するためには、送ってきた相手が発信者なのか中継者なのかを特定しなければならない(=P2P掲示板を構築する上での問題点)。 → 現状はOnionちゃんねるも、新月もこの投稿誰のかこれもうわかんねえな(諦念)状態かと *実装方法検討 **(3) 「匿名性保証と同一ノード情報取得の両立」について ***(A)ノードAからノードBにID or IPアドレス情報を送る方法は? >A から B に何かを送りたい場合、 > >1) B および中継ノード X, Y .... を「最初にAが決めておく」 >2) B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手 >3) 通信内容を公開鍵 Kb で暗号化 >4) 3) の結果+B のアドレスを公開鍵 Ky で暗号化 >5) 4) の結果+Y のアドレスを公開鍵 Kx で暗号化 >6) 5) を X に送る > → この場合BがAのIPアドレスを知るのはほとんど無理であるが、それでも掲示板の仕様としてはIDによる投稿者の同一性を保証したい ***(B) (A)の回答 >A から B に何かを送りたい場合、 > >1) B および中継ノード X, Y .... を「最初にAが決めておく」 >2) B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手 > → 公開鍵を渡す側で、接続してきたIP を記録しておく(この場合は Kb と一所に接続先を記録する) >3) 通信内容を公開鍵 Kb で暗号化 >4) 3) の結果+B のアドレスを公開鍵 Ky で暗号化 >5) 4) の結果+Y のアドレスを公開鍵 Kx で暗号化 >6) 5) を X に送る > → B での復号時はあちらこちらにばら撒いた公開キーを覚えておいての総当り ***(C) IPと日付でID生成 既存(?)の方法 [[IPと日付でID生成]]を参照 ***(D) CGA認証 ノードのIDをノード自身が決めるのではなく、ノードの公開鍵とIPアドレスから決定する方法。 [[CGA認証]]を参照 ***(Z) 諦める… >考えるまでもなく、匿名性と書き込みIDの一貫性は矛盾する。 >考えるべきは、IDが正当なものは低コストで済み、IDの乗っ取りを企てる者には馬鹿高いコストの仕組み。 >そこの現実的な解が無い状態。 >というか、匿名なんだからID無しでもおkじゃね?
*P2P掲示板の仕様 ・TODO: 後で書く → 仕様なんて一発で決まるわけ無いだろ、いい加減にしろ! 少なくとも、HTMLを生成する部分と掲示板を管理するロジック、そしてP2P通信を行う部分で分けることになりそう *課題 and 機能要件 ・(1) &bold(){荒らし対策}:荒らしを抑えるために書き込みを(頻度的に/内容的に)制限しなくてはならない ・(2) &bold(){プロトコルによる制限}:自己に制限を掛ける形式だとプログラムを改造して不正利用される恐れがあるため使えない(※クライアント側のプログラムは制限をかけられない) ・(3)&bold(){ 匿名性保証と同一ノード情報取得の両立}:そのため外部から制限を掛ける必要があるが、ノードと書き込み内容の一致がなければならず、匿名性を危うくする(※ 匿名性は保証しつつ同一投稿者であることも保証したい) ・(4)&bold(){負荷の分散と接続性の向上}:災害時などの緊急時にアクセスが集中してもそれに耐えられる処理能力・一定数のノードが接続できなくなっても機能が維持される可用性が要求される。 *P2Pで掲示板を実装するアプローチ P2Pで掲示板を実装するにはいくつかのアプローチがある。掲示板のデータがネットワークを伝播するようにしてもいいし、掲示板のデータはDHTに保管し、その更新情報だけをネットワークに流してもいい。直接掲示板のデータを流すのではなく、抽象化してデータの保存部分と掲示板としての機能を分離してもいい。 *オニオンルーティングのアプローチ オニオンルーティング(Onion routing)は、米海軍調査研究所(United States Naval Research Laboratory)の出資で開発されたシステムである。 → [[Tor>http://ja.wikipedia.org/wiki/Tor]] &bold(){オニオンルーティングの肝要は、誰かが情報を送ってきても、その人が発信者なのか中継者なのかを秘匿していることである。} ← それどこ情報よ〜、俺にも教えてくれよな → しかし中継者が発信者のIDを付与するためには、送ってきた相手が発信者なのか中継者なのかを特定しなければならない(=P2P掲示板を構築する上での問題点)。 → 現状はOnionちゃんねるも、新月もこの投稿誰のかこれもうわかんねえな(諦念)状態かと *実装方法検討 **(3) 「匿名性保証と同一ノード情報取得の両立」について ***(A)ノードAからノードBにID or IPアドレス情報を送る方法は? >A から B に何かを送りたい場合、 > >1) B および中継ノード X, Y .... を「最初にAが決めておく」 >2) B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手 >3) 通信内容を公開鍵 Kb で暗号化 >4) 3) の結果+B のアドレスを公開鍵 Ky で暗号化 >5) 4) の結果+Y のアドレスを公開鍵 Kx で暗号化 >6) 5) を X に送る > → この場合BがAのIPアドレスを知るのはほとんど無理であるが、それでも掲示板の仕様としてはIDによる投稿者の同一性を保証したい ***(B) (A)の回答 >A から B に何かを送りたい場合、 > >1) B および中継ノード X, Y .... を「最初にAが決めておく」 >2) B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手 > → 公開鍵を渡す側で、接続してきたIP を記録しておく(この場合は Kb と一所に接続先を記録する) >3) 通信内容を公開鍵 Kb で暗号化 >4) 3) の結果+B のアドレスを公開鍵 Ky で暗号化 >5) 4) の結果+Y のアドレスを公開鍵 Kx で暗号化 >6) 5) を X に送る > → B での復号時はあちらこちらにばら撒いた公開キーを覚えておいての総当り ***(C) IPと日付でID生成 既存(?)の方法 [[IPと日付でID生成]]を参照 ***(D) CGA認証 ノードのIDをノード自身が決めるのではなく、ノードの公開鍵とIPアドレスから決定する方法。 [[CGA認証]]を参照 ***(Z) 諦める… >考えるまでもなく、匿名性と書き込みIDの一貫性は矛盾する。 >考えるべきは、IDが正当なものは低コストで済み、IDの乗っ取りを企てる者には馬鹿高いコストの仕組み。 >そこの現実的な解が無い状態。 >というか、匿名なんだからID無しでもおkじゃね?

表示オプション

横に並べて表示:
変化行の前後のみ表示: