11/12/18 23:12:55.58
はいどうぞ。
前スレ
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
11/12/18 23:23:16.04
君が死んでからもう１年。
君は今も僕を見守ってくれているのかな？
君は、僕の生まれて初めて出来た彼女だった。
すごく嬉しくて、幸せだったなあ。
突然、白血病だって医者に宣告されてから、君は病室で日に日に弱っていった。
「病院ってひまねえ」って笑う君を見て、僕はいつも泣いていたんだ。
君の為に、僕の小汚いノートパソコンをあげたら、君はすごく喜んでくれたよね。
ネットをするようになった君がいつも見ていたサイト、それが「２チャンネル」だった。
ある日君はいつものように、笑いながら言った。
「ほら、見て今日も２ゲット出来たよ。」
「あまりパソコンばっかいじってると身体に障るよ」
なんて僕が注意すると、
「ごめんねえ。 でもね、これ見てよ。
ほら、この３のひと、２げっとぉ！なんて言っちゃってさぁ、ふふ」
僕は黙っていた。君がすごく楽しそうで、僕は何も言えなかった。
「ほらみて、この３のひと、変な絵文字使ってくやしぃ～！だって。
かわいいねえ。 ふふ。」
僕はまだ黙っていた。笑う君を見て、どうしようもなく悲しくなった。
「憶えててくれるかなあ」 君がふと言った。
「…この３のひと、私がいなくなっても、あの時変な奴に２をとられたんだよなー
なんて、憶えててくれないかなあ……無理かな……憶えてて、ほしいなぁ……」
それから数ヶ月後、君は家族と僕に見守れながら息を引き取った。
君はもうこの世に居ない、なのに僕は今F5を連続でクリックしている。
君の事を、３のひとが忘れないように、いつまでも、いつまでも忘れないように。
天国にいる君と一緒に、今ここに刻み込む
2ゲット
3:デフォルトの名無しさん
11/12/18 23:26:58.98
>>2おめでとう。
前スレのが確かなら、書き込むときにユーザー同士でメッセージを転送しまくる2chブラウザ作ればOKという話になるな。
2chという資源もそのまま使える。
4:デフォルトの名無しさん
11/12/18 23:30:48.95
素直にtor使えばいいのに。
5:デフォルトの名無しさん
11/12/18 23:32:14.55
>>3
書き込み側だけを守るというのであればそうだね
ただ実際問題として2chは管理しきれてないから警察に潰されてもおかしくない状態？例えば薬物売買の書き込みの場が
あったら幇助とされて書き込みを随時削除していたとしても管理者が逮捕される可能性もある。
同じように新規な掲示板であっても管理者負担は規模に応じて増えるから、P2Pだとその辺がクリアされていいと思う
（なんか同じ議論ばっかでまったく前に進まないスレｗ）
6:デフォルトの名無しさん
11/12/18 23:39:05.98
>>4
そう。つまり2chに規制されないプロキシを沢山見つけてくればいいじゃんってなる。まぁ環境構築が難しいって感じか。
そもそも、手間を惜しまなければ、WiFiオンにして住宅街うろつけばWEBキー設定してない野良電波が普通に見つかるしな。
>>5
まぁちっとまってくれ。法律の解釈とデザインが密接に繋がってて、無意味なもの作ってもしょうがないしな。
やっぱブラウザだけでP2Pとなると、ログ保存期間の短い単発スレの集合みたいなやつかな。ブラウザのJAVAアプレットでストレージ使わずに頑張る。
7:デフォルトの名無しさん
11/12/18 23:51:15.51
>>6
「そう」じゃねーよｗ torはその実装だっつってんのｗ
しかもこのご時勢になんでJavaｗ
ノードリストの初期の配布はどうすんの？tracker形式？
DHTなんかの仕様は？データの整合性は？関連はデータとしてどう表現するの？
その他もろもろ何にも話してないのになんで終わってんの？ｗ
8:デフォルトの名無しさん
11/12/18 23:52:56.08
>>7
javaってのはスマフォ（たぶんandroid）をクライアントとして選んだからだろ。JNIはあるけどjavaになるのはしょうがない
androidだと、表に来るアプリはいつ終了してもおかしくないから、Widgetとして実装した方がいいかもね
9:デフォルトの名無しさん
11/12/18 23:59:18.03
>>7
> 「そう」じゃねーよｗ torはその実装だっつってんのｗ
TORはその実装？なんの実装？文章の意味が分からん。
JAVAアプレットな。ブラウザで動いて、かつサーバー以外と通信できるのはJAVAアプレットだけ。
ノードリストはサーバーから貰う。
ノードの変化があれば、逐一サーバーから情報貰う。
ルーティングとかはChordでいいんじゃね？どのノードにどのノードリストを持たせるかは、サーバー側で決定する。
> その他もろもろ何にも話してないのになんで終わってんの？ｗ
なにが終わったの？文章の意味が分からない。
10:デフォルトの名無しさん
11/12/19 00:00:13.11
>>8
JAVAで実装するとAndroidで使いまわせるおいしさはあるな。
あと、P2PはUDP Hole Punchで穴あける。これは過去に作った奴もってるよ。
11:デフォルトの名無しさん
11/12/19 00:11:57.74
お前ら本気か？
ブラウザでって言ってる時点でJavaはないだろ。
12:デフォルトの名無しさん
11/12/19 00:23:02.08
他になにがあんだ？
13:デフォルトの名無しさん
11/12/19 00:28:21.06
アドオン作れ。
14:デフォルトの名無しさん
11/12/19 00:29:59.93
アドオン作るくらいなら、ネイティブアプリですき放題やるわ。
15:デフォルトの名無しさん
11/12/19 15:18:02.12
おまえらまだ出来てなかったのかよ。
俺なら３時間くらいで気分転換兼ねて作っちゃうけどな。
16:デフォルトの名無しさん
11/12/19 15:20:17.29
匿名のtwitterみたいなんでいいんじゃね？
17:デフォルトの名無しさん
11/12/19 15:41:37.61
P2Pで、アカウントを自動生成してそのアカウント＆パスワードを全員で共有、多段中継して書きこむTwitterクライアントｗ
18:デフォルトの名無しさん
11/12/19 19:19:17.84
>>7
こーいうとりあえず知ったかして、この場だけ優位な立場に立とうとして馬鹿さらす香ばしい人は、二度とこのスレに近寄らないで欲しい。
19:デフォルトの名無しさん
11/12/19 19:53:09.24
>>18
お前の視点は2ch、しかもこのスレしかないの？
法律的な話も含めてここ以外で散々話されてきた事だろうが。
20:デフォルトの名無しさん
11/12/19 19:58:13.27
>>19
そうだな。もう枯れた議論だからこのスレに書きこむ話題はないなｗ
21:デフォルトの名無しさん
11/12/19 21:07:40.79
>>2
いい話やん・・・。
22:デフォルトの名無しさん
11/12/19 21:08:53.68
>>19
>>20
久々に酷いの見たわ。
23:デフォルトの名無しさん
11/12/19 21:34:23.59
7月の段階で民主党が2兆円の復興予算を組んだとき
自民党が要請した復興予算は累計17兆円
自民党の17兆が7月時点でに決定されていたのなら
今の日本はもう少し違って居た筈だ
ちなみに関東大震災のときは復興予算として現在の価値にして150兆円以上を組んでいた。
この事実を知れば、予算の規模の小ささ、ましてや増税なんて奇知涯にも程があると思わざる負えない
帰化人だらけの民主党に復興なんて はなっから無理な話なんだよ
24:デフォルトの名無しさん
11/12/19 23:54:22.63
>>22
念のために言っておくと、>>20は>>19への皮肉だと思うよ。
25:デフォルトの名無しさん
11/12/20 03:10:33.75
Torブラウザ重すぎワロタ
26:デフォルトの名無しさん
11/12/21 00:39:15.00
2011年度 政治清潔度 ベスト10
1 ニュージーランド
2 デンマーク
3 フィンランド
4 スウェーデン
5 シンガポール
6 ノルウェー
7 オランダ
8 オーストラリア
9 スイス
10 カナダ
27:デフォルトの名無しさん
11/12/21 22:10:33.60
金子勇こと47氏の無罪が確定したから、先が見えるようになってきただろ。
28:デフォルトの名無しさん
11/12/21 22:55:47.90
Winnyは完全匿名じゃないのに？ｗ
バンバン捕まってるぞ。
29:デフォルトの名無しさん
11/12/22 01:24:25.41
>>28
バンバンのソース出せソース
30:デフォルトの名無しさん
11/12/22 02:13:28.71
P2P逮捕データベース
URLﾘﾝｸ(anond.hatelabo.jp)
31:デフォルトの名無しさん
11/12/22 02:20:24.56
思うに、掲示板というものと、匿名ネットは別インフラであってもいいんじゃないかと思うんだが。
32:デフォルトの名無しさん
11/12/22 02:25:25.09
匿名掲示板は、匿名違法コピーネットワークの
隠れ蓑として使われる言葉ですよ。
誰もそんなの本気で欲しいとは思っていませせん。
33:デフォルトの名無しさん
11/12/22 02:54:15.85
>>30
これのどの辺がWinnyばんばん？
34:デフォルトの名無しさん
11/12/22 04:31:49.44
Winnyは効率的な検索を優先してたからファイルの持ち主が持ってるファイルの情報を外部に公開してた
はっきり言って匿名でもなんでもない
Shareはアルゴリズム的にはまともで匿名だったけど
警察が民間企業の協力でネット上のトラフィックを常時監視するという
憲法違反の暴挙に出たために最初のファイル保持者が特定されるという事態になった
日本の警察は違法なことでも平気でやる
必要ならプロバイダに乗り込んでサーバーのデータすら盗む
というか既に主要ポイントのルータにはパケット監視用のマシンが設置されまくってるし
この国で実用的なP2Pを機能させるのは無理だろう
今のところ日本で通用しそうなアルゴリズムといったらオニオンルーティングくらいなもんだ
35:デフォルトの名無しさん
11/12/22 08:34:16.59
>>34
確かに令状も無いのに通信を監視するのは違法行為だな。
つかまったらその辺りを突けば無罪・・・にならないだろうなぁ。
日本の司法制度は腐ってるから。
欧米だったら無罪になった上に、国から莫大な損害賠償を得て、
ホクホクできるのだが。
36:デフォルトの名無しさん
11/12/22 08:37:59.19
> 確かに令状も無いのに通信を監視するのは違法行為だな。
それじゃWinny使っている人同士は
お互いに通信を監視しているから
みんな違法行為をしてるってことになるんじゃ？
37:デフォルトの名無しさん
11/12/22 10:35:42.43
>>34
パケット監視って、誰の金でやってるの？それだけでも莫大な金額かかるよな。プロバイダに出させてるのか。
どうやってShareの発信者特定したんだろ。
38:デフォルトの名無しさん
11/12/22 10:43:23.20
>>36
法律で禁止されてるのは２者の通信を第三者が傍受する行為
中身がデータでも電話の会話を盗聴するのと同じ行為だからね
>>37
大学が研究と称してやってたり
民間企業が警察に話を持ちかけて情報を買い取らせたりしてる
39:デフォルトの名無しさん
11/12/22 10:58:55.90
>>38
国の研究者でもいるだろ。
いろんな意味で有名なあの人とか。
40:デフォルトの名無しさん
11/12/22 11:14:58.96
むらいじゅん
41:デフォルトの名無しさん
11/12/22 12:45:21.12
ひろみちゅのつもりでした
42:デフォルトの名無しさん
11/12/22 18:55:31.80
>>34
そこで鍵交換ですよ。share はこれをやっていないから×。公開鍵はすでに解読されている。
43:デフォルトの名無しさん
11/12/22 21:25:29.48
公開鍵暗号使えばパケット監視しても意味ないよね
44:デフォルトの名無しさん
11/12/22 22:07:39.12
鍵交換しても、お作法通りにアクセスしてくるクローンとも交換するようじゃ、意味ないんだよな。
結局、公開鍵は改竄検知以上の事は出来ないと思ってる。
結局の所、何をリクエストしているか平文でも不明、くらいにならないと意味ない。
45:デフォルトの名無しさん
11/12/22 22:15:21.74
ファイル供給元->中継A->中継B->中継C->ファイル取得先
みたいにして、中継Bは中継Aがファイル供給元なのかそれとも中継人なのかが判断できないようにすればいいのかな。
中継数は固定じゃなくてランダムな確率で変動するようにして。自分が持ってるファイルも持ってない仮想ファイルも同じ
扱いでほかの人にリスト配信する形にして。転送効率は相当落ちるだろうけど匿名性は上がるはず。
ファイルのP2Pは完全にスレチだけど思わず書いてしまったorz
46:デフォルトの名無しさん
11/12/22 22:17:38.10
その時に中継しただけだから無罪！って逃げ切れるのか、と。
それこそファイルに特化したインフラだとさ。
47:デフォルトの名無しさん
11/12/23 00:38:01.92
>>45
ファイル供給元 -> [down]中継A[up] -> [down]中継B[up] -> [down]中継C[up] -> ファイル取得先
このように解釈される。
ファイル取得先 が ファイル供給元 を知っているのなら、
間のマシンはルータと同じ扱いの中継になるが、
ファイル取得先 は中継cから受け取っているだけで
ファイル供給元を認識できない仕組みにすると、
それは中継cが再送信しているとみなされる。
48:デフォルトの名無しさん
11/12/23 02:50:55.47
>>47
つまり、ファイルの中身が分かって違法コンテンツであれば、中継CはNGってこと？
暗号済みデータと公開鍵を、別ルートでやり取りすれば、中継ノードはデータの中身が分からないから、中継ノードとしてパケット監視しても違法コンテンツかどうか判断できない。
ファイル取得者としてパケット監視したら、違法コンテンツかどうか判断できる。その場合は、>>47でいうところの中継CがNGになるのか？
49:デフォルトの名無しさん
11/12/23 03:24:19.48
クローンを作ればどんな暗号化をされてようが解読は出来る
問題は解読した時のデータの中身のほう
そのデータに何のファイルがそのノードの近接に存在するかを含んでる
だから常時監視をしてる
そのノードが中継ノードかオリジナルホストかはデータだけでは判断出来ないが
オリジナルホストは何度も新規のファイルをアップロードしてるだろうから
近接ノードを常時監視することでオリジナルホストが統計学的に特定される
オニオンルーティングはこの欠点を改良したもんで
クローンを作って解読してもデータはまだ暗号化された状態にある
だから中身が分からない
50:デフォルトの名無しさん
11/12/23 03:27:10.53
中継がNGになるのは、ユーザーが違法ファイルを中継しているという認識があった、場合では？
中身が何だか分からない、どう中継されるか分からないシステムなら、罪には問えないと思う。
ただ、罪には問えない＝無罪だから逮捕されない、という意味ではなくて、逮捕される可能性
は大いにある。
51:デフォルトの名無しさん
11/12/23 08:09:35.61
誰でも分かることを自分が知らないなんて
ありえないのさ。
52:デフォルトの名無しさん
11/12/23 14:23:45.08
>>44
＞鍵交換しても、お作法通りにアクセスしてくるクローンとも交換するようじゃ、意味ないんだよな。
確かに鍵交換はクローンには無力だ。
しかし winny が鍵交換しておれば、一網打尽丸裸状態（第三者がパケットを盗聴するだけで winny 通信か判明してしまう状態）ではなくなる。
今でもユーザー数とキャッシュ量が多い winny がまずとるべき施策だと考える。
クローンは所詮、ピンポイントでしか情報を収集できない。
53:デフォルトの名無しさん
11/12/23 15:04:48.91
>>52
つーかさ、鍵とかいう話をするのなら
根本的な所を指摘しないといけない。
鍵はある。パスワードと言い換えてもいい。
しかしユーザー名が不明（匿名）で誰にでもアクセスを許可するのに
いったいパスワードが何の意味があるというのだ？
54:デフォルトの名無しさん
11/12/23 17:51:42.42
パスワードは意味あるよ
PDの場合、ファイルを暗号化してパスワードと暗号化されたデータを分離して放流してる
パスワードを取得できたノードだけが実際のデータを取得出来る
こうすることでデータ保持者ですら完全に自分の持ってるデータがわからない
鍵の保有者を配信ノードと受信ノードの２点のみに限定するオニオンルーティングの同じことだけど
PDのは予め暗号化して鍵だけ放流してしまうというアイデアはすばらしい
55:デフォルトの名無しさん
11/12/23 18:08:56.11
> パスワードを取得できたノードだけが
誰でもパスワードを取得できるのに
意味あるのか？ｗ
56:デフォルトの名無しさん
11/12/23 18:57:44.41
>>53
つURLﾘﾝｸ(ja.wikipedia.org)
つURLﾘﾝｸ(ja.wikipedia.org)
鍵を公開して第三者に対して通信を秘匿する方法は存在する。
57:デフォルトの名無しさん
11/12/23 20:46:10.33
>>56
それは、少なくとも一方が匿名じゃないのが条件。
両者が匿名かつ、鍵を公開して
成り立つ仕組みなんて無いんだよ。
58:デフォルトの名無しさん
11/12/23 20:53:06.51
>>57
「匿名」の意味がわからない。そちらの定義を教えてくれ。
たとえソースコードがオープンであっても、DH鍵交換で何の問題もなく通信の秘匿が可能だが？
59:デフォルトの名無しさん
11/12/23 21:02:09.79
>>58
匿名とは、通信相手が誰か全くわからないということ。
その状態でパスワードを送られてきたとして、
じゃあ、相手が信頼できる相手なのかどうやって判断する？
相手が誰かなんて匿名だからわからない。
パスワードが正しいとどうやって判断する？
誰にパスワードを渡すのか？
匿名（誰か全くわからない）ものに、
”誰”というキーワードは存在しない。
無作為にパスワードをばらまいて、よし、お前OKと言って
一体誰を通すというのだ？ 匿名だから誰かなんてわからない。
60:デフォルトの名無しさん
11/12/23 21:03:05.69
>>58
> たとえソースコードがオープンであっても、DH鍵交換で何の問題もなく通信の秘匿が可能だが？
そりゃ、通信相手が匿名じゃないから成り立つんだよ。
61:デフォルトの名無しさん
11/12/23 21:09:51.12
公開鍵暗号はAさんとBさんがいて、
他の誰かは見たり改ざんしたりできないってことを保証するもの。
つまり、AさんとBさんの通信ということが分かっている。
他の誰かとAさんBさんは明確に区別できる状況でないとなりたたない。
匿名ってのは誰もわからないんだから、Aさんは誰と通信しているかなんてわからない。
通信相手がBさんなのか、他の誰かなのかもわからない。
Bさんの通信が、他の誰かに改ざんされていたとしても、
本当にBさんが送ってきたものかすらもわからない。
なぜならBさんというものが存在しない世界なのだから。
62:デフォルトの名無しさん
11/12/23 21:10:40.03
>>59
匿名＝不特定多数の人間、としておく。
つURLﾘﾝｸ(ja.wikipedia.org)
を使えば、鍵を公開しても通信は第三者に対して秘匿できる。
＞じゃあ、相手が信頼できる相手なのかどうやって判断する？
それはまた別の話だ。クローン排除は確かに鍵交換では困難であることは、すでに >>52 で説明済み。
しかし、第三者に対して通信を秘匿するだけで状況は大きくかわる。
クローンは所詮、ピンポイントでしか情報を収集できない。
63:デフォルトの名無しさん
11/12/23 21:11:53.75
> を使えば、鍵を公開しても通信は第三者に対して秘匿できる。
まず、第三者という考え方が匿名ではない。
第二者と第三者は全く区別できない。
64:デフォルトの名無しさん
11/12/23 21:12:28.72
>>62
だから、別の話じゃないんだよ。
匿名で暗号化するってのが
絶対条件なんだから。
65:デフォルトの名無しさん
11/12/23 21:17:07.77
Aさん ⇔ 第三者 ⇔ Bさん
ってあいだに入って通信内容を書き換えることは可能なんだよ。
そのために、公開鍵暗号方式では、
データを受け取ったAさんは、Bさんの公開鍵を
つかって復号するという方法を取る。
つまり、Aさんは "Bさんの公開鍵” であることを知る必要があるんだよ。
だが匿名だと、公開鍵がBさんの公開鍵なのか、第三者の公開鍵なのか区別がつかない。
66: ◆QZaw55cn4c
11/12/23 21:19:30.64
>>60
もう一度確認するが、匿名の意味がよくわからない。
プログラムを書く立場からすると、接続にあたって接続先のアドレスはあらかじめ必要であるし、つながれた側はつないできた側のアドレスがわかる。
さらに、パケットを観察すれば、接続先・接続元の IP は自明だ。プロキシによる多段接続という手段はあるが、それは所詮、その場しのぎだ。
丹念にログを追跡すればいずれ判明することもあるだろう。
そういう意味では、そもそもTCP/IP ネットワークは匿名となりえない。
しかし、追跡しようにも、第三者から通信を秘匿し内容がわからないようにすれば、追跡のきっかけをあたえることもないであろう。
プロバイダに残る記録をみても、内容がわからなければ追跡はできない。
>>52
＞クローンは所詮、ピンポイントでしか情報を収集できない。
67:デフォルトの名無しさん
11/12/23 21:21:17.01
>>66
匿名の意味が分からないというのなら
違法にアップロードをしてもばれない完璧な方法と言い換えればいいよ。
そんなのがないのは当たり前、
それはそもそも俺が最初から言ってる。
匿名で暗号とか意味が無いと。
68:デフォルトの名無しさん
11/12/23 21:31:09.91
>>66
> しかし、追跡しようにも、第三者から通信を秘匿し
だから、第三者に対して通信内容を秘匿するってことは、
通信したい相手がいるってことでしょ？
その通信したい相手ってのが誰かわからないんだよ。
本当に通信したい相手なのか
実は第三者のなりすましなのかわからない。
69:デフォルトの名無しさん
11/12/23 21:41:21.36
>>65
＞ってあいだに入って通信内容を書き換えることは可能なんだよ。
そのとおりだ。>>52 前から断りはいれているとおり、クローンに対しては鍵交換は無力だ。
そういう意味であれば、匿名性の確保は不可能だ。
しかし、そのような「匿名性」は果たして必要だろうか？全ネットワークが検閲されたとしても「追跡不可能であること」で十分ではないだろうか？
70:デフォルトの名無しさん
11/12/23 21:43:30.20
>>69
話をすり替えるな。
匿名で暗闘とか無意味って話だ。
71:デフォルトの名無しさん
11/12/23 21:43:49.53
匿名で暗号とか無意味って話だ。
72: ◆QZaw55cn4c
11/12/23 22:21:29.30
>>70 >>71
すりかえてなどいない。>>42, >>52 で説明済み
52 名前：デフォルトの名無しさん[sage] 投稿日：2011/12/23(金) 14:23:45.08
>>44
＞鍵交換しても、お作法通りにアクセスしてくるクローンとも交換するようじゃ、意味ないんだよな。
確かに鍵交換はクローンには無力だ。
しかし winny が鍵交換しておれば、一網打尽丸裸状態（第三者がパケットを盗聴するだけで winny 通信か判明してしまう状態）ではなくなる。
今でもユーザー数とキャッシュ量が多い winny がまずとるべき施策だと考える。
クローンは所詮、ピンポイントでしか情報を収集できない。
73:デフォルトの名無しさん
11/12/23 22:37:17.58
>>72
話をすり替えていないというのなら、
匿名で暗号化して誰から何を守るというのですか？
それに答えなさい。
74:デフォルトの名無しさん
11/12/23 22:38:49.08
Winny通信したいなら、第三者にわざわざならなくても
直接相手に接続すればいい。
どうせ俺が誰かなんてわからないんだから
同じように接してくれるさｗ
75:デフォルトの名無しさん
11/12/23 22:55:31.91
とあるIPアドレスが持ってるファイルのリストを公開すると、
経路を暗号化しようと誰が何持ってるかは特定可能
・あるファイルの断片 (ハッシュ値とデータの組)
・あるファイルのレシピ (ハッシュ値の配列)
をバラバラに分散させたら、もはや誰が何を持ってるかはわからない
目的のファイルが完成するまですげえ時間かかるだろうけどね
76: ◆QZaw55cn4c
11/12/23 23:21:55.00
>>73
>>52
shrare は公開暗号系を使用していると考えられるが、ソース解析の結果RSA鍵を時間をかけて解読されてしまった模様。（時間をかけて素因数分解すればいいですからね）
一度 RSA 鍵が見出されてしまうと、通信の第三者からパケットは丸見えで、リアルタイムで通信内容が解析されてしまう。少なくとも、プロバイダのログ保存が意味を持つ。
しかし、DH 暗号鍵であれば、仮にソース解析されて公開鍵＝巨大素数を見つけ出されても、それだけでは手の打ちようがない。
暗号鍵は通信ごとに変えることができ、かつ、それを解読するには多大な計算能力的リソースを必要とするからだ。
さて暗号化にどれほどの意味があるか、についてだが、>>52 に述べたとおり、第三者がパケットを解読できるのとできないとでは、監視体制を構築するのに必要なコストが大きく違う。
DH暗号鍵をリアルタイムに解読するには、スーパーなんとかとかを投入しなければならないが、たかが P2P にそのような計算リソースを投入するのは、お金の無駄。
せいぜいクローンを作って、ピンポイントに吊り上げるしかないが、クローンは所詮ピンポイント。
運の悪い人間がもしかしてチェックされるかもだが、P2Pネットワーク全体の動きを把握することはできない。
キャッシュ転送を多段階にすれば、事実上追跡は不可能だから、職人も安全。
ついでにいえば、これらをクリアしている PD は無敵。あとは winny のキャッシュがそのまま利用できればいいのだが。
77: ◆QZaw55cn4c
11/12/23 23:24:41.74
>>75
それなんですね。
でも検索効率をあげるには、持っているファイルを全公開する仕様にするしかない、としか今は考えられない。
そのあたりをクリアできるといいのだが。PDはどうしてる？
78:デフォルトの名無しさん
11/12/24 00:51:22.87
44だが、つまりe2eで暗号化しようが、そのクライアント側が囮だと無意味だと。
それは、何らかの保持キーを渡す場合であって、しかし単純なファイルの交換には、リクエストには答えにゃならん。
それが、本人であろうが、転送者であろうが、要求がファイルであろうがブロックであろうが、そのハッシュであろうが。
つまりそこに無理があるんだよな。
やっぱり、インフラとファイル共有は別立てで組まないとダメだと。
79:デフォルトの名無しさん
11/12/24 00:58:08.56
なんか色々勘違いしているな。
通信を解析するのは犯罪者じゃないよ？犯罪者相手だったら、
相手は違法なことはなんでもやるから平気で通信内容を覗く。こういう相手に暗号化は必要。
だけど警察とか正義の立場から違法コピーを覗く人間は通信内容を覗くなんてことはできない。
でそういう人たちがやるテクニックは、正々堂々と直接接続するってことだ。
通信内容の傍受は目的ではない。知りたいのは相手が何を送信しているかだ。
それが分かるなら、傍受は必要ない（というか正義の立場では最初からできない）
あんたが言ってるのは、ドリフのコントと一緒だよ。
牢屋の鍵は開いてるのに、必死で鍵を取ろうとしているようなもん。
いくら鍵を取れないようにしたとしても、最初から扉は開いてるんだ。意味はない。
第三者の傍受とか考える前にまず、通信内容、何を送信可能にしているかを
誰かれかまわずスピーカーで叫ぶのをやめるべきだ。
スピーカーで叫ぶのをやめてから、初めて傍受の心配をするべきだ。
80:デフォルトの名無しさん
11/12/24 01:01:02.26
そう、だから、平文でも何をリクエストしてるかわからないインフラが必要だと言ってるんだが。
81:デフォルトの名無しさん
11/12/24 01:03:31.26
>>75
> ・あるファイルの断片 (ハッシュ値とデータの組)
> ・あるファイルのレシピ (ハッシュ値の配列)
> をバラバラに分散させたら、もはや誰が何を持ってるかはわからない
わかるぞ。
ある人が、ファイルの断片を持っているということが分かる。
ある人が、ファイルのレシピを持っているということが分かる。
確かに両方が揃わなければ、意味はないだろう。
だが、いつかは揃う。（揃わなかったら誰もファイルを手に入れられない）
そして、両方が揃った時、
あの人があの時持っていたのは、あのファイルの断片だ。
あの人があの時持っていたのは、あのファイルのレシピだ。と確定する。
82: ◆QZaw55cn4c
11/12/24 01:15:08.02
>>79
それが逆なんだなあ。
>>52 等で再三述べているとおり、クローラの個別一本釣りはそんなに怖くない。
現状キャッシュ保持自体を違法とはしないし、仮に違法とするのであれば部分しか保持しない仕様とすればいい。
所詮一本釣り、P2Pネットワーク全体の状況を把握できないつくりにすればなんら問題ない。
一方、winny, share はすでに P2P ネットワーク全体の状況を把握できる状態だ。これは、放流神にとっては危険だ。
これを可能にしているのは、パケットの暗号化が事実されていないかまたは解読されてしまったかだ。
つまり、個々の通信ごとに鍵を変えて暗号化するのが、とりあえずの良策。つまり DH鍵交換が有効なわけだ。
DH鍵交換さえ実装できれば、暗号自体は簡単なストリーム暗号、たとえば RC4 程度でもよい。無論、cryptMT あたりを採用したいところではあるが。
83:デフォルトの名無しさん
11/12/24 01:24:30.03
>>82
だからお前が言ってるのはスピーカーで騒いているのに
傍受されない方法を考えているようなもん。
お前がやろうとしている傍受は法律で禁止されているからもともとできない。
今の解析はすべて傍受ではなく、ユーザー個々に
直接つないで解析された結果。
クローラーも数が多くなると解析できるんだよ。
実際にされてるわけだし。
84:デフォルトの名無しさん
11/12/24 01:31:03.99
つーかさ、通信内容が暗号されていて傍受できないとしてもさ、
通信パターンの内容からWinnyってわかるだろうし、
そしたら通信内容を覗かないで
直接つなげばいいだけじゃなーの？
85: ◆QZaw55cn4c
11/12/24 01:39:29.02
>>83
＞お前がやろうとしている傍受は法律で禁止されているからもともとできない。
そうかな？
エシュロン等のうわさはご存じない？
詳しい方コメントをお願いいたします。
仮に傍受はなされていないものとして、しかし技術的に解読可能の状況にしておくのは決定的な弱点だ。
被疑者が最後に自白してしまうのも、その通信履歴（ダウンロード履歴とかね）を目前につきつけられてしまうからだと聞く。
これはもう傍受に等しい。
これがダウンロード履歴を技術的に取得不能であれば、私自身の感覚からいっても放流神にとってはかなり心強いと思う。
否認のまま起訴された例は寡聞にして聞かない。
＞クローラーも数が多くなると解析できるんだよ。
これはちょっと信じられない。まあ PD で自ら強度試験中であるからそのうちわかるだろう。
86: ◆QZaw55cn4c
11/12/24 01:42:01.94
>>84
＞通信パターンの内容からWinnyってわかるだろうし、
既存のプロトコル（HTTPS とかね）に似せれば第三者からの判別は困難だ。
＞直接つなげばいいだけじゃなーの？
直接接続することによって判明するのは、そのノードの保持しているキャッシュ情報だけだ。
ダウンロード情報は直接にはわからない。
87:デフォルトの名無しさん
11/12/24 01:43:55.05
> 既存のプロトコル（HTTPS とかね）に似せれば第三者からの判別は困難だ。
簡単だよ。Winnyネットワークに参加すれば
それだけでノード一覧が手に入る。
> 直接接続することによって判明するのは、そのノードの保持しているキャッシュ情報だけだ。
> ダウンロード情報は直接にはわからない。
いや、知りたいのは送信可能になっているデータのリストだからｗ
ダウンロード情報なんて欲しいとは思ってない。
88:デフォルトの名無しさん
11/12/24 01:45:15.47
まあ、玄関が開いていて誰でも入れる所に
施錠されている窓から入ろうとしているようなもんだよね。
そんな馬鹿なことする奴はいない。
89:デフォルトの名無しさん
11/12/24 01:46:33.58
> 簡単だよ。Winnyネットワークに参加すれば
> それだけでノード一覧が手に入る。
だよなｗ ちょっと自分のIPアドレスさらすだけで
相手のほうから接続しに来てくれるｗ
90: ◆QZaw55cn4c
11/12/24 01:52:40.66
>>87
＞送信可能になっているデータのリストだからｗ
それを P2P ネットワーク全体にわたって取得できるようであれば、確かに脅威だ。
第三者がパケット内容を解読可能であれば、プロバイダの過去の通信ログを機械的に検索することにより調査し、放流神を絞り込めるからね。
しかし、プロバイダ過去ログの保存がなんら意味をもたない状況に持ち込めば―― それでも放流神を特定できるというのかね？
たかだかクローラの一本釣りでそこまでできるというのであれば、これは試してみる価値がありそうだ。
91:デフォルトの名無しさん
11/12/24 01:53:14.61
>>81
わかんねえよ
ファイルの断片を要求したノードからは、
ファイルの断片を返送してくるノードしかわからない。
そのノードがどのノードと繋がってたは知らない。
断片を中継したノードは確かにファイルの断片を持ってたことになるけど
そのノードが完成したファイルを持ってたことにはならない
92:デフォルトの名無しさん
11/12/24 01:55:22.45
>>91
ん？ だから通信内容は直接接続すれば分かるんだってｗ
AがBに送っている通信内容は、
Aに直接接続して聞けば教えてくれる。
まだ、自分が玄関が開いてるのに、窓から入る方法の
話をしているってわかってないの？
93:デフォルトの名無しさん
11/12/24 01:56:01.32
初放流のファイルは、必ずP2Pでほかのノードに接続してそこにコピーする（ワンタイムキーで暗号化してキーは垂れ流し終わった後に相手に渡す）
受け取ったノードは、確率で次のノードにコピーするかそれとも自分のノードで「公開」するかを決める。
「公開」されるまでは、ほかのノードはそのファイルの存在を知ることができない。
こんな流れにしたら、放流元を突き止めにくくなるんじゃね？
完全に垂れ流す相手は、ファイルサイズやお互いの通信速度、安定性を見ながら決めることになるのかな。
結構難しそうだが。
94: ◆QZaw55cn4c
11/12/24 01:56:10.67
>>89
葱のログで一発だ。あるいは、netstat -a を定期的にスキャンするだけで、私の経験では万を超えたな。
95: ◆QZaw55cn4c
11/12/24 01:57:20.77
>>92
それが脅威かどうかが問題だ。玄関だか窓だか知らないが、そろそろ感情に訴えたたとえ話は飽きてきたんだが。
96:デフォルトの名無しさん
11/12/24 01:58:00.32
なんで物分りが悪いのかね。
ファイル交換だと、最終的には、ファイルが出来るわけだろ？
つまり、なんとか紡ぎ合わせれば、ファイルは出来るわけだろ？そうじゃないとファイルは出来ない。
と言う事は、ハッシュ持ってる奴も、中身持ってる奴も、インデックス持ってるやつも一絡げで、ただのクライアントなんだよ。
97:デフォルトの名無しさん
11/12/24 01:58:59.91
>>91
重要なことを一つ忘れている。
そのノードが完成したファイルを持ってたことにはならないというが
そのノードが完成したファイルを持っていた可能性もあるってことだ。
一番最初のノードを考えると、一番最初は両方のデータを持っている。
そして、一番最初のノードにつないだ次のノードも存在する。
そしてたままた次のノードが捜査しているノードだったらどうする？
捜査をしているノードはたくさんあるから確率的に真犯人を追い詰めることが可能なんだ。
98: ◆QZaw55cn4c
11/12/24 01:59:07.50
>>93
いい方法だが
＞キーは垂れ流し終わった後に相手に渡す
ここが弱点。プロトコルはいずれ解読されるので、キーを生で渡すのは暗号化してないも同然。
そこで DH鍵交換の出番なんです。
99:デフォルトの名無しさん
11/12/24 02:00:52.46
>>95
このたとえ話のどこが感情に訴える話なの？
窓から入れないとおっしゃいますが、そもそも玄関開いてますよ。
これ聞いて可哀想とか思うのか？
お前の頭が可哀想だわｗ
100:デフォルトの名無しさん
11/12/24 02:02:13.11
>>98
> キーを生で渡すのは暗号化してないも同然。
暗号もいつかは解読されるので、暗号化してないのと一緒ｗ
いや、公開鍵暗号方式のように、
認証局がしっかりと本人証明すればいいよ。
でも、匿名システムじゃ成り立たないね。
101:デフォルトの名無しさん
11/12/24 02:02:45.34
>>98
相手から公開鍵もらって、複合に必要なキーをそれで暗号化して渡せばいいんじゃね？
102: ◆QZaw55cn4c
11/12/24 02:02:59.38
>>97
確率的、という言葉は安易に使えない。
クローラの一本釣りだけで、確率的に放流神、と断定できるだけの情報があつまるのか？
それって信頼度何パーセントで検定すればよいのか？
2σ？3σ？
103: ◆QZaw55cn4c
11/12/24 02:03:58.85
>>100
＞暗号もいつかは解読されるので、暗号化してないのと一緒ｗ
極論にでましたか。で、そのいつかってどれくらいですか？千年？万年？
104:デフォルトの名無しさん
11/12/24 02:04:13.66
>>98
お前、技術の名前だけ知っていてその技術に必要なことを知らないだろ？
DH鍵交換だって、公開鍵をだしたのが本当に接続相手なのかを
保証する必要がある。それを匿名（接続相手がわからない）システムで
成り立つ方法があるというのなら、それを披露してみたらどうだ？
お前の話は、その技術が適用可能ってのを前提にしてるが、
その前提が間違っていることに気づけよ。
105:デフォルトの名無しさん
11/12/24 02:04:59.07
>>102
すでに、集まるのか？とか言ってる状況じゃないよ。
実際に集まってるから、逮捕者が出てるわけだ。
106:デフォルトの名無しさん
11/12/24 02:05:48.02
>>103
すでに暗号は解かれてるよ。
あと、DH鍵交換は、匿名だと成り立たないから。
107: ◆QZaw55cn4c
11/12/24 02:08:07.73
>>101
相手も同じクライアントであるし、そもそもクライアントは公開されるものだから、公開鍵となる秘密鍵の生成方法自体は公になってしまっているんですよ。
多数の素数を保持しておきランダムで選ぶ、というは手としてありうるかもしれないが（ここでは RSA暗号を仮定しています）、たかだか十個二十個であればいずれパターンを読みきられてしまう。
むしろ DH鍵交換の方が安全度が高い、と考えるべきかと。
108:デフォルトの名無しさん
11/12/24 02:09:42.51
DH鍵交換ってのは共通鍵暗号方式。
つまりソフトウェアに鍵が内蔵されている。
つまり、暗号を解かなくても
ソフトウェアを解析すれば、鍵は得られる。
そんなに時間がかからない話だな。
109: ◆QZaw55cn4c
11/12/24 02:10:18.83
>>104
だから、>>52 で、相手がクローラであることを防げない、ということはすでに述べている。
DH鍵交換でクローラの接続を排除することは不可能。
でも第三者に通信を秘匿化することで、クローラの活動を無力化できないか？と提案している。
110:デフォルトの名無しさん
11/12/24 02:11:14.95
>>107
俺はWindowsしか知らないけど、WindowsのAPIで公開鍵／秘密鍵を生成できる。それを使えば
普通に考えて鍵の強度的には大丈夫じゃないの？
111:デフォルトの名無しさん
11/12/24 02:11:25.38
>>109
> でも第三者に通信を秘匿化することで、クローラの活動を無力化できないか？と提案している。
それは無理。
匿名システムにおいて、第三者というものは存在せず
すべてが公平だから。
112:デフォルトの名無しさん
11/12/24 02:11:41.07
>>97
捜査ノードが全体のどれだけを占めてるかによるねえ。
1つのファイルを100分割して、100ノードに繋がってるとして、
それぞれに別々の断片を放流すれば、
1%が捜査ノードだとしても、捜査ノードは1つの断片しか取得できない
（確率的にその時繋いだノードが全て捜査ノードだったらアウトだけど）
113: ◆QZaw55cn4c
11/12/24 02:12:18.36
>>105
>>85
それは winny や share のような、パケット内容が暗号化されていないに等しい P2P での話だ。
114:デフォルトの名無しさん
11/12/24 02:12:37.77
>>110
その場合、公開鍵をどうやって相手に届けるかという問題がある。
そして届けた相手が正義のヒーローだったらどうする？ｗ
115:デフォルトの名無しさん
11/12/24 02:12:59.33
>>112
確かにそれが大きいね。大量にクライアント起動してくるだろうからヤバイ
116:デフォルトの名無しさん
11/12/24 02:13:07.53
>>113
> それは winny や share のような、パケット内容が暗号化されていないに等しい P2P での話だ。
パケットが暗号化されていても
ソフトウェアを解析すれば暗号は解ける。
117:デフォルトの名無しさん
11/12/24 02:14:59.45
おれ思うに、本当の暗号化ってのは、その中身をもって暗号化したものだけだと思うんだよね。
つまり、ファイルAのハッシュA'をもって暗号化したファイルαだけ。
でもそれは手に入らない(持ってる物(A)のみ、複合できる)し、手に入ったとしてファイルAの真贋性の証明にしかならないんだよ。
118:デフォルトの名無しさん
11/12/24 02:16:45.65
>>130
だから何度も言うように
そのやり方は相手の存在を認識している場合に成り立つので
匿名システムで適用不可能。
119: ◆QZaw55cn4c
11/12/24 02:17:06.76
>>108
確かに DH鍵交換は鍵内蔵だが、その鍵が判明したからといって個々の暗号の強度は落ちない。
だから、DH鍵交換は有力だ。
URLﾘﾝｸ(ja.wikipedia.org)
＞ここで第三者 Z がこの二人の通信を盗聴して A と B を入手しても、 g^a mod p と g^b mod p から K = g^(a*b) mod p を多項式時間で計算する方法は現在の所、存在しないので Z は鍵 K を生成することが困難である。
120:デフォルトの名無しさん
11/12/24 02:17:19.85
>（確率的にその時繋いだノードが全て捜査ノードだったらアウトだけど）
あ、これは時間を置いて何度かに分けて放流するとか
ある程度の断片を中継したノードに限定するとかで低めることができそう
121: ◆QZaw55cn4c
11/12/24 02:18:55.97
>>111
＞匿名システムにおいて、第三者というものは存在せずすべてが公平だから。
申し訳ないが、ここでの第三者というのは、通信当事者 2 者以外の者を指している。言葉遊びをしている場合ではない。
122:デフォルトの名無しさん
11/12/24 02:19:22.00
>>119
うん、だから通信内容が暗号されていたとしても直
接繋げば相手から欲しい情報を得られるから
暗号もクソもあったもんじゃないよねって話。
123:デフォルトの名無しさん
11/12/24 02:19:54.07
>>122
どうも、その単純なことが理解出来ないらしいね。
124:44 ◆T.CxvhQZS2
11/12/24 02:20:54.64
A'を無事に渡せれば、それはαの伝搬には全く関係ないんじゃないか？いずれ、キャッシュに全部たまる事を期待せねばならんが。
このインフラに、SNSを使うかとか。
つまり、友人の友人……(信頼できる人物まで)と、交換する。
125:デフォルトの名無しさん
11/12/24 02:21:31.09
>>124
だが、匿名なんだ。
相手が誰かなんてわからない。
126: ◆QZaw55cn4c
11/12/24 02:22:20.56
>>116
DH 鍵交換は、パケットごとに乱数等で暗号鍵を変えることが可能な方法だ。ソフトウェアの解析では暗号は解けない。
RC5-72 distributed.net の苦戦をご存知ない？
127:デフォルトの名無しさん
11/12/24 02:24:06.35
捜査機関に接続してしまったクライアントは、暗号化していようがしていまいがバレる。
だから、放流元か、それとも中継者なのか、それが分からないようなプロトコルにすればいいんじゃない？
一番最初の放流に関しては>>93みたいにして、広範囲に放流元だということが分からないようにする。
一発目から捜査機関に接続してしまっても、捜査機関は初放流なのか、初放流のためにコピーしている状
態なのかが判断できないようにする。
128: ◆QZaw55cn4c
11/12/24 02:28:41.44
>>122
直に接続されても、そこでクローラに知れるのは自分の保持キャッシュだけ、という話。
自分が放流したかどうかまではわからない。
放流神を特定するには、特定のキャッシュに絞ったとしても P2P 全体のキャッシュ保持状況をほぼ的確に保持していなければならないし、
常々蓄積されている通信ログについて、特定のキャッシュの保持状況を過去にさかのぼって検索できる状況でなければならない。
第三者による暗号解読が不可能な状況で、個々のクローラの一本釣りだけで、それができるかどうか。
129:デフォルトの名無しさん
11/12/24 03:55:04.27
かの金子氏が
「P2Pにおける匿名性の本質は、通信路の暗号化ではなくプロキシ構造にある」
と述べた（大意）のが全て。だからWinnyの暗号も適当実装
130: ◆QZaw55cn4c
11/12/24 04:31:48.47
>>129
書籍「winny の技術」が手元にあるが、それは残念な考え方であった。
理屈的には、プロバイダ等による通信ログの蓄積により、過去にさかのぼって P2P ネットワーク内でのキャッシュ分布状況を、クローラを使用しなくとも把握できてしまう状況となった。
その状況にあるだけでも、たとえば、それを利用した自白誘導操作が有効となり、放流神には過酷な状況といわざるを得ない。
winny が鍵交換を利用した簡易暗号を実装しておれば、解析にかかるコストが理論的に何桁にもわたって増大することになり、一定の抑制効果が期待できたのであったが。
winny が次に実装しなければならない仕様と考えている。
131:デフォルトの名無しさん
11/12/24 04:49:02.45
>>130
攻撃者にISPが入ってると想定するのに
中間者攻撃が行われないと仮定する妥当性が理解できないんだが
132:デフォルトの名無しさん
11/12/24 06:10:50.32
だから要はtorみたいなインフラ上に、掲示板を別だてでたてるべきなんよ。
で、掲示板同士は新着情報のみ振りまく。
133:デフォルトの名無しさん
11/12/24 07:45:28.03
俺が良い案を教えてやるよ。
データは暗号化して配信し、鍵は一切公開しない。
解読するための鍵は、データをダウンロードした
各クライアントで総当りなりの方法で解析して手に入れる。
脆弱性のある鍵や、適当に短い鍵、暗号アルゴリズムを使うとなお良い。
暗号を解読する行為自体が違法だから、民間団体はこれを解読することができない。
仮に解読したとしても、自身が犯罪者になるのだから、警察にたれ込みなどできない。
警察も令状が無ければ、勝手に他人のデータを解読したりできない。
匿名を守ろうとするから技術的に破綻するのさ。
134:デフォルトの名無しさん
11/12/24 09:20:32.38
>>133
プログラムそのものの違法性が高くなって終りじゃね？
135:デフォルトの名無しさん
11/12/24 09:40:19.59
1. 鍵とIDハッシュのマップを流す
2. 中継ノード上でListenしてもらう。
3. IDハッシュを中継ノード上から配る。
4. 双方でマップの鍵を使ってP2P開始
これでも中継ノードは「情を知って」になるのかな？
136:デフォルトの名無しさん
11/12/24 09:55:19.24
よく考えたら要件的にOLN前提だなこれ。
最初の上層のマップは下層でTorトンネルで流してもらうほか無い。
137:デフォルトの名無しさん
11/12/24 10:27:18.98
東京にある6つのキー局の内、製作から財務まで一貫して朝鮮人が行ってるテレビ局が1つ
中国共産党から毎年大量の反日工作費が流れているテレビ局が2つ
もろに北朝鮮と繋がっているテレビ局が1つ
宮城県庁を訪問する谷垣禎一（自民党）と松本龍（民主党）
URLﾘﾝｸ(www.youtube.com)
自民党と民主党の違いｗ
138:デフォルトの名無しさん
11/12/24 14:44:10.24
今までの議論をまとめるよ。
警察のデータ収集法について
１．警察は、通信を傍受することはしない。しかし暗号化すれば傍受を防ぐことができる。
２．警察は、クライアントを使ってデータ（ファイルやブロック（断片化されたファイルの一部））の送受信を監視している。これでキャッシュの分布があらかた分かっている。
誰が、または何が違法で違法じゃないかについて
「発信⇒中継⇒中継⇒・・・⇒受信」として考える。
やり取りするデータは、ファイルorブロックor暗号化ファイルと鍵セット
１．受信者が発信者を知っている場合は、中継者はルーターと同等とみなされる。
１．１．データが違法の場合、発信者がNG。中継者はOK。
２．受信者が発信者を知らない場合は、中継者がデータ発信者とみなされる。
２．１．データが違法で、中継者がファイル丸々中継した場合は、中継者はNG。
２．１．データが違法で、中継者がデータの一部のみ（ブロック、または暗号化ファイルと鍵のどちらか）を中継した場合は、中継者はOK。
139:デフォルトの名無しさん
11/12/24 14:49:14.05
>>138
GJ
これ見ると、受信者が発信者が分からないようにして、かつ、中継はキーとデータを別々に渡せばうまくいく可能性が高いってことね
140:デフォルトの名無しさん
11/12/24 14:49:36.85
掲示板とファイル共有で圧倒的に違うのは、掲示板ではデータ（会話ログ）に著作権など含まれていなければ、データ発信者に違法性はないってことだね。
書き込んだ奴が違法の場合、それを匿名にするという議論は、またちょっと違う？
141:デフォルトの名無しさん
11/12/24 14:49:47.58
ファイル供給元 -> [down]中継A[up] -> [down]中継B[up] -> [down]中継C[up] -> ファイル取得先
このように解釈される。
ファイル取得先 が ファイル供給元 を知っているのなら、
間のマシンはルータと同じ扱いの中継になるが、
ファイル取得先 は中継cから受け取っているだけで
ファイル供給元を認識できない仕組みにすると、
それは中継cが再送信しているとみなされる。
142:デフォルトの名無しさん
11/12/24 14:50:41.88
>>141
なるほどね。
そこで違法再送信が適用されるわけか。
143:デフォルトの名無しさん
11/12/24 14:53:49.19
>>141
だからキーとデータを別々に渡せば？ということ
144:デフォルトの名無しさん
11/12/24 14:57:07.95
しかし、完結してないデータの中継に違法性がないってのは本当なんかねぇ？
10分割されてたとして、10人の中継者を全員特定できれば、そいつらまとめてNGとかならんのかな。
145:デフォルトの名無しさん
11/12/24 15:13:54.47
>>140
どうだろう。例えば薬物売買スレッドがあったとして、そのスレッドを保持してるやつは、売買幇助の罪に問うとか、
そういう警察の攻め方もあるのでは？
146:デフォルトの名無しさん
11/12/24 15:13:57.32
>>143
分けた所で、データを送信するから一緒だよ。
147:デフォルトの名無しさん
11/12/24 15:15:08.19
ところでさ、パスワードが共通で誰でも復号できる暗号って
それは暗号ではなくただのデータ形式の変換だと思うんだが。
148:デフォルトの名無しさん
11/12/24 15:16:32.10
>>147
そうだよ
149:デフォルトの名無しさん
11/12/24 15:19:02.14
Winnyの暗号化通信というもの同じだな。
誰でも接続できて誰でも同じデータを取得できるのだから
あれも暗号化通信ではなく、単なるプロトコル。
150:デフォルトの名無しさん
11/12/24 15:24:54.00
>>147
変換だろうが暗号だろうが、どう呼ぼうがよくね？疑問を抱くところが、的を射てないんだが。
あと、警察は通信傍受は違法だからやらないって言ってたけど、同じロジックで、警察がクライアント使うのが違法じゃないってことは、データ中継するのは違法じゃないってこと？警察はDLだけしてキャッシュをUPしない仕組みにしてるのか？
それだとしても、キャッシュのDLは合法ってことだよね？
キャッシュデータが完成して、初めて著作権に反してるコンテンツなのか、未成年ポルノなのかとか判明するわけだよね。
未成年ポルノなんか、保有するだけで違法なのに、警察はどうやってるんだろう。
151:デフォルトの名無しさん
11/12/24 15:27:24.40
ワンタイムキーを使って暗号化して、暗号化されたデータとキーを別々のルートで、中継者を通して受信者に渡す。
中継者はキーと暗号データのセットを持っていないから、自分が中継してるのが違法ファイルなのか、合法なのか
を判断することはできない。
この状態なら中継者を罪に問うことはできても有罪にはできないと思うのだが。
152:デフォルトの名無しさん
11/12/24 15:35:00.95
>>150
落ち着けｗ
お前が言ってるのは、警察が麻薬を押収したら
麻薬所持で犯罪だって言っているようなもんだ。
警察は特権を持っている。捜査のためなら
一般の人がやったら犯罪でも、合法になるんだよ。
153:デフォルトの名無しさん
11/12/24 15:37:21.27
>>151
2つの事実を意図的に無視してるだろう？
一つは、中継者はキーと暗号データのセットを持っている場合もあるという事実。
もう一つは、中継者がダウンロードして中身を知っているファイルも送信しているという事実
154:デフォルトの名無しさん
11/12/24 15:49:28.77
>>153
1つ目は確かに意図的に無視したなｗ
実際の運用でどうやって、最終的な送信元と受信先を隠したままに複数ルートを創りだすかっていうのは難しい点だね。でも、キーと
データが揃っても中継を担う人はそれを復号しない実装にすればどうかな？ソフト上で中継者は中継に徹するのみとする。
2つ目の中継者は中身～は、普通の共有ソフトは中継したときに復号化して自分でキャッシュしてどんどん広げる役目も担うけど、
それをしない実装にすればいいと思う。つまり、常に中継者はデータを文字通り中継するだけでキャシュしない方法にしたらどうかな。
155:デフォルトの名無しさん
11/12/24 15:50:27.56
中継ではなくて再送信だ。
156:デフォルトの名無しさん
11/12/24 15:55:24.21
誰でも手に入れられる鍵で復号できるのなら
それは暗闘ではなくて、ただのデータ形式の変換だと思うよ。
157:デフォルトの名無しさん
11/12/24 16:15:12.99
>>153
> 一つは、中継者はキーと暗号データのセットを持っている場合もあるという事実。
> もう一つは、中継者がダウンロードして中身を知っているファイルも送信しているという事実
両者ともに、そーいうケースもあるだろうが、警察がクライアント使って断定することが事実上不可能ならOK？
158:デフォルトの名無しさん
11/12/24 16:17:30.03
警察だって人間なんだし、
警察だけが駄目な方法なんて存在しないだろ。
159:デフォルトの名無しさん
11/12/24 16:17:47.06
キーの生成を会えて別のノードにやってもらい
そのキーを使って暗号化したデータを放流すれば
データを放流したことにはならないのではないか？
160:デフォルトの名無しさん
11/12/24 16:18:43.45
麻薬取引会場で、警察官は立入禁止ですとか
警察官は侵入したら一兆円支払う義務がありますとか
そういうルールを作っても、警察は従う理由はないだろうな。
161:デフォルトの名無しさん
11/12/24 16:19:14.59
ファイル初放流
1.（放流神がアップフォルダにファイル追加）
2.ファイルを暗号化してキーと暗号データを別々にほかのノードにコピー（コピー先ノードは送信元が勝手に選択）
放流神 -> 中継A -> 中継B -> ファイルコピー先
3.アップフォルダからファイルを削除（この時点で放流神のPCからは放流したいファイルは消失）
4.コピー先ノードは自身がファイルを公開するか、それともさらにコピーするかを確率で決定。コピーするなら2の手順を再実行
5.公開するならネット上のほかのノードにファイルがあることを公開する
ソフトのUIでは、自分のクライアント内にキャッシュがあるかどうかは表示しない。あくまでもファイルリストを表示するだけ。
こうすることで自分のクライアント内にどんなファイルがあって公開されているのかは闇の中。つまり仮に違法ファイルの放流
に使われていても、それを意図的にしていると判断するのは難しい。初放流した人を見つけるのも困難。
162:デフォルトの名無しさん
11/12/24 16:19:22.27
>>159
データを放流したなら、それがどんなファイル形式であっても
放流に違いはないだろう。
163:デフォルトの名無しさん
11/12/24 16:20:01.38
> 2.ファイルを暗号化してキーと暗号データを別々にほかのノードにコピー
この時点で、違法にアップロードしたことが確定し、
その他のノードが警察などだったらアウトです。
164:デフォルトの名無しさん
11/12/24 16:22:30.90
>>163
そのために4の手順がある。相手が警察でも、そのときのコピー元が中継者なのか、それとも放流神なのかが判断できない
165:デフォルトの名無しさん
11/12/24 16:23:47.20
>>164
一番早くデータを送信した人が、放流犯罪者ですよ。
間違えることもあるだろうけど、何度も繰り返すと
確率的に真犯人を見つけられる。
166:デフォルトの名無しさん
11/12/24 16:24:54.97
>>164はミス。そのために中継がある。キーとデータを別々に中継して送ることでもともとの発信者が分からないようにしてる。
167:デフォルトの名無しさん
11/12/24 16:26:39.49
キーとデータを別々にした所で意味はないよ。
なぜなら、
受信した段階ではその中身がわからなくても、
データを受信した時刻を記録しておけばいい。
そうすればキーを受信してデータの中身がわかったときに、
記録していた時刻データから、一番最初に送信した人が確定するって寸法さ。
168:デフォルトの名無しさん
11/12/24 16:29:00.91
また逆もあり得るよな。
キーを一番最初送った人も怪しい。
一番最初にキーを送れる人は真犯人に間違いない。
ここから、キーもしくはデータを一番最初に送った人が
真犯人となる。危険度が2倍になってるなｗ
探索用ノードを複数放っておいて、
一番最初にキーとデータを送ったノードが一致すれば
それが真犯人に間違い無いだろう。
169:デフォルトの名無しさん
11/12/24 16:30:49.66
キーとデータの両方を持っている人は
別に別に分けて送るとなると、最初の段階で
両方持っている人は少ないだろうね。
その少ない中で、両方持っていたりしたら
怪しまれるだろう。
170:デフォルトの名無しさん
11/12/24 16:32:59.30
>>167-168
キーと暗号データを全ノードに公開する方法の場合はそうだね。
別々に送るのが有効なのは（中継は無視して）1対1の通信の場合。
171:デフォルトの名無しさん
11/12/24 16:36:08.58
>>162
すべての暗号化はそれを立証できなくするためにやってるのに
行為は同じとか的はずれなことしか言えないならもう書きこむな
172:デフォルトの名無しさん
11/12/24 16:40:02.62
>>171
断るｗ
173:デフォルトの名無しさん
11/12/24 18:53:38.76
一番最初に送信した人を確定するって、事実上不可能だろ。
警察が全てのユーザーと1ホップで繋がる量のノードを用意しないと、確定できない。
仮に警察ノードが、全体の10%のノードの繋がってても、その中で一番最初⇒家宅捜索に踏み切れんのかね？
174: ◆QZaw55cn4c
11/12/24 18:55:41.97
>>131
中間者攻撃はDH鍵交換では防げない。これは >>52 ですでに述べている。
しかし、仮に中間者攻撃＝クローラを排除できないにせよ、クローラがP2Pネットワーク全体の状況を把握しうるとは考えていない。
P2Pネットワーク全体の状況を把握できないかぎり、放流神を追い詰めるだけの十分な情報を取得できないから、少なくとも放流神は安全だ。
クローラは所詮、ピンポイントでしか情報を収集できない。
175: ◆QZaw55cn4c
11/12/24 18:59:01.43
>>138
>１．警察は、通信を傍受することはしない。
ISP にログ取得および一定期間保存を義務付けている以上、実質的に傍受しているといってよいだろう。リアルタイムにデータ解読していなければ傍受ではない、というのが彼らの用いる詭弁だ。
176: ◆QZaw55cn4c
11/12/24 19:00:53.20
>>147
通信当事者（送信者と受信者）のみが復号可能で、傍受者が復号可能でない場合、これは立派な暗号通信だ。
DH鍵交換による通信はこれにあたる。
177: ◆QZaw55cn4c
11/12/24 19:02:12.47
>>156
>>176
178: ◆QZaw55cn4c
11/12/24 19:05:19.26
>>165
＞一番早くデータを送信した人が、放流犯罪者ですよ。
これを判別できるかどうかは、一重にクローラが P2P ネットワークの状況を把握できるかどうかにかかっている。
DH鍵交換を使い、クローラがピンポイントでしかキャッシュ保持状況を観察できないようにすれば、この判定は不可能と考える。
ただし winny のように上流へ上流へとキャッシュ保持情報を送る、というのは考え直さなければならないだろう。たしかにこれはまずい。
179: ◆QZaw55cn4c
11/12/24 19:07:24.86
>>168
ISP のログを解読できれば、あるいは「キーを最初に送った人」を判別できるだろう。過去にさかのぼって溜め込まれたログを取得すればよいから。
しかし通信当事者のみ復号可能な形にすると、ISP のログ保持が事実上無意味になる。
そしてそれが可能となる方法が存在する。
DH鍵交換だ。
180:デフォルトの名無しさん
11/12/24 19:11:28.56
>>178
つまり、警察はISPの通信を傍受している⇒これによりネットワーク全体を把握している（本当か？何割のISP業者の通信カバーすれば把握できるんだ？）⇒最初の放流者が分かる。という状況だと。
ノード同士の通信を暗号化すれば、傍受によるネットワーク全体の把握が不可能になり、最初の放流者が特定できなくなると。
暗号化といったときに、ファイル内容を暗号化してばら撒くって思ってる奴と、ノード間だけで個別に暗号化通信すると思ってる奴と、2パターンいねーか？
181:デフォルトの名無しさん
11/12/24 19:20:45.19
DH、DHって何だ?そんなに推すほどすげーのか?って思ってググったらただの公開鍵/秘密鍵のことかよ
ググッて損したぜ。そんなのgdgd言うほどすげーものでも何でもない一般的な方法じゃねーかw
182:デフォルトの名無しさん
11/12/24 19:23:49.87
中途半端な奴ばかり
183: ◆QZaw55cn4c
11/12/24 19:36:37.77
>>181
＞DH、DHって何だ?そんなに推すほどすげーのか?って思ってググったらただの公開鍵/秘密鍵のことかよ
違う。通信当事者がそれぞれパラメータを互いに送るだけで、その場かぎりの鍵が生成され、結果、第三者の傍受を不可能とする方法だ。
そのパラメータや、その他公開されている情報を用いても、その場かぎりの鍵を追生成できない。
184:デフォルトの名無しさん
11/12/24 19:41:53.10
>>183
どう読んでも公開鍵/秘密鍵です。ありがとうございますw
Diffie-Hellman鍵交換
URLﾘﾝｸ(www.sophia-it.com)
URLﾘﾝｸ(ja.wikipedia.org)
185:デフォルトの名無しさん
11/12/24 19:51:15.26
受信時にたまたまデータ送信できちゃった場合も
データ送信になるのかなあ
プロトコル上は受信なんだけどーみたいなー
186:デフォルトの名無しさん
11/12/24 19:55:45.85
つーかさ、素人が法律語るなってことだよ
URLﾘﾝｸ(www.moj.go.jp)
通信履歴の電磁的記録の保全要請に関するＱ＆Ａ
Ｑ２ 通信履歴とは何ですか。電子メールの本文もこれに当たるのですか。
「通信履歴」とは，通信に関わる事項の記録のうち，通信内容を除くものをいいます。
通信内容を除くもの
通信内容を除くもの
通信内容を除くもの
187:デフォルトの名無しさん
11/12/24 19:57:09.88
通信内容保存なんてなったら、トラフィックを全部記録ってことだからありえないわなｗ
188:デフォルトの名無しさん
11/12/24 19:58:41.15
◆QZaw55cn4c「ISP にログ取得および一定期間保存を
義務付けている以上、実質的に傍受しているといってよいだろう。（ｷﾘｯ）」
「あのー通信内容は記録義務ありませんよ 」
◆QZaw55cn4c「( ﾟдﾟ)ﾎﾟｶｰﾝ 」
189:デフォルトの名無しさん
11/12/24 19:59:27.60
>>182
> 中途半端な奴ばかり
マジそう思うわｗ
190:デフォルトの名無しさん
11/12/24 20:00:47.90
公開鍵暗号、公開鍵情報共有
とでも言っておけば満足かい？
>>183
191:デフォルトの名無しさん
11/12/24 20:01:45.24
うん、もともと傍受なんてしてないんだわ
今の捜査方法は。
だからいくら傍受されても大丈夫な方法を・・・と言っても
無駄なんだわ。
今実際に行われている捜査方法は、P2Pネットワークに入って
一般の人と同じように、相手に接続して情報を集めている。
この場合、傍受を防ぐための暗号は全く意味を成さない。
192: ◆QZaw55cn4c
11/12/24 20:23:53.65
>>188
たしかに、現時点では義務付けられていないようだ。失礼。しかし、
2001年に日本はサイバー犯罪に関する条約に署名、
2011年に情報処理の高度化等に対処するための刑法等の一部を改正する法律が可決成立、
これに伴い、サーバに保存されている電磁的記録を、サーバ全体の差し押さえを伴うことなく可能となった。
これとは別に、犯罪捜査のための通信傍受に関する法律の 第13条には、
外国語による通信又は暗号その他その内容を即時に復元することができない方法を用いた通信であって、傍受の時にその内容を知ることが困難なため、傍受すべき通信に該当するかどうかを判断することができないものについては、その全部の傍受をすることができる。
とある。暗号通信の全部を傍受することは適法である。
193:デフォルトの名無しさん
11/12/24 20:29:20.67
>>192
未来の話はどうでもいいよ。
現時点での脅威として、
通信内容は義務付けられていないのに、
追跡可能になっている。
それはクローラーが脅威になっているという証拠。
194:デフォルトの名無しさん
11/12/24 20:53:02.13
年末だからみんな暇なんだねぇ
195:デフォルトの名無しさん
11/12/24 21:17:45.75
トリが知ったか君だとわかった
196:デフォルトの名無しさん
11/12/24 21:22:17.33
急造はいつ頃から出没し始めたん？
197:デフォルトの名無しさん
11/12/24 21:23:30.63
灸挫でいっか
198:デフォルトの名無しさん
11/12/24 21:28:43.42
>>76
> ソース解析の結果RSA鍵を時間をかけて解読されてしまった模様。
> （時間をかけて素因数分解すればいいですからね）
こんなこと言う馬鹿は現代の暗号技術を語るな。
特に2行目が非道い。
199:デフォルトの名無しさん
11/12/24 21:51:01.28
RSA鍵の件については本来秘密にするべき、秘密鍵が
Winnyというソフトウェアに内蔵されてしまっていたのが敗因。
Winnyを解析すれば、秘密鍵がばれる。
200:デフォルトの名無しさん
11/12/24 21:51:28.98
WinnyじゃなくてShareか？
話は同じ事だが。
201:デフォルトの名無しさん
11/12/24 22:25:04.50
Shareが正しいよ。
そっちはおいておいてだ。
>>76
> （時間をかけて素因数分解すればいいですからね）
って言った癖に、
103 名前：◆QZaw55cn4c [sage]： 2011/12/24(土) 02:03:58.85
>>100
＞暗号もいつかは解読されるので、暗号化してないのと一緒ｗ
極論にでましたか。で、そのいつかってどれくらいですか？千年？万年？
って言ってる。アホかと馬鹿かと
あー、もしかして素因数分解って本当は逆汗の事、言いたかったの？
202:デフォルトの名無しさん
11/12/24 22:29:43.89
素因数分解の計算量の話はいいっすよもうべつにここでしないでも
203:デフォルトの名無しさん
11/12/24 22:35:18.65
それでも逃げずに開発は進めるつもりなんだろ？
よしよし
204:デフォルトの名無しさん
11/12/24 23:01:59.36
今のところ暗号は解析される手間を増やす程度の意味しかないから考えなくていい
むしろ暗号化無しでも配信ノードや受信ノードが特定出来ない方法を考えないといけない
205:デフォルトの名無しさん
11/12/24 23:06:34.08
161みたいな方法でやればいんじゃね?
206:デフォルトの名無しさん
11/12/24 23:13:26.38
WinnyやShareでわかった欠点は常時起動してる人間がほんの数十人しかいないってこと
ほとんどの奴は一時的に起動してたりキャッシュを定期的に消したりしてる
だから最初の放流者がずっと放流してないと広まらない
これがもっと何十万人という規模で常時起動してたら恐らく配信者が特定されることはなかっただろう
だから単純に分散すればわからなくなるという話でもない
分散したらキャッシュが失われてデータが消え去るだけなんだよ
人間が自分勝手であるというファクターを見落とした結果だね
207:デフォルトの名無しさん
11/12/24 23:14:05.10
別に掲示板なら、配信ノード特定できてもいいんじゃね。
書き込み者が特定できなければ。
208:デフォルトの名無しさん
11/12/24 23:18:20.28
東京にある6つのキー局の内、製作から財務まで一貫して朝鮮人が行ってるテレビ局が1つ
中国共産党から毎年大量の反日工作費が流れているテレビ局が2つ
もろに北朝鮮と繋がっているテレビ局が1つ
年寄はまだまだテレビという外国人に騙され続ける
209:デフォルトの名無しさん
11/12/24 23:32:26.15
>>207
>>145
210:デフォルトの名無しさん
11/12/24 23:43:46.59
犯罪スレは撲滅できる方がいいだろう。
211: ◆QZaw55cn4c
11/12/24 23:49:36.30
>>198
おっとたしかにこれはひどい。
RSA 暗号が使われていたとして、送信側と受信側で同じソフトウェアを使うのなら、そのソフトには秘密キーが埋め込まれていると仮定せねばなるまいね。
たしかに何かを鵜呑みにしていたようだ。
ご指摘感謝だ。
212:デフォルトの名無しさん
11/12/24 23:59:07.80
秘密キーを埋め込んでるソフトは論外だよｗ
それは上で誰かが言ってるように、単なるデータ変換形式にすぎない
213:198
11/12/25 00:02:50.67
>>211
いや、
> （時間をかけて素因数分解すればいいですからね）
に文句を言ってんだよ。
時間をかけても素因数分解できないよってのが
RSA暗号の安全性の根拠なんだからさ、
具体的な指摘もなく、安全性の根拠が崩れた前提で
～～いいですからねって、お前はアホか
さらには
ご指摘感謝だとか、馬鹿にもほどってもんがある
公開鍵暗号の勉強し直しだ。
数学部数学科に行って勉強してこい
214: ◆QZaw55cn4c
11/12/25 00:08:17.82
>>213
＞時間をかけても素因数分解できないよってのがRSA暗号の安全性の根拠なんだからさ、
鍵となる素数の長さによる。今なら 2^256 くらいだとまずい。2^128 であれば個人でも解読できる。
215:デフォルトの名無しさん
11/12/25 00:10:40.28
＞213
違うよ、時間をかければ解読できるけど、かかる時間が非現実的に長いってことだよ。
216:デフォルトの名無しさん
11/12/25 00:11:31.05
>214
聞いてるとほんとお前初心者っぽいなｗ
217:デフォルトの名無しさん
11/12/25 00:15:30.49
>>216
俺は知ってた。
218:デフォルトの名無しさん
11/12/25 00:16:07.22
素因数分解の計算量がビット数に対して指数的に増える話はもういいよ。
それより>>213の数学部数学科ってなんだよｗｗｗｗｗ
219:デフォルトの名無しさん
11/12/25 00:23:34.44
>>214
公開鍵の話に触れるのは止めなよ
ボロがどんどん出てくるぞ
話を変えるけどさー、47もそこまで暗号には詳しくなさそうだったけど
住人の心を掴んで一大プロジェクトみたいになったのはなんで？
代替を提供できたからなの？
ここのコテは目玉機能として公開鍵暗号を使おうとしているけど、
その目玉機能に関しての知識もあやふやだから、みな胡散臭がってんのか
220:デフォルトの名無しさん
11/12/25 00:27:10.95
シッタカ感が出ていて、とてもプログラミングできそうもないね
コテと前スレで実装考えていた人って別でしょ？俺はそういう印象なんだけど？
221:デフォルトの名無しさん
11/12/25 00:31:29.31
>>219
アップしても捕まりませんよって
騙したから。
222:219
11/12/25 00:32:07.86
>>219の47は47氏のことね
223:デフォルトの名無しさん
11/12/25 00:32:13.43
トリップ付けてる奴は理論派（）なんでしょ。言ってみればボトムアップ型。このタイプは仕様書を考えるだけで
一杯一杯になって何も作れずに終わる。
できる奴は細かい理論は置いておいて、とりあえず動く物を作ってそれからどんどん改善策を入れていく
224:デフォルトの名無しさん
11/12/25 00:35:40.90
チャット機能もBAN機能もついてないP2Pだったから。
MXはいろいろ面倒だった。
何も持ってないでダウンロードしたら、なんかうざいこと言ってくるしさ。
暇なのか落としていると、俺が何も持ってないのを見つけたのか
いきなりダウンロードできないようにしてくるしさ。
アップは犯罪なんだから、ギブするわけないだろ
テイクするだけだよｗ
225:デフォルトの名無しさん
11/12/25 00:39:28.48
>>224
あるある。転送速度が相手の方が遅いから相手に合わせて下げたら向こうも下げて、、、の繰り返しでどんどん
転送速度低下。うざったくなって相手に速度制限なくそうってチャットしたら一瞬でDL終わりとか。ふざけんなよっ
てシステムｗｗｗ
懐かしいなMX
226:デフォルトの名無しさん
11/12/25 00:40:23.64
騙した、騙したか、ﾜﾛｽ
47氏の時は開発途中でも盛り上がってたじゃん、
ここのコテは盛り上がらないっていうか、皆に煙たがられているでしょ？
そこの違いが不思議なんだよ。
47氏は住人に好意的に受けとられていたのに、
ここのコテはうざがらてれる感があって不思議なんだ。
227:デフォルトの名無しさん
11/12/25 01:45:26.87
単純な話。ここのコテのレスは読むに耐えない
技術的に面白くもない
228:デフォルトの名無しさん
11/12/25 01:51:24.63
と、技術力のない方々がぼやくスレですね。
229:デフォルトの名無しさん
11/12/25 01:56:28.49
あれだろ？47死様を褒め称えるレスがないと
満足しないんだろ？
230:デフォルトの名無しさん
11/12/25 01:58:33.91
コテはポスドクなのか。どうりで偉ぶってるわけだ。勘違い野郎なんだな。きっと。
231:デフォルトの名無しさん
11/12/25 01:59:23.16
馬鹿な大学のポスドクとかは、学生が馬鹿すぎて、馬鹿向けの会話の仕方が身に染みちゃうんだよ。察してあげて。
232:デフォルトの名無しさん
11/12/25 02:13:02.90
>>229
金子氏がエライのは実装を書いたこと
極端な話、理論面で大したことはやってないが
業績としては非常に大きい
もちろん理論も実装も両方重要だが、
まあここのQZとかいうコテにはどちらがあるのやら……
233: ◆QZaw55cn4c
11/12/25 02:17:09.87
>>219
＞ここのコテは目玉機能として公開鍵暗号を使おうとしているけど、その目玉機能に関しての知識もあやふやだから、みな胡散臭がってんのか
DH鍵交換は RSA と違う。逆汗されても安心。
234:デフォルトの名無しさん
11/12/25 02:27:51.62
>>233
必要十分条件は満たしてないが、RSA ＝ DH鍵交換
URLﾘﾝｸ(www.sophia-it.com)
>Diffie-Hellman鍵交換を採用した代表的な公開鍵暗号としては、RSAやエルガマル法を挙げることができる。
235:デフォルトの名無しさん
11/12/25 02:32:45.75
>>234
この説明だとRSAって鍵交換アルゴリズムも含んでいるかのように読めるけど。
鍵交換とRSAは、組み合わせだと思ってたな。
236:デフォルトの名無しさん
11/12/25 02:36:30.65
>>223
それは間違ってるぞ。
仕様書ってのは最後の砦だ。プログラム上で迷うのは、仕様が定まってないとか、
逆にスイスイ進むのは一部の人間の思い込みや、他者に対する過剰な信頼に過ぎない。
仕様の段階で叩けるだけ叩かずに作った物ってのは、ただの砂上の楼閣だよ。想定外の雨が降ったらおしまい。
最初から、最初はPoCの犬小屋でもいいからミリ単位で設計すべし。と叩き込まれたし、そう思ってる。
237:デフォルトの名無しさん
11/12/25 02:41:31.42
>>236
俺は趣味の開発は最初にα版を一気に作る派だな。そうしないとモチベが下がって結局動かせず終わる。
仕事の開発は逆。仕様書をきっちり要求する。それでも後から、やっぱりこうして～、なんて言われて巻き戻るけどなｗ
238: ◆QZaw55cn4c
11/12/25 02:42:57.81
>>234
なにをもって「＝」としたのか kwsk。単に引用された文を鵜呑みにしていないか？
＞Diffie-Hellman鍵交換を採用した代表的な公開鍵暗号としては、RSAやエルガマル法を挙げることができる。
実装の面からいうと、
・RSA は通信当事者の片側が秘密鍵を二つとも所有する
・エルガマル法・DH鍵交換は通信当事者の両者が秘密キーを一つずつ所持する。
P2Pソフトを作成するとしたら、この差は大きい。
エルガマル法は暗号処理を含んでいるが、DH鍵交換は、単に通信当事者間で一つの数を共有するだけ。
その分、winny の rc4 とかお好きな暗号を選択することができる。
239:デフォルトの名無しさん
11/12/25 02:54:27.00
DH鍵交換を発展させたのがRSAだろW
>>238
実装の面から言うとA->Bにファイルを送信したいときに、RSAを使った場合は初期状態で鍵は不要。素数セットとかそういうのも不要。
つまりRSAでは両者が初期状態では鍵をまったく持っていない。
1.Bは秘密鍵・共通鍵を生成する（この時点で、このどちらの鍵もAは知らない）
2.BはAに公開鍵を送る（この時点でAはBが生成した公開鍵のみを知る）
3.Aは共通鍵を生成する（この時点で、この鍵をBは知らない）
4.Aは生成した共通鍵を使ってファイルを暗号化する
5.AはBから受け取った公開鍵を使って3で生成した共通鍵を暗号化する
6.Aは暗号化されたファイルデータと暗号化された共通鍵をBに送る
7.Bは受け取った暗号化された共通鍵を秘密鍵を使って復号する（この時点で、Bは共通鍵をGET）
8.Bは共通鍵を使って暗号化されたファイルデータを復号する（これでファイルゲット）
わざわざ共通鍵を生成するのは、公開鍵を使った暗号化は演算処理がかかるからそれを省くためね。コテは知識なさそうだから細かく
説明しちまったW
240:デフォルトの名無しさん
11/12/25 03:01:25.54
やりたいこと＼困難な問題 素因数分解問題 離散対数問題
鍵交換 RSA鍵交換 DH鍵交換
公開鍵暗号 RSA公開鍵暗号 エルガマル暗号
何にせよ、あまり本質的な話ではない
241:デフォルトの名無しさん
11/12/25 03:02:20.15
どんな暗号を使おうが、
警官が犯罪者に直接接続出来る以上いみがないのだ。
今の捜査はそうやって行われて成果を出している。
242:デフォルトの名無しさん
11/12/25 03:02:57.87
確かにまったく本質から外れてるなｗ
コテが暗号について無知すぎる・・・
243:デフォルトの名無しさん
11/12/25 03:06:01.79
>>241
だな。
だから、やるべきは直接接続されても逮捕に踏み切れないような実装を考えること。
244:デフォルトの名無しさん
11/12/25 03:10:13.81
>>243
単に匿名が欲しいだけならFreenetではだめなのかという話になると思う
どこが不満か、あるいは○○であるべきという話がないと
発展性がないと思う
245:デフォルトの名無しさん
11/12/25 03:13:08.09
>>241
そして、警察に直接接続されたとして、なにがOKでなにがNGかという議論になるんだよね。
みんな、警察が家宅捜索に踏み切る閾値が知りたいんだよね。
246:デフォルトの名無しさん
11/12/25 03:17:02.50
コテは自惚れてんだよな
公開鍵暗号について知識が乏しい癖に、
自分は公開鍵暗号について詳しいと思ってる。
コテの教授だれだよ、説教してもらってこい
247:デフォルトの名無しさん
11/12/25 03:22:18.30
エルガマルって署名だけじゃなかったっけ？
暗号化もできるんだっけ？
って書いてるうちにググればいいと気づいてググったよ。
URLﾘﾝｸ(ja.wikipedia.org)
暗号化用もだし、署名用もだし両方だった。
248:デフォルトの名無しさん
11/12/25 03:28:24.74
上のログを読んでも、例えば10分割された違法ファイルの一部を中継者が再送信したらNGかOKかもはっきり出てない。
ある発信者or中継者から10ブロック全部受信できたら、そのIPはNG？常時UPしてるユーザーが実はかなり少数で、警察が長期間ログを取ってたら、この危険性もありえる。
掲示板なら、元ファイルとかがあるわけじゃなくて、ユーザーの書き込みが蓄積されていくわけだから、はじめからスレの完全なデータを1人に持たない仕組みにすればOKなの？
249:デフォルトの名無しさん
11/12/25 03:29:05.32
A → 中継者 → B
暗号化の目的は、中継者に中身をバレないようにすること。
中継者は中身を解読できない。解読できるのはBだけ。
これはどういうことかというと、
中継者がいくらデータを受信したとしても、
解読できるのはBだけだから、
データが拡散しないということ。
250:デフォルトの名無しさん
11/12/25 03:36:33.75
>>249
データ送信：A→中継者C（複数）→B
鍵送信：A→中継者D（複数）→B
と暗号化＋多段プロキシができるとして。
Bが警察だったら、Aは突き止められないけど、CDはNG？OK？
Cが警察だったらデータの中身が分からないからOK
Dが警察だったらデータの中身が分からないからOK
CDまたはBCDが警察だったらAアウトだけど、実質そんなことは起きないだろう。
ということでOK？
251:デフォルトの名無しさん
11/12/25 03:39:39.72
>>250
警察はひとりじゃないよ。
252:デフォルトの名無しさん
11/12/25 03:41:11.50
糞コテスレ
253:デフォルトの名無しさん
11/12/25 03:43:27.49
>>250
>Bが警察だったら、Aは突き止められないけど、CDはNG？OK？
俺はCDはセーフだと思ってる。その違法ファイルを意図的に中継しているとユーザーは認識できないだろうから
>CDまたはBCDが警察だったらAアウトだけど、実質そんなことは起きないだろう。
それは起こるかもしれない。だから、BCDが警察だった場合でも、Aが中継者なのか送信元なのかが分からないようなプロトコルにするべき
254:デフォルトの名無しさん
11/12/25 03:47:43.73
>>239
分かりやすすぎワロタ
1は"秘密鍵・公開鍵を生成する"の間違いだろ
255:デフォルトの名無しさん
11/12/25 03:55:52.66
>>253
>BCDが警察だった場合でも、Aが中継者なのか送信元なのかが分からないようなプロトコルにするべき
CDがAから鍵とデータをもらったら、Aは中継だろうが発信者だろうがNGなのかね？
同じことだけど、CDが同じノードで、データと鍵を持ってたらNG？
256:デフォルトの名無しさん
11/12/25 04:06:30.55
>>255
公開鍵方法を使うなら、
ファイルデータの流れは、ファイル送信元(A) ->中継 -> ファイル受信先
鍵の流れは、ファイル送信元(A) <-中継<-ファイル受信先
流れが逆。また、鍵（公開鍵）とファイルデータを持っていてもそれを復号できないから、中継はOK
ただし問題は>>249が言っているように拡散しない点ね。
だからダウンロードとは別に拡散させるための方法が必要。参照数が多いファイルは>>161の2、4の手順を使って
適当に選んだノードに強制コピーさせて拡散させていくのがいいのかな？
257: ◆QZaw55cn4c
11/12/25 04:08:27.33
>>239
RSA の実装は、URLﾘﾝｸ(www.amazon.co.jp) を参照している。
この本では、Java のBigInteger のみを使い、剰余演算も組み込み関数を使わずに記述している。
余談だがこの本は章によってあたりはずれが激しすぎる。
>1.Bは秘密鍵・共通鍵を生成する（この時点で、このどちらの鍵もAは知らない）
鍵の元 p, q; p, q とも素数を生成。秘密鍵eと公開鍵dを生成。このとき、ed≡1(mod L), L = lcm(p - 1, q - 1)となるように e, d を設定する。
＞2.BはAに公開鍵を送る（この時点でAはBが生成した公開鍵のみを知る）
公開鍵＝(pq, e)
＞3.Aは共通鍵を生成する（この時点で、この鍵をBは知らない）
？？？？？？？なんですか？共通鍵って？
＞4.Aは生成した共通鍵を使ってファイルを暗号化する
オリジナルのメッセージを M, 暗号化されたメッセージを C としたとき、
C = M^e mod pq
A は e も pq も知っている。が、d はしらない。
＞5.AはBから受け取った公開鍵を使って3で生成した共通鍵を暗号化する
＞6.Aは暗号化されたファイルデータと暗号化された共通鍵をBに送る
？？？？？？？なんですか？共通鍵って？M だけ送ればいいんでない？
＞7.Bは受け取った暗号化された共通鍵を秘密鍵を使って復号する（この時点で、Bは共通鍵をGET）
M = C^d mod pq
・表に表れる数は、pq, e, C
C から M を求めるには、d を知らなければならない。
d を知るためには、L = lcm(p - 1, q - 1) をしらなければならない。
L を知るためには、p, q を知らなければならない。しかし、pq から p, q を知るのは困難。
共通鍵がよくわからないのですけれども、p, q, e, d, L, を使って表現するとどんな数になる？あと、共通鍵の暗号化とは何？
258:デフォルトの名無しさん
11/12/25 04:10:13.04
ｗｗｗｗｗｗｗｗｗｗｗ
259:デフォルトの名無しさん
11/12/25 04:11:56.90
>>257
お前は何もわかってないｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
260: ◆QZaw55cn4c
11/12/25 04:14:25.62
>>254
どこがわかりやすいんだ？疑問だらけだが。ちゃんと数字を使って説明してくれ。
261:デフォルトの名無しさん
11/12/25 04:14:49.80
>>256
>>250で中継がOKなのは、データを中継したノードが鍵を取得する手段がないからだよな。
暗号化したデータを拡散させる＝鍵を誰でも取得できるとなってしまって、やはり暗号化の意味がなくなってしまうのか？
262: ◆QZaw55cn4c
11/12/25 04:15:49.49
>>259
具体的に。
263:デフォルトの名無しさん
11/12/25 04:18:58.98
コテに質問。お前って暗号化のプログラミングしたことある？
数バイトのデータを暗号化／復号化じゃなくて、最低でも数MBのオーダーでね。
あと暗号関連に限らず実用的なソフト（UIもあるソフトね）を作れたことある？
264:デフォルトの名無しさん
11/12/25 04:20:18.34
>>261
暗号化するのは中継者を逮捕から守るため。どんなファイルを運んでるのか分からなくする。
だから微妙に暗号化する意味はある
265:デフォルトの名無しさん
11/12/25 04:21:11.28
>>239が例示しているのは、ただのハイブリッド暗号だと思うが
数学的な説明も何も……
266:デフォルトの名無しさん
11/12/25 04:23:01.38
>>239は具体的な実装をそのまま文章に落としてるんだよ。あの順番でそのためのAPIを呼び出せばそのまま暗号化できるｗ
RSAなりDHなりの処理をベタに実装する必要なんてないんだよ。そんなものライブラリもしくはAPIがあるんだから。
お前みたいな素人がベタに実装すると必ずバグがでて死ぬｗ
267: ◆QZaw55cn4c
11/12/25 04:24:34.50
>>263
>>257 の教科書を参照し、手元にある多桁演算ライブラリを利用して C/C++ に移植したことならある。
268:デフォルトの名無しさん
11/12/25 04:24:38.85
ここは糞コテの暗号勉強すれじゃないからな
分からないまま実装進めて住人から総スカンになるのも面白いじゃないか
269:デフォルトの名無しさん
11/12/25 04:26:55.58
>>257
公開鍵方式は演算処理を食うんだよ。だから、ファイルみたいな大きなデータを扱う場合は、公開鍵とは別に
共通鍵方式の暗号化処理を使ってファイルを暗号化する。そしてファイルの暗号化に使った共通鍵を公開鍵
で暗号化して渡す。
ぶっちゃけこんなの常識だと思うのだが・・・
270: ◆QZaw55cn4c
11/12/25 04:26:59.04
>>266
重ねて質問。共通鍵ってなに？p, q, e, d, L を使って表現してくれ。あと、共通鍵の暗号化ってなに？
数学的に記述していない教科書をコピペしただけじゃない？ちゃんと実装を追体験した？
271:デフォルトの名無しさん
11/12/25 04:27:17.49
どうやって人柱を集めるのか考えておけ
47氏みたいに安全だって騙せないといけないけど、
糞コテには騙せそうもないな
教授に泣きついて公開鍵暗号の基礎から勉強しなおせ
272:デフォルトの名無しさん
11/12/25 04:27:45.67
>>267
要するにソフトは作ったことないし、大きなサイズの暗号化もしたことがないということねｗ
273: ◆QZaw55cn4c
11/12/25 04:27:55.79
>>269
共通鍵って p, q, e, d, L を使って表現すると何になりますかね？
274: ◆QZaw55cn4c
11/12/25 04:28:29.92
>>268
共通鍵ってなに？という質問に答えられないということですね。よくわかりました。
275:デフォルトの名無しさん
11/12/25 04:28:43.83
共通鍵って大将鍵の事だよ
裸の大将って知らない？
俺はネタスレ認定した
糞コテで遊ばせてもらう
276:デフォルトの名無しさん
11/12/25 04:29:06.67
>>269
・・・・勉強になります・・・。
277:デフォルトの名無しさん
11/12/25 04:29:22.46
想像の斜め上を行くレベルでトリップが何もしないことに愕然
278: ◆QZaw55cn4c
11/12/25 04:29:56.77
>>271
教授？誰それ？
それはともかく、>>239 の共通鍵って p, q, e, d, L で表現すると何にあたるのでしょうかね。
279:デフォルトの名無しさん
11/12/25 04:30:10.17
裸の大将って山下清じゃないぞ
暗号学の概念を説明する簡単な話だぞ
280:デフォルトの名無しさん
11/12/25 04:30:21.26
じゃーべつに>>250なら、共通鍵を裸のやりとりでいいじゃん。
281: ◆QZaw55cn4c
11/12/25 04:31:21.91
>>276
ほう？
具体的な話もなにのにどう勉強になったか教えてくれるとありがたいんだが？
282:デフォルトの名無しさん
11/12/25 04:32:10.50
>>266
ブルース・シュナイアーは
そもそも専門家でないプログラマが低水準なAPIを使うな、
慎重に設計された高水準なプロトコル（SSLとか）のライブラリを使えとまで言ってたと思う
RSA一つとっても、パラメータ選択とか微妙な問題もあるようだし
283:デフォルトの名無しさん
11/12/25 04:33:45.57
糞コテは結構高齢とみた
30代後半から40代中盤くらいの年齢だろう
しかも会社の中ではうだつの上がらない糞プログラマとみた
284:デフォルトの名無しさん
11/12/25 04:34:41.16
そーいや、ラティス系の暗号化ってのもあるよね。
一般にはまだ認められてないけどね。
285:デフォルトの名無しさん
11/12/25 04:36:14.66
>>278
どれにも当たらない。まったく別の方式を使う。暗号強度さえあればどんな方法でもいい。
本当に何もわかってないな・・・
286:デフォルトの名無しさん
11/12/25 04:37:54.87
>>283
教科書とか言ってるし、確実にプログラマじゃないよ
287:デフォルトの名無しさん
11/12/25 04:38:52.95
共通鍵の部分はAESとかそんなのでいいんだよ
288:デフォルトの名無しさん
11/12/25 04:39:03.02
>>278
key = p ^ e * q ^ d (mod L)
これでいいか？もう聞くなよ
289:デフォルトの名無しさん
11/12/25 04:40:39.54
このスレはコテのお勉強用ですｗ
290:デフォルトの名無しさん
11/12/25 04:44:13.70
DESを3回かよ
291: ◆QZaw55cn4c
11/12/25 04:44:48.34
>>285
へ？じゃ、RSA暗号には適合しないんだ？じゃ、>>239 は何の説明なの？
>>286
単に書籍といわずに敬意を払っているだけ。
ｽﾚﾘﾝｸ(tech板)
>>288
＞key = p ^ e * q ^ d (mod L)
それで、復号化の処理
M = C^d mod pq
が、おっしゃる key でどう楽になるというのですかね。というか使えるのか？
292:デフォルトの名無しさん
11/12/25 04:45:12.33
>>270
ちなみに俺は実装の追体験なんてしてない。プログラマであって数学家じゃないからなW
車輪の再発見は学生時代にはやっておくべきだが、開発の場ではできるだけ避けるべきもの。
最近じゃライセンスの関係上やらなきゃいけないことも多々あるがorz
293:デフォルトの名無しさん
11/12/25 04:48:27.20
>>291
>>269を読め。ファイルの暗号化では処理が増えるからだよ
>>239はファイル転送を踏まえた上での「実装」を想定して書いてる文章
294: ◆QZaw55cn4c
11/12/25 04:55:36.13
>>293
つまり >>265 ということですか。
じゃあ、DH鍵交換で鍵を渡しておいて、あとはお好きな暗号で通信当事者が通信するのと変わらないのね。
で、RSA 暗号と DH鍵交換とどちらが P2P に適しているのですかね。私は >>233, >>238 という見解ですけど。
295:デフォルトの名無しさん
11/12/25 05:02:51.30
>>294
もう好きにしろｗｗｗｗ
実際の実装じゃ、Windowsなら5秒もあればDHからRSAに変更できるし、逆もできるからな
296: ◆QZaw55cn4c
11/12/25 05:03:27.22
>>292
だから、単なるハイブリッドを RSA として説明する（>>239)、という致命的なミスを犯すわけですね。いや、勉強になりました。
297:デフォルトの名無しさん
11/12/25 05:04:33.32
散々どうでもいい議論を引っ張り回した挙句、このざまである
298: ◆QZaw55cn4c
11/12/25 05:05:27.08
>>295
可換性と適合性とはなんの関係もないとおもいますけど。
299:デフォルトの名無しさん
11/12/25 05:08:35.31
>>296
>>239にある両者が初期でカギをもっていないとかっていうRSAの説明はあってるよ。
コテのために実際にRSAを使ってどうやって実装していくかを1～8で説明してるのでは?
300:デフォルトの名無しさん
11/12/25 05:11:43.46
>>298
変えたいときに変えれるから、本質に外れた議論をする必要はないという意味。後々の検討
課題として保留しておけばいい。
実際の開発現場でもこういうような無駄な会議をして、先に決めておくべき重要なことが後回
しになるんだよな。使えない上司を持つと困るぜｗｗ
301: ◆QZaw55cn4c
11/12/25 05:14:41.32
>>299
では、>>239 に対する >>257,>>273 の答えはなんでしょうかね。>>239 は RSA 暗号の説明ということだったら >>273 の質問に答えられるはず。
302:デフォルトの名無しさん
11/12/25 05:16:26.97
>>301
ばかすｗｗｗｗｗｗｗ
303: ◆QZaw55cn4c
11/12/25 05:17:35.33
>>300
「DH鍵交換を使えば、秘匿性がずっとましになる」という論調ですすめてきましたから、DH鍵交換と RSA とを比較することは本質に近いと思いますが。
まあ >>193 は謹聴していますが。
304: ◆QZaw55cn4c
11/12/25 05:18:47.57
>>302
とうとう思考能力を感じられないレスポンスになってきましたか。大丈夫？
305:デフォルトの名無しさん
11/12/25 05:18:52.03
こんな糞コテにプログラムは不可能です！239がプログラムするべき！
306:デフォルトの名無しさん
11/12/25 05:24:38.66
何かがおかしいと思ったら、>>233を読むと
もしかしてRSA暗号の秘密鍵をハードコードする事になってるのか？
307:デフォルトの名無しさん
11/12/25 05:26:46.35
>>306
このコテならやってくれそうだねｗ
308:デフォルトの名無しさん
11/12/25 05:27:05.26
>>269が真理だろ。
公開鍵なんて鍵長でも違うし妥当な強度なら実装なんて何でも良いんだよ。
ほんと無駄な議論だな。
309:デフォルトの名無しさん
11/12/25 05:27:35.77
javaからコードを移植して、数式読んでそれでマスターした気になってる子だから。。。
310:デフォルトの名無しさん
11/12/25 05:31:14.05
つかこのコテ、前にも作るとか言って放置してる奴だぞ。
かき回すだけかき回して楽しんでるだけの真正のクズ。
311:デフォルトの名無しさん
11/12/25 05:31:50.01
>>219の忠告を聞いて公開鍵の話に触れなきゃよかったのにね
312:デフォルトの名無しさん
11/12/25 05:33:47.81
公開鍵なんてshareでもPDでも普通に使ってるのにな。
313:デフォルトの名無しさん
11/12/25 05:41:32.64
p, q, e, d, L を使って表現すると何になるか、ってのは考える必要ないって気づくことは一生ないんだろうなｗ