14/04/23 16:17:11.34 gYYujDYq
権力からの攻撃に耐えうる柔軟で雑草のように強いが情報集約可能なネットワークを作るのがこのスレの目的だろ。
957:デフォルトの名無しさん
14/04/23 18:57:11.00 FoocQSO7
これって、「完全匿名DHT」が難しいんだろ？
958:デフォルトの名無しさん
14/04/23 19:11:38.15 Rps+NS4N
>>953
ではキャッシュを分割して保持するのがいいね，RAID5 みたいに冗長性をもたせるのもいいし
＞書き込み者の匿名性はいらない。
クローラが蔓延し，あるいは ISP から接続履歴，あるいはネットワークデータそのものを当局によって押収されたとしても耐えうるくらいの匿名性はほしいね
959:デフォルトの名無しさん
14/04/23 19:50:21.69 Btqa34NG
情報投稿者の匿名(保護)
→オニオンルーティングでOK
→荒らし対策としてNGIDか、ID発行サーバか、自称IDでもホワイトリストが欲しいけど、実現出来るの？
情報配信者の匿名(保護)
→情報配信者が配信内容の決定に寄与しない構造ならばOK？
※勝手に配信してるので配信者の知った事ではないという主張で通す
→情報配信者が所持情報の解読が不可能な構造ならばOK？
→掲示板自体が公開の場合は復元に使う鍵を自力で回収できてしまわないか？
→経路上に鍵を置いておき、中継時に変換する操作を行うことで鍵の隠蔽は可能
→オニオンルーティングで情報配信者を隠蔽できていればOK？
960:デフォルトの名無しさん
14/04/23 20:27:43.05 Rps+NS4N
>>959
＞ →荒らし対策としてNGIDか、ID発行サーバか、自称IDでもホワイトリストが欲しいけど、実現出来るの？
>>100
>>68 に対しては >>199 ただし，一斉射撃問題みたいなことをしなければ，もう一歩ブレークスルーがほしいね
＞情報配信者の匿名(保護)
＞→情報配信者が配信内容の決定に寄与しない構造ならばOK？
これは実現は困難，複数の経路をつかって投稿をばら撒き，投稿内容に基づいたハッシュで同定するしかない
配信者がspamになることは防げないのが課題
→いわゆる配信経路リストを投稿内容に含めるのがいいか？これは発信者IDほど綿密に考慮する必要はない，IP を一段階ハッシュにとおすだけでいい
配信に協力している，という事実が公開されても問題はない．
配信者の認証というかチューリングテストも追加するとなおよい
＞→オニオンルーティングで情報配信者を隠蔽できていればOK？
オニオンルーティングは1対1の情報伝達には向いていても，配信には向かない，現段階ではオニオンルーティングは情報発信者のロンダリングが精一杯
961:デフォルトの名無しさん
14/04/23 22:34:20.42 Btqa34NG
>>960
「情報配信者の匿名」ってのが何処までできればOKなのかの話で、
「情報配信者が配信内容の決定に寄与しない」ってのは単純に「俺は頼まれただけ」状態にして責任逃れの言い訳があればいいの？って話。
レガシなP2Pファイル共有での、再配信する情報は自身がDLしたファイルだから再配信する人が制御出来ている状態、てのを避けるだけ。
配信者のオニオンルーティングは可能だよ。逆方向のポートフォワードに近い事をすればいいだけ。
配信者(≒サーバ)を示す符号から特定の中継者を算出できるようにしておいて、
配信者から中継者までオニオンルーティングでトンネル掘って、クライアントからのアクセスはその経路を逆送する。
実装調べて無いけどTorのHiddenServiceとかはその類じゃない？
962:デフォルトの名無しさん
14/04/23 23:31:13.54 k48oXhUz
次スレ立てといた
２ちゃんねる互換P2P匿名掲示板の実装を考える １
ｽﾚﾘﾝｸ(tech板)
>>940のまま行きたかったがスレタイ文字数制限に引っかかった、以上
963:デフォルトの名無しさん
14/04/23 23:47:01.42 MiNJnvws
>>962
乙です。
964:デフォルトの名無しさん
14/04/23 23:49:40.59 FoocQSO7
次スレというか分離だな。ここのスレタイ通りの実装を考えるなら、２ちゃん互換も足枷でしかないからな。
965:デフォルトの名無しさん
14/04/24 00:04:35.48 JyMg56AH
実装スレって必要なんだろうか？
作ってみたならそこで話せばいいわけだし、作れない連中の吹き溜まりなら無理に分けることもない。
966:デフォルトの名無しさん
14/04/24 00:08:57.62 fAk9I7UT
ていうか互換にできるのかと。
967:デフォルトの名無しさん
14/04/24 08:03:39.60 tXCIarBm
>>961
＞配信者のオニオンルーティングは可能だよ。逆方向のポートフォワードに近い事をすればいいだけ。
いや、それは配信者間の通信であって、「配信者」というポイントが内容の改竄を実施することは防げない
配信者間でオニオンルーティングを咬ませる意義もよくわからない
以上は配信者、というかny3ネットに参加している、という事実が外部に判明してもいい、という前提での話ではあるが
968:デフォルトの名無しさん
14/04/24 18:18:23.90 fAk9I7UT
>>967
> いや、それは配信者間の通信であって、
中継を含む配信やP2P故の潜在的な配信者って意味を除いた意味で、配信者間の通信ではない。
情報の保持配信を行う配信者とその情報を取得しようとする閲覧者の間を二重にルーティングする。
「配信者→[配信者隠蔽用のオニオンルーティング]→中継者」って通信によってトンネルを作り、
「閲覧者→[閲覧者隠蔽用のオニオンルーティング]→中継者」って通信でそのトンネルを逆走する。
配信者を示すキーを公開鍵にして暗号化すれば中継者は内容に関知できず、中継しかできない。
> 「配信者」というポイントが内容の改竄を実施することは防げない
「情報配信者の匿名」の話なんだけど改竄可能性が何か関係あんの？
そもそも、データを示すキーをデータ自体のハッシュ等にしておけば、
配信方法によらずキーが表すデータを改竄(置換)する事は出来ない。
> 配信者間でオニオンルーティングを咬ませる意義もよくわからない
自分で「配信者間」って前提で無理に解釈して意義が分らんとか言われても。
969:デフォルトの名無しさん
14/04/24 19:17:31.94 tXCIarBm
>>968
ごめん，「配信者」と「中間者」の違いがよくわからない
＞データを示すキーをデータ自体のハッシュ等に
改竄ともにハッシュ値そのものを変えられたらどうする？
たぶん発信者・配信者・中継者との意味が明確でないのだろう．私は発信者と配信者はノットイコール，配信者と中継者はイコールとしているが．
970:デフォルトの名無しさん
14/04/24 19:50:27.95 JyMg56AH
別のハッシュが捏造されて一致するなら只の改変コピペだろう。
元の投稿と取り違える方が難しくないか？
971:デフォルトの名無しさん
14/04/24 20:54:06.01 tXCIarBm
>>970
たしかに >>387 に示されているとおり，発信者が複数のノードにばら撒けばいいだけだね
972:デフォルトの名無しさん
14/04/24 20:57:15.66 fAk9I7UT
>>969
> ごめん，「配信者」と「中間者」の違いがよくわからない
中間じゃ無くて中継。中継者はオニオンルータなどの、中継したデータを閲覧も保存もしないノード
> たぶん発信者・配信者・中継者との意味が明確でないのだろう．
今言ってる配信者隠蔽の場合、役割は以下のようになる
投稿者(発信者)：中継者を介して配信者に投稿を送信する
配信者(保存者)：中継者を介して代理人となる中継者へトンネルを掘り、トンネルに届いた要求に応答する
閲覧者(受信者)：中継者を介して目的の配信者の代理人である中継者に接続し情報を要求する
中継者(代理人)：配信者からの接続が有る間、自身に届いたその配信者への通信要求をそこに転送する
中継者(オニオンルータ)：ある種の多段プロキシ、接続元から自身までの通信の暗号化を一枚解除する
誰もが保持する情報の範囲内で別の役割を担うことができる(投稿者→配信者、閲覧者→配信者)
ただ中継者は中継内容を得る訳ではないので、ある投稿の中継に参加してもその投稿の配信者にはならない
> 改竄ともにハッシュ値そのものを変えられたらどうする？
閲覧者は欲しい情報のキーを予め知っている
ハッシュ値をキーにしてるんだから、閲覧者からしたら無関係なゴミ渡されただけだし無視するだけ
ハッシュを衝突させたシノニム作って渡されたら改竄が成立するけど、強衝突性突破しなきゃ無理
973:デフォルトの名無しさん
14/04/24 21:10:23.62 tXCIarBm
>>972
配信者は単数？複数？単数なら，それは p2p ではないのでは？
配信者は複数として，配信者同士の情報交換には中継者は必要か？私は不要だと思っているが．
＞閲覧者は欲しい情報のキーを予め知っている
これはわからない．投稿者の情報を示すキーを閲覧者はどこから手に入れる？というか，あらかじめ（投稿内容を取得する前に）キーだけ入手しておく理由は？
無論，ある投稿単位のアンカーの指す先を入手するために閲覧者がキーのみ知っている状況があってもいいと思うが，すべてがそうではないのでは？
974:デフォルトの名無しさん
14/04/24 21:41:11.48 fAk9I7UT
>>973
> 配信者は単数？複数？単数なら，それは p2p ではないのでは？
説明した経路は単数。当然だけど、それを繰り返して複数にするのも可能だし普通はそうする。
DHTの場合は状況に応じて配信者は増減して、ある情報の配信者が単一になるケースも有る。
そもそもDHTだとキーに対してそれを保持するノードが有る程度の数に元々絞り込まれる構造。
> 配信者同士の情報交換には中継者は必要か？私は不要だと思っているが．
『「情報配信者の匿名」ってのが何処までできればOKなのかの話(>>953,959,961)』
の流れで書いてるんだから、配信者の隠蔽がそもそも不要だと思うならそれはそれ。
正直な話、自分も一々掲示板投稿の配信者まで隠蔽するのは大げさだと思うけど、
需要(>>953)があって実現可能なら実現すればいい。トラフィックは跳ね上がるけど。
> 投稿者の情報を示すキーを閲覧者はどこから手に入れる？
その辺は匿名ネットワーク上に構築する掲示板の構造に依存するとしかいえないが、
例えば461氏の実装(>>301)はキーは別個にブロードキャストで配信される構造だよ。
ブロックチェーンでキーをひたすら追記してもいいけどこの場合は本文も入れれるな。
975:デフォルトの名無しさん
14/04/24 22:22:12.43 tXCIarBm
>>974
なるほど、DHT が前提での話だったんだね、であれば配信者は投稿単位を保持の実体と解釈できるね。
DHT は勉強不足だから、隔靴掻痒にお感じになっていたのであれば非常にすまない。
DHT は、キーをあらかじめ知っていたとして、キーをもとに投稿単位を入手する前提となるが
そもそもどんなキーが available であるかを閲覧者に知らせるにはどうすればいいのか？
＞匿名ネットワーク上に構築する掲示板の構造に依存するとしかいえないが、
＞キーは別個にブロードキャストで配信される構造だよ。
ふむ。
976:デフォルトの名無しさん
14/04/24 23:07:34.25 a85RYCvf
torのhidden serviceを使ってDHTを構築する話でしょ。
一言で済むのに。