P2P型の完全匿名掲示板はまだ出来ないの？その２

1 ：11/12/18 〜 最終レス ：11/12/24

はいどうぞ。
前スレ
http://toro.2ch.net/test/read.cgi/tech/1229130147/

2 ：

君が死んでからもう１年。
君は今も僕を見守ってくれているのかな？
君は、僕の生まれて初めて出来た彼女だった。
すごく嬉しくて、幸せだったなあ。
突然、白血病だって医者に宣告されてから、君は病室で日に日に弱っていった。
「病院ってひまねえ」って笑う君を見て、僕はいつも泣いていたんだ。
君の為に、僕の小汚いノートパソコンをあげたら、君はすごく喜んでくれたよね。
ネットをするようになった君がいつも見ていたサイト、それが「２チャンネル」だった。
ある日君はいつものように、笑いながら言った。
「ほら、見て今日も２ゲット出来たよ。」
「あまりパソコンばっかいじってると身体に障るよ」
なんて僕が注意すると、
「ごめんねえ。　でもね、これ見てよ。　
ほら、この３のひと、２げっとぉ！なんて言っちゃってさぁ、ふふ」
僕は黙っていた。君がすごく楽しそうで、僕は何も言えなかった。
「ほらみて、この３のひと、変な絵文字使ってくやしぃ〜！だって。
かわいいねえ。　ふふ。」　
僕はまだ黙っていた。笑う君を見て、どうしようもなく悲しくなった。
「憶えててくれるかなあ」　君がふと言った。
「…この３のひと、私がいなくなっても、あの時変な奴に２をとられたんだよなー
なんて、憶えててくれないかなあ……無理かな……憶えてて、ほしいなぁ……」
それから数ヶ月後、君は家族と僕に見守れながら息を引き取った。
君はもうこの世に居ない、なのに僕は今F5を連続でクリックしている。
君の事を、３のひとが忘れないように、いつまでも、いつまでも忘れないように。
天国にいる君と一緒に、今ここに刻み込む
2ゲット

3 ：

>>2おめでとう。
前スレのが確かなら、書き込むときにユーザー同士でメッセージを転送しまくる2chブラウザ作ればOKという話になるな。
2chという資源もそのまま使える。

4 ：

素直にtor使えばいいのに。

5 ：

>>3
書き込み側だけを守るというのであればそうだね
ただ実際問題として2chは管理しきれてないから警察に潰されてもおかしくない状態？例えば薬物売買の書き込みの場が
あったら幇助とされて書き込みを随時削除していたとしても管理者が逮捕される可能性もある。
同じように新規な掲示板であっても管理者負担は規模に応じて増えるから、P2Pだとその辺がクリアされていいと思う
（なんか同じ議論ばっかでまったく前に進まないスレｗ）

6 ：

>>4
そう。つまり2chに規制されないプロキシを沢山見つけてくればいいじゃんってなる。まぁ環境構築が難しいって感じか。
そもそも、手間を惜しまなければ、WiFiオンにして住宅街うろつけばWEBキー設定してない野良電波が普通に見つかるしな。
>>5
まぁちっとまってくれ。法律の解釈とデザインが密接に繋がってて、無意味なもの作ってもしょうがないしな。
やっぱブラウザだけでP2Pとなると、ログ保存期間の短い単発スレの集合みたいなやつかな。ブラウザのJAVAアプレットでストレージ使わずに頑張る。

7 ：

>>6
「そう」じゃねーよｗ torはその実装だっつってんのｗ
しかもこのご時勢になんでJavaｗ
ノードリストの初期の配布はどうすんの？tracker形式？
DHTなんかの仕様は？データの整合性は？関連はデータとしてどう表現するの？
その他もろもろ何にも話してないのになんで終わってんの？ｗ

8 ：

>>7
javaってのはスマフォ（たぶんandroid）をクライアントとして選んだからだろ。JNIはあるけどjavaになるのはしょうがない
androidだと、表に来るアプリはいつ終了してもおかしくないから、Widgetとして実装した方がいいかもね

9 ：

>>7
> 「そう」じゃねーよｗ torはその実装だっつってんのｗ
TORはその実装？なんの実装？文章の意味が分からん。
JAVAアプレットな。ブラウザで動いて、かつサーバー以外と通信できるのはJAVAアプレットだけ。
ノードリストはサーバーから貰う。
ノードの変化があれば、逐一サーバーから情報貰う。
ルーティングとかはChordでいいんじゃね？どのノードにどのノードリストを持たせるかは、サーバー側で決定する。
> その他もろもろ何にも話してないのになんで終わってんの？ｗ
なにが終わったの？文章の意味が分からない。

10 ：

>>8
JAVAで実装するとAndroidで使いまわせるおいしさはあるな。
あと、P2PはUDP Hole Punchで穴あける。これは過去に作った奴もってるよ。

11 ：

お前ら本気か？
ブラウザでって言ってる時点でJavaはないだろ。

12 ：

他になにがあんだ？

13 ：

アドオン作れ。

14 ：

アドオン作るくらいなら、ネイティブアプリですき放題やるわ。

15 ：

おまえらまだ出来てなかったのかよ。
俺なら３時間くらいで気分転換兼ねて作っちゃうけどな。

16 ：

匿名のtwitterみたいなんでいいんじゃね？

17 ：

P2Pで、アカウントを自動生成してそのアカウント＆パスワードを全員で共有、多段中継して書きこむTwitterクライアントｗ

18 ：

>>7
こーいうとりあえず知ったかして、この場だけ優位な立場に立とうとして馬鹿さらす香ばしい人は、二度とこのスレに近寄らないで欲しい。

19 ：

>>18
お前の視点は2ch、しかもこのスレしかないの？
法律的な話も含めてここ以外で散々話されてきた事だろうが。

20 ：

>>19
そうだな。もう枯れた議論だからこのスレに書きこむ話題はないなｗ

21 ：

>>2
いい話やん・・・。

22 ：

>>19
>>20
久々に酷いの見たわ。

23 ：

7月の段階で民主党が2兆円の復興予算を組んだとき
自民党が要請した復興予算は累計17兆円
自民党の17兆が7月時点でに決定されていたのなら
今の日本はもう少し違って居た筈だ
ちなみに関東大震災のときは復興予算として現在の価値にして150兆円以上を組んでいた。
この事実を知れば、予算の規模の小ささ、ましてや増税なんて奇知涯にも程があると思わざる負えない
帰化人だらけの民主党に復興なんて　はなっから無理な話なんだよ

24 ：

>>22
念のために言っておくと、>>20は>>19への皮肉だと思うよ。

25 ：

Torブラウザ重すぎワロタ

26 ：

2011年度　政治清潔度　ベスト10
1　　ニュージーランド
2　　デンマーク
3　　フィンランド
4　　スウェーデン
5　　シンガポール
6　　ノルウェー
7　　オランダ
8　　オーストラリア
9　　スイス
10　　カナダ

27 ：

金子勇こと47氏の無罪が確定したから、先が見えるようになってきただろ。

28 ：

Winnyは完全匿名じゃないのに？ｗ
バンバン捕まってるぞ。

29 ：

>>28
バンバンのソース出せソース

30 ：

P2P逮捕データベース
http://anond.hatelabo.jp/20110204082505

31 ：

思うに、掲示板というものと、匿名ネットは別インフラであってもいいんじゃないかと思うんだが。

32 ：

匿名掲示板は、匿名違法コピーネットワークの
隠れ蓑として使われる言葉ですよ。
誰もそんなの本気で欲しいとは思っていませせん。

33 ：

>>30
これのどの辺がWinnyばんばん？

34 ：

Winnyは効率的な検索を優先してたからファイルの持ち主が持ってるファイルの情報を外部に公開してた
はっきり言って匿名でもなんでもない
Shareはアルゴリズム的にはまともで匿名だったけど
警察が民間企業の協力でネット上のトラフィックを常時監視するという
憲法違反の暴挙に出たために最初のファイル保持者が特定されるという事態になった
日本の警察は違法なことでも平気でやる
必要ならプロバイダに乗り込んでサーバーのデータすら盗む
というか既に主要ポイントのルータにはパケット監視用のマシンが設置されまくってるし
この国で実用的なP2Pを機能させるのは無理だろう
今のところ日本で通用しそうなアルゴリズムといったらオニオンルーティングくらいなもんだ

35 ：

>>34
確かに令状も無いのに通信を監視するのは違法行為だな。
つかまったらその辺りを突けば無罪・・・にならないだろうなぁ。
日本の司法制度は腐ってるから。
欧米だったら無罪になった上に、国から莫大な損害賠償を得て、
ホクホクできるのだが。

36 ：

> 確かに令状も無いのに通信を監視するのは違法行為だな。
それじゃWinny使っている人同士は
お互いに通信を監視しているから
みんな違法行為をしてるってことになるんじゃ？

37 ：

>>34
パケット監視って、誰の金でやってるの？それだけでも莫大な金額かかるよな。プロバイダに出させてるのか。
どうやってShareの発信者特定したんだろ。

38 ：

>>36
法律で禁止されてるのは２者の通信を第三者が傍受する行為
中身がデータでも電話の会話を盗聴するのと同じ行為だからね
>>37
大学が研究と称してやってたり
民間企業が警察に話を持ちかけて情報を買い取らせたりしてる

39 ：

>>38
国の研究者でもいるだろ。
いろんな意味で有名なあの人とか。

40 ：

むらいじゅん

41 ：

ひろみちゅのつもりでした

42 ：

>>34
そこで鍵交換ですよ。share はこれをやっていないから×。公開鍵はすでに解読されている。

43 ：

公開鍵暗号使えばパケット監視しても意味ないよね

44 ：

鍵交換しても、お作法通りにアクセスしてくるクローンとも交換するようじゃ、意味ないんだよな。
結局、公開鍵は改竄検知以上の事は出来ないと思ってる。
結局の所、何をリクエストしているか平文でも不明、くらいにならないと意味ない。

45 ：

ファイル供給元->中継A->中継B->中継C->ファイル取得先
みたいにして、中継Bは中継Aがファイル供給元なのかそれとも中継人なのかが判断できないようにすればいいのかな。
中継数は固定じゃなくてランダムな確率で変動するようにして。自分が持ってるファイルも持ってない仮想ファイルも同じ
扱いでほかの人にリスト配信する形にして。転送効率は相当落ちるだろうけど匿名性は上がるはず。
ファイルのP2Pは完全にスレチだけど思わず書いてしまったorz

46 ：

その時に中継しただけだから無罪！って逃げ切れるのか、と。
それこそファイルに特化したインフラだとさ。

47 ：

>>45
ファイル供給元 -> [down]中継A[up] -> [down]中継B[up] -> [down]中継C[up] -> ファイル取得先
このように解釈される。
ファイル取得先 が ファイル供給元 を知っているのなら、
間のマシンはルータと同じ扱いの中継になるが、
ファイル取得先 は中継cから受け取っているだけで
ファイル供給元を認識できない仕組みにすると、
それは中継cが再送信しているとみなされる。

48 ：

>>47
つまり、ファイルの中身が分かって違法コンテンツであれば、中継CはNGってこと？
暗号済みデータと公開鍵を、別ルートでやり取りすれば、中継ノードはデータの中身が分からないから、中継ノードとしてパケット監視しても違法コンテンツかどうか判断できない。
ファイル取得者としてパケット監視したら、違法コンテンツかどうか判断できる。その場合は、>>47でいうところの中継CがNGになるのか？

49 ：

クローンを作ればどんな暗号化をされてようが解読は出来る
問題は解読した時のデータの中身のほう
そのデータに何のファイルがそのノードの近接に存在するかを含んでる
だから常時監視をしてる
そのノードが中継ノードかオリジナルホストかはデータだけでは判断出来ないが
オリジナルホストは何度も新規のファイルをアップロードしてるだろうから
近接ノードを常時監視することでオリジナルホストが統計学的に特定される
オニオンルーティングはこの欠点を改良したもんで
クローンを作って解読してもデータはまだ暗号化された状態にある
だから中身が分からない

50 ：

中継がNGになるのは、ユーザーが違法ファイルを中継しているという認識があった、場合では？
中身が何だか分からない、どう中継されるか分からないシステムなら、罪には問えないと思う。
ただ、罪には問えない＝無罪だから逮捕されない、という意味ではなくて、逮捕される可能性
は大いにある。

51 ：

誰でも分かることを自分が知らないなんて
ありえないのさ。

52 ：

>>44
＞鍵交換しても、お作法通りにアクセスしてくるクローンとも交換するようじゃ、意味ないんだよな。
確かに鍵交換はクローンには無力だ。
しかし winny が鍵交換しておれば、一網打尽丸裸状態（第三者がパケットを盗聴するだけで winny 通信か判明してしまう状態）ではなくなる。
今でもユーザー数とキャッシュ量が多い winny がまずとるべき施策だと考える。
クローンは所詮、ピンポイントでしか情報を収集できない。

53 ：

>>52
つーかさ、鍵とかいう話をするのなら
根本的な所を指摘しないといけない。
鍵はある。パスワードと言い換えてもいい。
しかしユーザー名が不明（匿名）で誰にでもアクセスを許可するのに
いったいパスワードが何の意味があるというのだ？

54 ：

パスワードは意味あるよ
PDの場合、ファイルを暗号化してパスワードと暗号化されたデータを分離して放流してる
パスワードを取得できたノードだけが実際のデータを取得出来る
こうすることでデータ保持者ですら完全に自分の持ってるデータがわからない
鍵の保有者を配信ノードと受信ノードの２点のみに限定するオニオンルーティングの同じことだけど
PDのは予め暗号化して鍵だけ放流してしまうというアイデアはすばらしい

55 ：

> パスワードを取得できたノードだけが
誰でもパスワードを取得できるのに
意味あるのか？ｗ

56 ：

>>53
つhttp://ja.wikipedia.org/wiki/RSA%E6%9A%97%E5%8F%B7
つhttp://ja.wikipedia.org/wiki/DH%E9%8D%B5%E4%BA%A4%E6%8F%9B
鍵を公開して第三者に対して通信を秘匿する方法は存在する。

57 ：

>>56
それは、少なくとも一方が匿名じゃないのが条件。
両者が匿名かつ、鍵を公開して
成り立つ仕組みなんて無いんだよ。

58 ：

>>57
「匿名」の意味がわからない。そちらの定義を教えてくれ。
たとえソースコードがオープンであっても、DH鍵交換で何の問題もなく通信の秘匿が可能だが？

59 ：

>>58
匿名とは、通信相手が誰か全くわからないということ。
その状態でパスワードを送られてきたとして、
じゃあ、相手が信頼できる相手なのかどうやって判断する？
相手が誰かなんて匿名だからわからない。
パスワードが正しいとどうやって判断する？
誰にパスワードを渡すのか？
匿名（誰か全くわからない）ものに、
”誰”というキーワードは存在しない。
無作為にパスワードをばらまいて、よし、お前OKと言って
一体誰を通すというのだ？ 匿名だから誰かなんてわからない。

60 ：

>>58
> たとえソースコードがオープンであっても、DH鍵交換で何の問題もなく通信の秘匿が可能だが？
そりゃ、通信相手が匿名じゃないから成り立つんだよ。

61 ：

公開鍵暗号はAさんとBさんがいて、
他の誰かは見たり改ざんしたりできないってことを保証するもの。
つまり、AさんとBさんの通信ということが分かっている。
他の誰かとAさんBさんは明確に区別できる状況でないとなりたたない。
匿名ってのは誰もわからないんだから、Aさんは誰と通信しているかなんてわからない。
通信相手がBさんなのか、他の誰かなのかもわからない。
Bさんの通信が、他の誰かに改ざんされていたとしても、
本当にBさんが送ってきたものかすらもわからない。
なぜならBさんというものが存在しない世界なのだから。

62 ：

>>59
匿名＝不特定多数の人間、としておく。
つhttp://ja.wikipedia.org/wiki/DH%E9%8D%B5%E4%BA%A4%E6%8F%9B
を使えば、鍵を公開しても通信は第三者に対して秘匿できる。
＞じゃあ、相手が信頼できる相手なのかどうやって判断する？
それはまた別の話だ。クローン排除は確かに鍵交換では困難であることは、すでに >>52 で説明済み。
しかし、第三者に対して通信を秘匿するだけで状況は大きくかわる。
クローンは所詮、ピンポイントでしか情報を収集できない。

63 ：

> を使えば、鍵を公開しても通信は第三者に対して秘匿できる。
まず、第三者という考え方が匿名ではない。
第二者と第三者は全く区別できない。

64 ：

>>62
だから、別の話じゃないんだよ。
匿名で暗号化するってのが
絶対条件なんだから。

65 ：

Aさん　⇔　第三者　⇔　Bさん
ってあいだに入って通信内容を書き換えることは可能なんだよ。
そのために、公開鍵暗号方式では、
データを受け取ったAさんは、Bさんの公開鍵を
つかって復号するという方法を取る。
つまり、Aさんは "Bさんの公開鍵” であることを知る必要があるんだよ。
だが匿名だと、公開鍵がBさんの公開鍵なのか、第三者の公開鍵なのか区別がつかない。

66 ：

>>60
もう一度確認するが、匿名の意味がよくわからない。
プログラムを書く立場からすると、接続にあたって接続先のアドレスはあらかじめ必要であるし、つながれた側はつないできた側のアドレスがわかる。
さらに、パケットを観察すれば、接続先・接続元の IP は自明だ。プロキシによる多段接続という手段はあるが、それは所詮、その場しのぎだ。
丹念にログを追跡すればいずれ判明することもあるだろう。
そういう意味では、そもそもTCP/IP ネットワークは匿名となりえない。
しかし、追跡しようにも、第三者から通信を秘匿し内容がわからないようにすれば、追跡のきっかけをあたえることもないであろう。
プロバイダに残る記録をみても、内容がわからなければ追跡はできない。
>>52
＞クローンは所詮、ピンポイントでしか情報を収集できない。

67 ：

>>66
匿名の意味が分からないというのなら
違法にアップロードをしてもばれない完璧な方法と言い換えればいいよ。
そんなのがないのは当たり前、
それはそもそも俺が最初から言ってる。
匿名で暗号とか意味が無いと。

68 ：

>>66
> しかし、追跡しようにも、第三者から通信を秘匿し
だから、第三者に対して通信内容を秘匿するってことは、
通信したい相手がいるってことでしょ？
その通信したい相手ってのが誰かわからないんだよ。
本当に通信したい相手なのか
実は第三者のなりすましなのかわからない。

69 ：

>>65
＞ってあいだに入って通信内容を書き換えることは可能なんだよ。
そのとおりだ。>>52 前から断りはいれているとおり、クローンに対しては鍵交換は無力だ。
そういう意味であれば、匿名性の確保は不可能だ。
しかし、そのような「匿名性」は果たして必要だろうか？全ネットワークが検閲されたとしても「追跡不可能であること」で十分ではないだろうか？

70 ：

>>69
話をすり替えるな。
匿名で暗闘とか無意味って話だ。

71 ：

匿名で暗号とか無意味って話だ。

72 ：

>>70 >>71
すりかえてなどいない。>>42, >>52 で説明済み
52 名前：デフォルトの名無しさん[sage] 投稿日：2011/12/23(金) 14:23:45.08
>>44
＞鍵交換しても、お作法通りにアクセスしてくるクローンとも交換するようじゃ、意味ないんだよな。
確かに鍵交換はクローンには無力だ。
しかし winny が鍵交換しておれば、一網打尽丸裸状態（第三者がパケットを盗聴するだけで winny 通信か判明してしまう状態）ではなくなる。
今でもユーザー数とキャッシュ量が多い winny がまずとるべき施策だと考える。
クローンは所詮、ピンポイントでしか情報を収集できない。

73 ：

>>72
話をすり替えていないというのなら、
匿名で暗号化して誰から何を守るというのですか？
それに答えなさい。

74 ：

Winny通信したいなら、第三者にわざわざならなくても
直接相手に接続すればいい。
どうせ俺が誰かなんてわからないんだから
同じように接してくれるさｗ

75 ：

とあるIPアドレスが持ってるファイルのリストを公開すると、
経路を暗号化しようと誰が何持ってるかは特定可能
・あるファイルの断片 (ハッシュ値とデータの組)
・あるファイルのレシピ (ハッシュ値の配列)
をバラバラに分散させたら、もはや誰が何を持ってるかはわからない
目的のファイルが完成するまですげえ時間かかるだろうけどね

76 ：

>>73
>>52
shrare は公開暗号系を使用していると考えられるが、ソース解析の結果RSA鍵を時間をかけて解読されてしまった模様。（時間をかけて素因数分解すればいいですからね）
一度 RSA 鍵が見出されてしまうと、通信の第三者からパケットは丸見えで、リアルタイムで通信内容が解析されてしまう。少なくとも、プロバイダのログ保存が意味を持つ。
しかし、DH 暗号鍵であれば、仮にソース解析されて公開鍵＝巨大素数を見つけ出されても、それだけでは手の打ちようがない。
暗号鍵は通信ごとに変えることができ、かつ、それを解読するには多大な計算能力的リソースを必要とするからだ。
さて暗号化にどれほどの意味があるか、についてだが、>>52 に述べたとおり、第三者がパケットを解読できるのとできないとでは、監視体制を構築するのに必要なコストが大きく違う。
DH暗号鍵をリアルタイムに解読するには、スーパーなんとかとかを投入しなければならないが、たかが P2P にそのような計算リソースを投入するのは、お金の無駄。
せいぜいクローンを作って、ピンポイントに吊り上げるしかないが、クローンは所詮ピンポイント。
運の悪い人間がもしかしてチェックされるかもだが、P2Pネットワーク全体の動きを把握することはできない。
キャッシュ転送を多段階にすれば、事実上追跡は不可能だから、職人も安全。
ついでにいえば、これらをクリアしている PD は無敵。あとは winny のキャッシュがそのまま利用できればいいのだが。

77 ：

>>75
それなんですね。
でも検索効率をあげるには、持っているファイルを全公開する仕様にするしかない、としか今は考えられない。
そのあたりをクリアできるといいのだが。PDはどうしてる？

78 ：

44だが、つまりe2eで暗号化しようが、そのクライアント側が囮だと無意味だと。
それは、何らかの保持キーを渡す場合であって、しかし単純なファイルの交換には、リクエストには答えにゃならん。
それが、本人であろうが、転送者であろうが、要求がファイルであろうがブロックであろうが、そのハッシュであろうが。
つまりそこに無理があるんだよな。
やっぱり、インフラとファイル共有は別立てで組まないとダメだと。

79 ：

なんか色々勘違いしているな。
通信を解析するのは犯罪者じゃないよ？犯罪者相手だったら、
相手は違法なことはなんでもやるから平気で通信内容を覗く。こういう相手に暗号化は必要。
だけど警察とか正義の立場から違法コピーを覗く人間は通信内容を覗くなんてことはできない。
でそういう人たちがやるテクニックは、正々堂々と直接接続するってことだ。
通信内容の傍受は目的ではない。知りたいのは相手が何を送信しているかだ。
それが分かるなら、傍受は必要ない（というか正義の立場では最初からできない）
あんたが言ってるのは、ドリフのコントと一緒だよ。
牢屋の鍵は開いてるのに、必死で鍵を取ろうとしているようなもん。
いくら鍵を取れないようにしたとしても、最初から扉は開いてるんだ。意味はない。
第三者の傍受とか考える前にまず、通信内容、何を送信可能にしているかを
誰かれかまわずスピーカーで叫ぶのをやめるべきだ。
スピーカーで叫ぶのをやめてから、初めて傍受の心配をするべきだ。

80 ：

そう、だから、平文でも何をリクエストしてるかわからないインフラが必要だと言ってるんだが。

81 ：

>>75
> ・あるファイルの断片 (ハッシュ値とデータの組)
> ・あるファイルのレシピ (ハッシュ値の配列)
> をバラバラに分散させたら、もはや誰が何を持ってるかはわからない
わかるぞ。
ある人が、ファイルの断片を持っているということが分かる。
ある人が、ファイルのレシピを持っているということが分かる。
確かに両方が揃わなければ、意味はないだろう。
だが、いつかは揃う。（揃わなかったら誰もファイルを手に入れられない）
そして、両方が揃った時、
あの人があの時持っていたのは、あのファイルの断片だ。
あの人があの時持っていたのは、あのファイルのレシピだ。と確定する。

82 ：

>>79
それが逆なんだなあ。
>>52 等で再三述べているとおり、クローラの個別一本釣りはそんなに怖くない。
現状キャッシュ保持自体を違法とはしないし、仮に違法とするのであれば部分しか保持しない仕様とすればいい。
所詮一本釣り、P2Pネットワーク全体の状況を把握できないつくりにすればなんら問題ない。
一方、winny, share はすでに P2P ネットワーク全体の状況を把握できる状態だ。これは、放流神にとっては危険だ。
これを可能にしているのは、パケットの暗号化が事実されていないかまたは解読されてしまったかだ。
つまり、個々の通信ごとに鍵を変えて暗号化するのが、とりあえずの良策。つまり DH鍵交換が有効なわけだ。
DH鍵交換さえ実装できれば、暗号自体は簡単なストリーム暗号、たとえば RC4 程度でもよい。無論、cryptMT あたりを採用したいところではあるが。

83 ：

>>82
だからお前が言ってるのはスピーカーで騒いているのに
傍受されない方法を考えているようなもん。
お前がやろうとしている傍受は法律で禁止されているからもともとできない。
今の解析はすべて傍受ではなく、ユーザー個々に
直接つないで解析された結果。
クローラーも数が多くなると解析できるんだよ。
実際にされてるわけだし。

84 ：

つーかさ、通信内容が暗号されていて傍受できないとしてもさ、
通信パターンの内容からWinnyってわかるだろうし、
そしたら通信内容を覗かないで
直接つなげばいいだけじゃなーの？

85 ：

>>83
＞お前がやろうとしている傍受は法律で禁止されているからもともとできない。
そうかな？
エシュロン等のうわさはご存じない？
詳しい方コメントをお願いいたします。
仮に傍受はなされていないものとして、しかし技術的に解読可能の状況にしておくのは決定的な弱点だ。
被疑者が最後に自白してしまうのも、その通信履歴（ダウンロード履歴とかね）を目前につきつけられてしまうからだと聞く。
これはもう傍受に等しい。
これがダウンロード履歴を技術的に取得不能であれば、私自身の感覚からいっても放流神にとってはかなり心強いと思う。
否認のまま起訴された例は寡聞にして聞かない。
＞クローラーも数が多くなると解析できるんだよ。
これはちょっと信じられない。まあ PD で自ら強度試験中であるからそのうちわかるだろう。

86 ：

>>84
＞通信パターンの内容からWinnyってわかるだろうし、
既存のプロトコル（HTTPS とかね）に似せれば第三者からの判別は困難だ。
＞直接つなげばいいだけじゃなーの？
直接接続することによって判明するのは、そのノードの保持しているキャッシュ情報だけだ。
ダウンロード情報は直接にはわからない。

87 ：

> 既存のプロトコル（HTTPS とかね）に似せれば第三者からの判別は困難だ。
簡単だよ。Winnyネットワークに参加すれば
それだけでノード一覧が手に入る。
> 直接接続することによって判明するのは、そのノードの保持しているキャッシュ情報だけだ。
> ダウンロード情報は直接にはわからない。
いや、知りたいのは送信可能になっているデータのリストだからｗ
ダウンロード情報なんて欲しいとは思ってない。

88 ：

まあ、玄関が開いていて誰でも入れる所に
施錠されている窓から入ろうとしているようなもんだよね。
そんな馬鹿なことする奴はいない。

89 ：

> 簡単だよ。Winnyネットワークに参加すれば
> それだけでノード一覧が手に入る。
だよなｗ　ちょっと自分のIPアドレスさらすだけで
相手のほうから接続しに来てくれるｗ

90 ：

>>87
＞送信可能になっているデータのリストだからｗ
それを P2P ネットワーク全体にわたって取得できるようであれば、確かに脅威だ。
第三者がパケット内容を解読可能であれば、プロバイダの過去の通信ログを機械的に検索することにより調査し、放流神を絞り込めるからね。
しかし、プロバイダ過去ログの保存がなんら意味をもたない状況に持ち込めば――― それでも放流神を特定できるというのかね？
たかだかクローラの一本釣りでそこまでできるというのであれば、これは試してみる価値がありそうだ。

91 ：

>>81
わかんねえよ
ファイルの断片を要求したノードからは、
ファイルの断片を返送してくるノードしかわからない。
そのノードがどのノードと繋がってたは知らない。
断片を中継したノードは確かにファイルの断片を持ってたことになるけど
そのノードが完成したファイルを持ってたことにはならない

92 ：

>>91
ん？　だから通信内容は直接接続すれば分かるんだってｗ
AがBに送っている通信内容は、
Aに直接接続して聞けば教えてくれる。
まだ、自分が玄関が開いてるのに、窓から入る方法の
話をしているってわかってないの？

93 ：

初放流のファイルは、必ずP2Pでほかのノードに接続してそこにコピーする（ワンタイムキーで暗号化してキーは垂れ流し終わった後に相手に渡す）
受け取ったノードは、確率で次のノードにコピーするかそれとも自分のノードで「公開」するかを決める。
「公開」されるまでは、ほかのノードはそのファイルの存在を知ることができない。
こんな流れにしたら、放流元を突き止めにくくなるんじゃね？
完全に垂れ流す相手は、ファイルサイズやお互いの通信速度、安定性を見ながら決めることになるのかな。
結構難しそうだが。

94 ：

>>89
葱のログで一発だ。あるいは、netstat -a を定期的にスキャンするだけで、私の経験では万を超えたな。

95 ：

>>92
それが脅威かどうかが問題だ。玄関だか窓だか知らないが、そろそろ感情に訴えたたとえ話は飽きてきたんだが。

96 ：

なんで物分りが悪いのかね。
ファイル交換だと、最終的には、ファイルが出来るわけだろ？
つまり、なんとか紡ぎ合わせれば、ファイルは出来るわけだろ？そうじゃないとファイルは出来ない。
と言う事は、ハッシュ持ってる奴も、中身持ってる奴も、インデックス持ってるやつも一絡げで、ただのクライアントなんだよ。

97 ：

>>91
重要なことを一つ忘れている。
そのノードが完成したファイルを持ってたことにはならないというが
そのノードが完成したファイルを持っていた可能性もあるってことだ。
一番最初のノードを考えると、一番最初は両方のデータを持っている。
そして、一番最初のノードにつないだ次のノードも存在する。
そしてたままた次のノードが捜査しているノードだったらどうする？
捜査をしているノードはたくさんあるから確率的に真犯人を追い詰めることが可能なんだ。

98 ：

>>93
いい方法だが
＞キーは垂れ流し終わった後に相手に渡す
ここが弱点。プロトコルはいずれ解読されるので、キーを生で渡すのは暗号化してないも同然。
そこで DH鍵交換の出番なんです。

99 ：

>>95
このたとえ話のどこが感情に訴える話なの？
窓から入れないとおっしゃいますが、そもそも玄関開いてますよ。
これ聞いて可哀想とか思うのか？
お前の頭が可哀想だわｗ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
41: C/C++の宿題片付けます 154代目 (781)
42: 【超高速】C/C++に代わる低級言語を開発したい 7 (641)
43: COBOL vs Java 2戦目 (949)
44: JAVAとか未だに使ってる奴いんの (209)