Linny開発プロジェクト Part2

1 名前：login:Penguin mailto:sage [03/06/22 19:40 ID:zhqumg4k] 今までのP2Pファイル共有ソフトに負けない機能、手軽さ、匿名性を備えた 全く新しいWWWベースのファイル共有ソフトを作るプロジェクトです。 -------------------- 535 ◆HO0OFh2RXI 氏による最初の発言 -------------------- 03/04/30 23:19 pc.2ch.net/test/read.cgi/linux/1024473956/535 > みんなでデーモンとして動くようなLinux版Winnyつくらない？ > デーモンとして動かなくてもコンソールで使えればいいです。 > どうでしょうか？自分は、Linux C(C++)プログラマーです。 前スレ Linny開発プロジェクト pc.2ch.net/test/read.cgi/linux/1053087824/ Project Page linny.sourceforge.jp/ 議論用Wiki linny.sourceforge.jp/wiki/ ※プロジェクト参加希望の方は535氏<burner@users.sourceforge.jp>まで連絡してください。 　また、本格的に参加する場合はSourceForge.jpのアカウントを取得してください。 244 名前：login:Penguin mailto:sage [03/12/04 02:10 ID:0dWBPS/h] ソフト開発出来る人、参加して下さい。オープンソースでの開発を目標にしています。 次期P2Pの仕様　part5 tmp2.2ch.net/test/read.cgi/download/1070113264/ 245 名前：login:Penguin [03/12/04 02:10 ID:0dWBPS/h] age忘れました。 246 名前：login:Penguin mailto:sage [03/12/04 05:04 ID:AK3fWQow] >>244 コードは書けんが、テストなら協力できますよ 247 名前：login:Penguin mailto:sage [03/12/04 08:15 ID:LZsdqusC] >>244 アップはできんが、ダウンなら協力できますよ 248 名前：login:Penguin mailto:sage [03/12/06 16:41 ID:ASv9zxaf] 典型的なプロジェクト失敗例を見せてくれたスレ 249 名前：login:Penguin mailto:sage [03/12/07 00:28 ID:1ZK45BnP] プロジェクトにすらなってないけどな 250 名前：login:Penguin [03/12/20 19:45 ID:uF39G1i3] mute-net.sourceforge.net/ > MUTE File Sharing is a new peer-to-peer network > that provides easy search-and-download functionality while also protecting your privacy. > MUTE protects your privacy by avoiding direct connections with > your sharing partners in the network. だそうです。 251 名前：login:Penguin mailto:sage [03/12/20 20:17 ID:orBV6cTG] pc.2ch.net/test/read.cgi/prog/1071794941/l50 252 名前：login:Penguin mailto:sage [03/12/21 00:53 ID:Tnk+ergb] >>250 これ、期待できそうです。 253 名前：login:Penguin [03/12/21 01:21 ID:7KaUReeK] で、251のスレでWinny2のソースらしきものが張られているわけだが・・・。 254 名前：login:Penguin mailto:sage [03/12/21 01:42 ID:UW66JoV+] >>253 ところで、パスワードは割りましたか？ 255 名前：login:Penguin mailto:sage [03/12/22 05:22 ID:Fx01jsVP] >>254 ﾀﾞｳｿすらできてないわけだが・・・。 どのプロキシ使えば落とせるのやら。 256 名前：login:Penguin [03/12/22 17:21 ID:C9mRSYV4] >>250 /.本家より MUTE: Simple, Private File Sharing slashdot.org/article.pl?sid=03/12/19/1750250 だそうだ 257 名前：login:Penguin mailto:sage [03/12/23 20:17 ID:UofXNrH/] 蟻が食べ物を見付ける方法からインスピレーションを得たってなんか凄いな・・・ 258 名前：login:Penguin mailto:sage [03/12/24 09:19 ID:p5RJmfHH] >>256 で、どうよ。使えそうか？ 俺の環境(RedHat9)では固まりまくるが。 259 名前：login:Penguin [04/01/08 12:45 ID:91Mu2rfW] Mute Ver.0.2 mute-net.sourceforge.net/ Known issues with version 0.2: Linux: --Strange system-wide freeze on LinuxPPC. Happens when receiving a series of connections (shows up in log). Freezes happen with both text and GUI. Must be triggering a kernel crash (bug in kernel). LinuxPPC kernel v2.2.15-2.9.0 --No crashes seen in Linux. 260 名前：login:Penguin [04/01/12 19:03 ID:H2XKicfm] age がんばれ 261 名前：login:Penguin mailto:sage [04/01/14 00:07 ID:Qid/c1ot] 俺もRedHat9ですが接続先を追加できないっぽいです 262 名前：login:Penguin mailto:sage [04/01/29 21:39 ID:gWkVseHH] ほしゅ 263 名前：login:Penguin [04/01/31 00:08 ID:PjoeMZsH] んでいつできるんだ？ 264 名前：login:Penguin mailto:sage [04/02/04 10:13 ID:3zoKxviV] MUTEを日本語使えるようにすりゃいいじゃん。 265 名前：login:Penguin [04/02/11 23:48 ID:2/PKzn50] 俺、linuxというかUnix版のWinny作ってるんだけど、 やっぱ公開すると、家宅捜索とかされちゃうのかな？ 266 名前：login:Penguin mailto:sage [04/02/12 02:55 ID:gusrgYRS] そもそも君の場合は、コードが手元にない狂言なので、大丈夫かと。 267 名前：Seisei_Yamaguchi mailto:sage [04/02/15 02:29 ID:NKg64qLe] 警察の中の人はソースが欲しかったから ジオシティー日本から辿ったんとちゃう ? 268 名前：login:Penguin [04/02/17 20:23 ID:l3npdv3O] Winnyパケットをブロックするソフトが出たみたいだね。 age 269 名前：login:Penguin [04/02/18 11:15 ID:9aTdwy7Y] >>268 これのことだろ。 itpro.nikkeibp.co.jp/free/ITPro/NEWS/20040217/139906/ モニタしてるキャプ画像があるんだが、暗号は完全に解読された模様。 もうwineでwinny動かしてる場合じゃないぞ、おまいら。 270 名前：login:Penguin mailto:sage [04/02/18 12:14 ID:gem58jl9] これって暗号が解読されてるのかな… あれだけだと、 winny network に偽の node として参加してるようにも見えるけど。 参加できれば、検索とかの query 読んで、その関連する packet 落とす…とかもできるだろうし。 271 名前：login:Penguin mailto:sage [04/02/18 13:47 ID:INzA8wD0] ふつーに、どこかの板に、不完全なソースコードが転がってます。 ソースコードの中には埋め込まれた暗号鍵も付いてます。 272 名前：login:Penguin mailto:sage [04/02/18 18:34 ID:ysm3TANi] Winny は相互接続する時に相手で本当に Winny が動作しているかどうかの確認 と、回線速度情報、クラスタワード を交換します。どうもその時の情報をデコー ドするのに成功したようですね。通信内容は無理っぽい。 Netagent で公開されてる資料の13ページ見ると手がかりがありますな。 273 名前：login:Penguin mailto:sage [04/02/19 21:44 ID:YUXcILLr] どっちにしてもKとACCSは完全なソースを持っている。 274 名前：login:Penguin [04/02/27 19:11 ID:OzDpoA/F] もまいら、winnyはいよいよ駄目だぞ。 www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html 暗号さえもっと強固なものだったら良かったのかね? 275 名前：login:Penguin mailto:sage [04/02/27 21:00 ID:WZTEm3ZQ] だから暗号と匿名性は無関係だとなんど言えば。 276 名前：login:Penguin mailto:sage [04/02/28 22:34 ID:S72mqHhA] >>275 >杉浦氏は、1個のパケットを見て、どこから来たものか解析することはある程度可能だと話す。 >「たどっていけば、1次配布先も分かるだろう」（杉浦氏）。 と言ってるからだと思われ。 ただ、 >「ソースコードを見たり、パケットを解析したりしながら、試行錯誤してデータを逆アセンブルしていった」（同氏） 最初は、ソースは入手していないメモリ解析と書かれていたと思うのだが この辺の供述が曖昧な辺りが、この記事で発言している人物の信憑性に疑問を持たせる。 277 名前：login:Penguin mailto:sage [04/02/28 23:51 ID:WXc+IhON] >>276 まぁ、本人はその筋では結構有名な人だから、技術者としてはどっかの ネットアークと較べればかなりまともな筈。 逆アセしたソースを見たと言ってたんじゃないかなぁ。データを逆アセ するってのもなんか表現が変。この記者の信頼性もいまいちなので... ttp://aki.nekoruri.jp/diary/200401c#D30_5 278 名前： ◆HO0OFh2RXI mailto:sage [04/02/29 06:48 ID:lTwPvcXw] 原案 Winnyのオープンソース化を考えるスレ winny.info/2ch/misc/1056020225.html pc.2ch.net/test/read.cgi/linux/1056020225/354- 354案にいろいろと混ぜてみたものです。 細かいチャンクにする、通信にはコストがかかるとする、というのが基本です。 自分のUp/Downしたいものは隣のノードが欲しがっている/持っているとみなして行動。 Winnyの転送の多い時期で転送リンクブチブチ状態のイメージ。 やればやるほどFreenet…効率がとても悪そうです。 とりあえず置いておくんで好きにしてください。 279 名前：login:Penguin mailto:sage [04/02/29 06:49 ID:lTwPvcXw] ☆ネットワークを流れる情報は、すべてにIDが振られた小さなチャンクに分割される。 　このIDは、内容により決められネットワーク上一意とする。 ☆チャンクは2種類あり、書き換え可能なチャンクと内容が保護されたチャンクである。 　書き換え可能なチャンクを回覧板、内容が保護されたチャンクを小包と呼称する。 　★回覧板チャンクのIDは、内容のテーマにより決められ、内容に関知しない。 　★小包チャンクの内容は公開鍵暗号を使用し、暗号化する。 　　そのIDは、暗号化済みの内容(鍵を含む)ともともとの内容の両方のハッシュに依存し、 　　それぞれ確かめ得るようにする。 ☆すべてのチャンクのやり取りにコストを設定する。 　正のコストのチャンクを受信すると、送信ノードに対し、送信債務が発生する。 　要するにUpしてもらえる権ということです。 　コストは、取引開始側が設定し、取引了承側が認証する。負のコストも許される。 　言い値で決まるが、不満であれば取引が成立しない。 　虚偽の取引を行った場合は直ちにリンクを切断し、以降の取引は行われない。 　すべてのノードは、送信債務という借金状態を解消しようとすることが要請される。 　つまり基本的にはDownすればUpすることが要請されます。 　あるノードが借り逃げを行った場合、または著しい債務超過に陥った場合、 　悪質ノードとして切断し、以降の接続を一定期間禁止する。 　大きい値のコストの取引は、取引実績ができるまで行われない。 ☆ファイルを流す際は、適当なサイズに分割しそれぞれを小包チャンクとする。 　それぞれの小包のIDとその鍵のリスト、及び元のファイルの識別情報（ファイル名、元ハッシュなど）を 　まとめて小包チャンクとし、フックチャンクとする。 　このフックチャンクはWinnyでいうところの仮想キーに相当するヘッダ部分である。 ★フックチャンクは、自ノードでは特別に処理が行われ、元ファイルの識別情報と対応がつけられている。 　外部に対しては、直接指定された場合は単なる小包チャンクとして振る舞う 280 名前：login:Penguin mailto:sage [04/02/29 06:49 ID:lTwPvcXw] ☆チャンク情報の拡散 　検索ワードを指定した回覧板チャンクをつくり、これを検索チャンクとする。 　検索チャンクには、指定ワードと関連するファイルの、元ファイル識別識別情報とフックチャンクIDのセットが 　リストになって入れてある。 　受け取ったノードは、リストをフックチャンクプールに格納し、自分の情報を混ぜた上で再び検索チャンクを形成し 　隣接ノードに転送する ☆チャンクの予約 　タグワードを指定した回覧板チャンクをつくり、これをオークションチャンクとする。 　オークションチャンクには、要求チャンクIDと取引成立時の予定コストとUp/Downのリストが入れてある。 　受け取ったノードは、リストを来たノードをマークした上でオークションチャンクプールに格納する。 　自らのダウン予約の都合を考えて、オークションチャンクを入れ替え、隣接ノードに転送する。 ☆チャンクの取引 　オークションチャンクの情報を元に、Up/Downの要求が一致すれば、送ってきた隣接ノードに取引要求する。 　要求内容は、対象チャンクID･Up/Downの別･成立時の支払いコストとする。 　要求を受け取ったノードは、以下の3つから行動を選ぶ 　　★要求を受諾し、チャンクを移動し、完了後コストが移動される。 　　★要求を拒絶する。 　　★要求は拒否するが、他のノードを紹介する。 　検索チャンク、オークションチャンクも同様に扱う。 281 名前：login:Penguin mailto:sage [04/02/29 06:50 ID:lTwPvcXw] ＜データ入手までの流れ＞ ファイル名 →フックチャンクプールから検索(なければ検索チャンクで底引き) →フックチャンクをオークションチャンクで予約→取引成立すればDown→展開 →内容チャンクを順次オークションチャンクで予約→取引成立チャンクからDown →すべて揃い次第元に戻す ＜オークションチャンクと取引コスト＞ ☆あるチャンクが欲しい時、大きいコストを設定してDown予約をかけると、 　成立の可能性が高くなる。 　所持ノードがUpしたときの利益が大きいので応じることが予想されるからである。 　しかし、あまり大きいと新参者小取引の原則により無視される。 　また、中間ノードが中継して(もっと小さいコストで元ノードから入手し)利益を得ようと 　するので効率が悪くなる。 ☆あるチャンクのDown予約が隣から流れてきた時、そのノードに対して債務がある場合、 　自ら率先してそのチャンクを入手することが望まれる。 　先に手に入れることができれば、そのノードに対しUpを行い借りを返すことができるからである。 ☆オークションチャンクの転送時に予定コストを書き換えることで、転送利益を得ることができる。 ☆あるチャンクが欲しい場合、Downで正のコストを設定する。 　誰かが欲しがっているチャンクをUpする場合、Upで正のコストを設定する。 　オークションチャンク、検索チャンクなどのどうしても受け取って欲しいチャンクを 　Upする場合、Upで負のコストを設定する。 ☆負のコストのUpを利用して、仮想アドレスタグをつけた小包チャンクを投げることで 　IMのようなノード間通信が可能かも。 　このとき、間のノードはコストの絶対値を少しずつ減じていくことで、利益を得ることが 　できるのでコストに対し十分近ければ届く。 ★所持チャンクのコスト評価値 　Upする時のコスト目標値。有用だと自らが判断するチャンクに対しては高くつけておく。 　需要が多ければ上げ、なければ下げる(でないとDownする人がいない)。 282 名前：login:Penguin mailto:sage [04/02/29 06:51 ID:lTwPvcXw] ＜検索およびオークションチャンクの転送経路＞ ☆タグまたは検索ワードと、クラスタ化キーワードとの優先度比較で大きいノードに転送されやすくする。 ☆送ってきたノードに直接返してはいけない。(取引の不正を防ぐため) ☆チャンク転送利益を得られないほどコストの絶対値の下がった、自分に不要なチャンクは破棄してよい。 ＜ノードの接続条件、切断条件＞ (考え中) ☆クラスタワード制により、意図的に移動できるようなネットワーク距離を導入し、 　近いノードに優先接続する ☆取引実績のあるノードは優先する ☆取引に嘘ついたノードは即切断、(覚えていられる限り)二度と許さない。(周りに伝達するかも) ☆取引がこちらの赤字の場合できるだけ切断しない ☆(主観基準の)大規模な借り逃げは、以降の接続を蹴る。(周りに伝達するかも) ☆ある程度の借りっぱは、次に接続した時に払ってもらう。動的IPの誤爆は気にしない。 ☆小規模な貸し借りは、水に流す。 ☆貸している側はいつでも切断できる。 283 名前：login:Penguin mailto:sage [04/02/29 06:51 ID:lTwPvcXw] ＜利点＞ ☆2者間の通信のみで、不正ノードを判定できる。 ☆部分キャッシュであるチャンクに価値をもたせられる。 ☆チャンクそれ自体は、単独で意味を持たない。 ☆チャンクの取引コストを、信頼度、優先度として準用できる。 ☆チャンクを所持していることは、内容を知って公開していることを意味しない。 　(中の人の判断基準は取引に有用であるかどうかのみ) ＜問題点＞ ★大きいファイルの時チャンクが揃わない可能性。 ★ネットワーク上の自分とその周りのノードが興味を持つチャンクすべてを把握する必要がある。 ★膨大な数のチャンクの取引の必要があり、ネットワークが飽和する危険がある。 ★検索がかけにくい。 ★同一ファイル複数キャッシュ問題。暗号化キーが異なるチャンクは互換でない。 284 名前：補足考察 mailto:sage [04/02/29 06:52 ID:lTwPvcXw] ★ネットワーク的に価値をもたないチャンクの排除 　フックチャンクの場合(ファイル名詐称など)は、無視リストを使用して所持しない、転送しない。 　優良フックチャンクを高く評価し(取引コストを上げる)、相対的に排除。 　平チャンクの場合、内容の評価は不可能。高値で取引できるのなら、中身については関知しない。 　ゴミチャンクは意図的にDownをかける香具師がいない限り、コスト値が高いまま取引されることはない。 　ローカルでチャンクの保持基準をコスト評価値と最終アクセス時を元に決めればそのうち消える。 ★高い評価のゴミチャンクの可能性 　自作自演によって可能。たとえ自分が騙されても、他に騙されるやつがいる限り 　被害はない。平チャンクがどこのファイルの所属なのかをたどる方法は存在しないので、 　アクセスがある限り消えることがない。 　消える可能性は、Winnyでいうところの完全キャッシュのみにする操作をノードが 　行うであろうこと。 　HDDに余裕があるのならどうぞ飼ってやってください。 ★優先度の詐称 　高値のチャンクをUpすることが一番効率のよい方法。 ★接続ノード限界 　Upするノードの不足がもたらす。落としたいファイルを持つノードの優先接続条件に 　適合するようにすれば回避できる。つまり熱心に奉仕汁 285 名前：login:Penguin mailto:sage [04/02/29 06:53 ID:lTwPvcXw] ★初期開放ノードの隠蔽、その必要性 　フックチャンクが出回らない限り、平チャンクのアクセスは困難。 　そのため、どうしても身元を隠蔽したいデータをUpする際は、自作自演をかけ 　周りにチャンク単独での価値を知らしめ、拡散した後、フックチャンクを公開する。 　自作自演にはコストがかかるので、どうしてもの時だけに。 　Down要求を蹴って他のノードに回して、かつ、その他ノードに対しUp要求をかけると 　隠蔽できるかも。 ★Port0(外部からの接続不可)の取り扱い 　未定 ★大量のファイルの保持者の負荷 　チャンクの要求があったとき、所持チャンクから検索しなければならない。 　ファイルをネットワークに投入する際、ハッシュ計算で時間がかかる。 ★IPをさらした上での匿名性 　隣接ノードがUp要求をかけた際に、所持チャンクが確定できる。 　ただし、これはファイルの所持に直結しない。 286 名前：login:Penguin mailto:sage [04/02/29 06:53 ID:lTwPvcXw] ★IPの変わる常時Up優良ノードの取り扱い 　あまり長時間同一ノードと取引することは推奨されない、ノードの評価の保持は 　一定期間であるということから、固定IPと比べ不利益はない ★繋ぎなおしでマイナス評価が消える 　ネットワークへの接続はかなり厳しいものとなっているので、取引に必要な 　評価を得ることへの手間がペナルティとなる ★途中の中継ノードによる、検索キーの捏造/改竄 　IDは内容のハッシュを元にするので、破損として処理する。 　破損チャンクは取引成立ではないのでリトライが強制される。 ★ファイル名の詐称 　フックチャンクの評価値により排除をする ★クラスタ位置を変えることによる評価の消滅 　クラスタにとって有用でないノードはいらないと考える。 　たとえ別クラスタで有用であったとしても、それはそれこれはこれ。 ★流通するキーの一覧を作成することによる危険 　目安になることは確かであるが、実際に完成するまで本当に存在するかは確定できない。 287 名前：login:Penguin mailto:sage [04/02/29 07:46 ID:KT/zUJUZ] おお！？ Linnyプロジェクト再起動か！？ 288 名前：login:Penguin mailto:sage [04/03/01 21:27 ID:rhb6VIeO] すでにバッテリーもへたってるから、腐った燃料では動きもしない･･･と。 289 名前：login:Penguin mailto:sage [04/03/02 00:45 ID:9lmYd62z] >>278-286　まで読んで見たものの、言葉だけではボンヤリとコンセプトだけで 具体的な手続きの順序とか、階層とかそういったものが共有できない… それぞれ得意な分野を分担して実装すれば、ソース公開の意味があって いいと思うんだけど、誰が何から実装するのかという、 最初の取っ掛かりがあればねえ。 俺も含めて他力本願なんだろうけど。 290 名前：login:Penguin mailto:sage [04/03/02 02:33 ID:9lmYd62z] 次期P2Pの仕様 part9 tmp2.2ch.net/test/read.cgi/download/1075400646/ 需要として参考になるのかな。 291 名前：login:Penguin mailto:sage [04/03/02 23:46 ID:j+7Rtc66] freenetのNGRが良い感じ。 292 名前：login:Penguin mailto:sage [04/03/09 02:54 ID:lz/xxrRp] >>290 ちょうど今、これ>>278-286と似たようなことが話題になってるな。 サーバを置くのが効率的には絶対にいいと思うんだけど、いろいろと問題ありそう。 eDonkeyが価値評価を導入してるらしい。参考になるかな 293 名前：login:Penguin mailto:sage [04/03/13 02:35 ID:it57ICZi] せっかく>>290のスレで課金可能性について論じられていたので278案での実現可能性について書いておきます。 ネットワーク内で使用している取引コストとして、現実世界のお金を使用することで課金できると思います。 ただしこの場合、信頼できる通貨サーバが必要ですが。 内容は暗号化し、ネットワークに流しておきます。 フックチャンクを2種類用意し、1つは集めることはできるが復号はできないもの(不完全フックチャンク)、 もう1つは復号できるもの(完全フックチャンク)とします。 不完全フックチャンクは通常と同じに流通させますが、完全フックチャンクは特殊な取引によってのみ流通させます。 内容が欲しいノードは、通常の手順で不完全フックチャンクを元に、パーツをそろえます。 次に、完全フックチャンクを持っているノードと、通貨サーバと通信できる状態にします。 チャンクの取引には、通常だと取引コストとしてDown権を渡すわけですが、完全フックチャンクの取引には 通貨サーバによる支払い証明を取引コストとして渡すことになります。 この取引において、完全フックチャンクを所持しているノードが正規の手続きなしに流してしまうと そのファイルに対する課金が崩壊してしまいます。 転送報奨としていくらか分け前を与えるとか、完全フックチャンクに所持ノードIDを書いておくとかしか 思いつかないんで、他にもっといい方法があるかも。 294 名前：login:Penguin mailto:sage [04/03/31 06:32 ID:HoAkMBXl] winny3を作ろうよ tmp2.2ch.net/test/read.cgi/download/1080239741/ 295 名前：login:Penguin mailto:sage [04/04/02 00:21 ID:WpkuJ3NS] とりあえず厨が入ってこれないようにしたい。 296 名前：login:Penguin mailto:sage [04/04/02 09:14 ID:WTKLrf8O] winnyの英語版が欲しいです。 私はあなたの支援を必要とします。 297 名前：login:Penguin mailto:sage [04/04/02 09:41 ID:j4zdC+mr] >>296 板違い 298 名前：login:Penguin mailto:sage [04/04/17 01:58 ID:JW5Fbu01] sage 299 名前：login:Penguin [04/04/30 03:21 ID:1Mr+A9gw] age of Linny 300 名前：login:Penguin mailto:sage [04/04/30 07:37 ID:F2pqcMu3] >>297 韓国人にそれは通じないだろう 301 名前：login:Penguin mailto:sage [04/04/30 07:42 ID:MoJY09XL] >>300 韓国ってのもいいかげん飽きたなぁ。 302 名前：login:Penguin mailto:sage [04/05/01 00:01 ID:rQWDA2uP] >>301 三国人で無問題 303 名前：login:Penguin [04/05/10 14:12 ID:gOkOLaIk] ４７氏の釈放を訴えるＯＦＦ off2.2ch.net/test/read.cgi/offmatrix/1084137851/ ４７氏の釈放を訴えるＯＦＦ off2.2ch.net/test/read.cgi/offmatrix/1084137851/ 304 名前：login:Penguin mailto:age [04/05/10 18:11 ID:zyDxrivK] 結局、535氏の途中断念が正しかったのか？ 作ったらﾀｲｰﾎだろ？ 305 名前：login:Penguin mailto:sage [04/05/10 19:28 ID:1n9r+xb3] 違法逮捕だとは思うが、nyには興味ないので無視。 306 名前：login:Penguin mailto:sage [04/05/10 19:31 ID:1n9r+xb3] EFFに通報すれば取り上げてくれるだろうけど、誰も英文メールが書けない。 307 名前：login:Penguin mailto:sage [04/05/10 19:33 ID:1n9r+xb3] 海外に情報が漏れないように英語の記事を載せないようメディア統制済。 308 名前：login:Penguin mailto:sage [04/05/10 19:34 ID:1n9r+xb3] でも本家/.にタレコまれててアウト。 309 名前：login:Penguin [04/05/11 02:44 ID:B6Rf6hGv] >>305-308 これ作ってる人が本家/.タレコミ者だな exe.adam.ne.jp/dice/index_j.html yro.slashdot.org/article.pl?sid=04/05/10/0157259&mode=thread&tid=123&tid=158&tid=99 310 名前：login:Penguin [04/05/11 12:48 ID:Al0YeF99] これが本当のオープンにしなかった理由だしょ。 headlines.yahoo.co.jp/hl?a=20040511-00000018-kyodo-soci 311 名前：login:Penguin mailto:sage [04/05/11 15:01 ID:Hq1OSHfm] というか、Winny-DOMを使っていないと考えるほうが不自然 312 名前：login:Penguin mailto:sage [04/05/12 03:19 ID:q0cG20qw] 別に数千から数万のノードがいる中で、百以下のノードが不正しても問題はない設計だろう。 不正ノードがいることではなく、多数を占めることを恐れてオープンにできなかった。 313 名前：login:Penguin mailto:sage [04/05/12 21:24 ID:dBKDTYWN] とりあえずさ、リリーススタイルを考えた方がいいと思う。 俺としては、tar.bz2にソースをまとめて海外の匿名串経由でuuencodeしたものを 2chに書き込む。これで完璧。 314 名前：login:Penguin mailto:sage [04/05/14 03:25 ID:b19TtUOi] 最初からFreenet上で開発宣言してリリースも全部そっちでやった方が良いよ。 315 名前：login:Penguin mailto:sage [04/05/14 17:50 ID:7U9iS7RX] 開発元を秘匿するのは、最初からやましいことやってるという表明にしかならん と思うのだが。 316 名前：login:Penguin mailto:sage [04/05/14 18:17 ID:uTjxhWEO] >>315 今回のような、万が一の為の回避策ですよ 317 名前：login:Penguin mailto:sage [04/05/14 19:09 ID:J6S3sDkg] 今回の件って、しかるべき結果なのでは？ ﾀﾞｳｿ板というグレーなものを扱う場所で動作確認をしているわけで。 318 名前：login:Penguin mailto:sage [04/05/14 19:55 ID:H+W+NZc7] 仕様用途を「LinuxのISO共有」にしとけばとりあえずOK 319 名前：login:Penguin mailto:sage [04/05/14 21:28 ID:uTjxhWEO] >>318 ISOファイルの共有は是非やりたいよね。 320 名前：318 mailto:sage [04/05/14 23:42 ID:ncaoYmUz] そういいつつFTPインストールをしていたりするｗ FedoraもFTP+GUIでインストールできるようになってたし。 321 名前：login:Penguin mailto:sage [04/05/15 11:22 ID:RVJL99XP] >>318 なら匿名性は必要ないから BitTorrent で十分。 322 名前：login:Penguin [04/05/17 20:36 ID:HO4EIYRj] ついにWinnyのソース公開！＠プログラマー pc5.2ch.net/test/read.cgi/prog/1071794941/l50 323 名前：login:Penguin mailto:sage [04/05/17 21:12 ID:+ZgvpoAo] >>321 その通りだが、 日本発のものが欲しい。 Winnyの使いごごちが捨てがたい。 署名性はおれも要らないと思う。 発信元がみえれば違法ファイルは流せなくなるからな。 324 名前：login:Penguin mailto:sage [04/05/17 21:12 ID:KQNT3jUC] 署名性? 325 名前：login:Penguin mailto:sage [04/05/17 21:20 ID:+ZgvpoAo] ゴメソ ->匿名性 326 名前：login:Penguin mailto:sage [04/05/18 14:19 ID:lZIh8sQE] 今さらだが作者がneko氏だった事にびっくり。 327 名前：login:Penguin mailto:sage [04/05/18 19:32 ID:5c9Ys/Tj] Linnyも535氏が本気だったなら結構楽しめるものに仕上がっていたと思うが。 328 名前：login:Penguin mailto:sage [04/05/22 17:22 ID:nqTAVPpu] linny.winny.info/ 329 名前：へりくつ星人 mailto:sage [04/06/27 16:41 ID:o/ZzpKCM] 表現の自由を守るため、 匿名性はぜひ必要です。 330 名前：login:Penguin mailto:sage [04/06/27 19:56 ID:TW8O336t] 匿名にすると荒れるからね… 331 名前：login:Penguin mailto:sage [04/07/01 17:19 ID:hhBC6xMz] 言論の自由が保障されている国に住みながら、表現の自由のためとは何事？ 違法行為をしたいだけじゃないのか。 332 名前：login:Penguin mailto:sage [04/07/01 19:30 ID:nV7KzNbc] >>331 個人情報保護法案を濫用されるようじゃだめぽ 333 名前：login:Penguin mailto:sage [04/07/02 00:22 ID:23tKNoDx] 破壊活動防止の名のもとに、いわゆる盗聴法案で通信の傍受が行われ、 米国のテロ対策のためにエシュロンによる一方的な傍受が行われています。 別に、身元の安全を保証されて訴えたい事は今の所無いわけですが、 だからといって因果関係の説明がハッキリしない幇助罪の濫用を認めると、 他の法案との兼ね合いから恐ろしいことになります。 通信の機密を高める研究がおざなりだった事が、太平洋戦争の作戦面での 敗因をいくつも作っているし、日米自動車会談での米側の通信傍受によって 経済的な敗北を招いた事もあり、国益の面から考えても重要な課題です。 逆に、犯罪者が使う事も考えられますが、まず個人をマークできていなければ 通信の内容をクリアにした所で防ぎきれないのは911が証明してしまいました。 殆どの犯罪捜査の面で、通信の強度が最大の問題になりえないでしょう。 計画的な犯行の内容を知りながら、止める事が出来ないのですから。 334 名前：login:Penguin [04/07/12 13:39 ID:oP37bQUb] この手のはどこいったんだ？ 335 名前：login:Penguin mailto:sage [04/07/13 01:13 ID:Wjb7ht7F] ここで相談しているだけで幇jy(ry 336 名前：login:Penguin mailto:sage [04/07/13 03:12 ID:UBZ1ootY] 凶吐腐刑様が見てる 337 名前：login:Penguin [04/07/20 09:21 ID:uwPwIKQc] >>333 アホくさ！警視庁、警察庁公安部が所謂、盗聴法に基づいて、 主なプロダイバのサーバー横ににメール盗聴用のＢＯＸを設置してますが、なにか？ あのなぁエシュロンどうだとかより、足元の公安部のほうがタチ悪いんだけどねｗ マルタイ対象者のメールは事実上、筒抜けというのがホントのとこ そういうこと理解してないだろ！！ｗ 338 名前：login:Penguin mailto:sage [04/07/20 12:06 ID:ZHO2cB4v] 俺のメールも盗聴してもらえるようになりたいものだ。 339 名前：login:Penguin mailto:sage [04/07/20 14:21 ID:NLHpUOa+] GnuPGはどうやって解読しているのやら。 340 名前：login:Penguin [04/07/20 16:40 ID:Ir/Sk1kn] 実際のところ暗号化してメールしてる香具師なんてごく少数。 一番DQNだと思うのはSSLで住所とか入力させて、 確認用にふつーのメールで入力した住所とか送ってくるサイト そういうサイトに限ってSSL対応だから絶対安心です、とか意味不明なことが書いてある。 341 名前：login:Penguin mailto:sage [04/07/22 04:23 ID:CHk2gMcm] i2pはどうよ？ 342 名前：login:Penguin mailto:sage [04/07/31 03:03 ID:74tIdb2R] >>337 先頭の段落だけに反応してもしょうがないが、タチが悪い良いの話ではなく ツツ抜けにしたところで分析を間違えれば防げないという話でせう。 「マルタイ対象者のメール」の絞込みから、内容の解読まで、エシュロンに 関わってる人間の多さ優秀さに比べればザルなんだろう…と、 長官狙撃事件の起訴見送りなんて大失態から伺えるなあってこったな。 ま、置いといて。 P2Pは悪くない，事業者が考えるべき策はまだある ttp://itpro.nikkeibp.co.jp/free/NCC/INTERVIEW/20040728/147832/ 興味深いのがYBBネットワークを設計した人ってところ。 343 名前：login:Penguin mailto:sage [04/08/05 22:23 ID:XEhm8+iR] P2Pとネットワーク技術の未来にあるもの ttp://blog.japan.cnet.com/kenn/archives/001457.html 344 名前：login:Penguin mailto:sage [04/08/06 09:58 ID:aRUsbpKu] キンタマで例のファイル見た。京都府警って素敵。w しかもファイルを回収しようとしてるらしいからもう最高。 345 名前：login:Penguin [04/08/10 10:50 ID:thjax6dy] Torで書き込みテスト 346 名前：345 [04/08/10 10:50 ID:thjax6dy] んで、もう一回書き込んでみると… 347 名前：345 [04/08/10 10:51 ID:thjax6dy] うまく使えてないっぽい… 348 名前：login:Penguin [04/08/10 11:13 ID:thjax6dy] テスツ 349 名前：login:Penguin mailto:sage [04/08/10 12:17 ID:DncnYLgd] >>345-348 しっかりやれ (^^; ていうか、/.jp への書きこみによると 2ch は対策を進めてるってことだけど、 それは関係ない? slashdot.jp/comments.pl?sid=201620&cid=602988 # オレは今のところ興味なくて、2ch の関連スレは読んでないけど。 350 名前：login:Penguin mailto:sage [04/08/10 21:11 ID:KaowJ+lx] ssh で使うときは socks 対応で(sshを)コンパイルし直さないと駄目なん？ > tor 351 名前：login:Penguin mailto:sage [04/08/15 02:55 ID:xoy5jEX1] 【信州大学】P2Pソフト MARIE【新進気鋭】 tmp4.2ch.net/test/read.cgi/download/1091445496/ 352 名前：login:Penguin mailto:sage [04/09/08 16:24 ID:q40OB9ny] 保守 353 名前：login:Penguin mailto:sage [04/09/19 16:25:54 ID:InKV6cb8] そういえば、昔このスレに47氏がカキコしてくれたなぁ。 ってことは、テレビに出たあの人もLinnyという言葉を知っているのか。 なんかすごいな。 354 名前：login:Penguin mailto:sage [04/10/19 13:05:06 ID:xgM0KVMN] >>351 某エロゲーメーカーのスクリプトエンジンと同じ名前だね。 355 名前：login:Penguin mailto:sage [04/10/19 19:15:22 ID:vSo4KyTx] Linnyはデーモンになるんですか？ 356 名前：login:Penguin mailto:sage [04/12/17 15:48:25 ID:QCBUlcCx] >>355 その前提で只今開発中です。 357 名前：login:Penguin [04/12/17 20:19:22 ID:Caiw6Ncr] >>356 通報しますた 358 名前：login:Penguin mailto:sage [05/02/19 09:27:04 ID:BJUsIJg+] よーし、パパsystem3.5って言うP2Pソフトつくっちゃうぞ〜 359 名前：login:Penguin [05/02/19 18:04:42 ID:crB44SZQ] 　国産、linux ｐ２ｐ ソフト！！ 期待します 360 名前：login:Penguin mailto:sage [05/03/04 10:20:03 ID:UoO0prm/] ファイル共有無くていいからLinnyBBS作って欲しいYO!! 361 名前：login:Penguin mailto:sage [05/03/05 03:15:03 ID:Jm1oAewG] 実質、ファイル共有部を利用してBBSのデータをやり取りしてるから 結局は両方実装しなければならない… 362 名前：login:Penguin [05/03/09 13:40:49 ID:PMkWko3y] あのー ずーっと待ってるんですけど。 363 名前：login:Penguin mailto:sage [05/03/09 16:37:12 ID:ufK0IMdA] >>362 だから何だ？ 364 名前：login:Penguin [05/03/09 16:44:39 ID:PMkWko3y] >>363 まだー？ ってこと。 まあ、おまえには関係ないと思うけど。 なんでしゃしゃり出てきたの？ 365 名前：login:Penguin mailto:sage [05/03/09 17:41:52 ID:JUJhub6J] バカ 366 名前：login:Penguin mailto:sage [05/03/09 22:26:36 ID:6CE5KbUl] 待ってるだけじゃねぇ。 367 名前：login:Penguin mailto:sage [05/03/10 03:47:15 ID:PPPryd0b] なんか伸びてると思ったら… BBS関連だけでも抜き出せないかとソースのようなものさんのを参考に見てみたけど 結局自分で書き直さないとぐちゃぐちゃだし、 共有関連も持ってこないとBBSデータのやり取りもできなさそうなので、めんどくなった。 これ解析するくらいなら、新しいの設計した方が速い気がしてやる気がでないし。 誰かやらないかな… 368 名前：login:Penguin mailto:sage [05/03/12 15:33:17 ID:AtiTv2c3] winnyのlinux版があれば全て解決。 369 名前：login:Penguin mailto:sage [05/03/14 05:37:26 ID:0YyTOLGz] >>368 47氏にでも依頼するのかい？ Linux版とかは作る気はない、とか言ってた気がするけど。 370 名前：login:Penguin mailto:sage [05/03/15 15:43:32 ID:fvSF73Mo] 厨房避けに最適なのに 371 名前：login:Penguin mailto:sage [2005/03/22(火) 20:38:19 ID:yam08RNP] wikiは見れなくなっているのだな 372 名前：login:Penguin mailto:sage [2005/04/10(日) 14:23:26 ID:Qg6Yp9sw] Winnyをソース化しよう tmp4.2ch.net/test/read.cgi/download/1071258282/ ここか。 373 名前：login:Penguin mailto:sage [2005/04/19(火) 20:18:53 ID:QwGOconk] >>369 オープンソースで成り立てばLinux版も可能といっていた。 374 名前：login:Penguin mailto:sage [2005/04/19(火) 20:28:15 ID:iza5jbtz] 要は暗号化と匿名化するのにソース非公開の方法しか 思い浮かばなかったんでしょ？ 暗号化はともかく、 匿名をオープンソースで実現することは可能なんだろうか。 375 名前：login:Penguin mailto:sage [2005/04/20(水) 00:08:19 ID:1AqW0Nsw] 暗号化も匿名化も出来る(っていうか暗号化は匿名化の手段でもある)が、 クラック避けが難しいって事じゃなかったかな>オープンソース化 376 名前：login:Penguin mailto:sage [2005/04/20(水) 00:42:36 ID:8LKPMmt8] ソース公開の匿名化はFreenetが(ry 377 名前：login:Penguin mailto:sage [2005/04/20(水) 10:38:18 ID:kXbvBhdm] ソース改変しても 相手の IP とか探ることはできないようになってるの？ 378 名前：login:Penguin mailto:sage [2005/04/20(水) 14:52:19 ID:eT3XmLKY] >>377 おまいさん、通信相手のIPアドレスがわからずにどうやってTCP/IPの通信をするつもりだい 重要なことは、誰が何を公開しようとしたかがわからないことであって、 誰が何のデータを持っているかは(プロクシ動作のために)意味を持たないと思う。 379 名前：login:Penguin mailto:sage [2005/04/23(土) 11:56:45 ID:wBX6QwFp] >>377 nyの一番重要なところは、プロクシ動作であり、流れるデータが常にキャッシュされるところ、 そのためキャッシュだけを見た時に、データが単にプロクシ動作のためにキャッシュされたものなのか、 直接的にアップしたものなのかわからない。 だから、相手が何を流してきたか？、何て事は全く意味を持たなくなる。 そのデータは相手が直接流したものなのか？単なるプロクシ動作によるキャッシュなのか？ それがわからないからだ。 もし、キャッシュに違法なデータが含まれていたとしても、法的に立件することは難しい。 なぜならば、キャッシュ動作を否定することは、ネット自体を否定することになるから。 ネット自体、データを途中にあるルータや鯖にキャッシュしながら通信が成り立っている。 そのキャッシュの中には法に触れるデータも含まれるであろう。 つまり、nyの動作はインターネットそのものであり、nyの動作を否定することは、 ネットそのものを否定することになる。 だから自分のPCのキャッシュに違法なデータが含まれていたとしても、 それだけで捕まえることは無理なのだ。 47氏はただ単に通信の手段を与えたにすぎず、nyの開発をしただけでの逮捕は違法といえる。 しかしなぜ逮捕できたか？それは47氏が著作権を崩壊させるのが目的であると、 nyの開発動機を語っていたから。つまり苦し紛れの理由で無理矢理 ﾀｲ━━━━||Φ|(|ﾟ|∀|ﾟ|)|Φ||━━━━ﾎ!! 相手のIPや通信経路が分かったところで、それが無意味だって事が わかったかい？>>377 380 名前：login:Penguin mailto:sage [2005/04/23(土) 14:09:15 ID:szBMljw1] >>379 あんた弁護士かい？ 47はキャッシュ動作(Upload)の違法性を認識しており、自分用にはDownload Onlyの クライアントを作成していたと言われているが、その件についてはどうかな？ 381 名前：login:Penguin mailto:sage [2005/04/23(土) 14:38:53 ID:mU74wke+] 犯罪に使われる可能性のある道具というのはいっぱいあるよね。包丁とか銃とか。 さらにほとんど犯罪にしか使われない道具もある。ピッキングツールとか。 犯罪にしか使われないソフトウェアというとクラッキングツールが そうだけど、そこら辺はどうなるんだろうね。 382 名前：login:Penguin mailto:sage [2005/04/23(土) 15:14:04 ID:wBX6QwFp] >>381 そう、結局はそこが曖昧なままなのが問題。 犯罪に使われる「可能性」のある道具を作るのが違法ならば インターネット自体が違法になりうるし、携帯電話だってなんだって当てはまってしまう。 最後には何も作ることが出来なくなる。 道具は使いようだからね。 >>380 つまりはキャッシュ動作の違法性も曖昧なままだ。 DLオンリーのクライアントがあったとしても、 47氏がキャッシュ動作が違法であると認識して作成したとは言えない。 それに、DLオンリーのクライアントを作成する理由は、他にいくらでもある。 本当にそんなクライアントがあったのかは知らないが・・ そもそも47氏がそんなもの使って一生懸命DLしてたと思えない。 やりたいことありすぎて時間もないだろうしな。 どっちにしても本人に直接聞かないことには推測の域は出ないので不毛。 つうか、別に違法性がどうのこうの言うつもりはなかったんだが・・・ ただ単に377があまりnyについて理解がなさ過ぎなのでレスしてみただけ。 383 名前：login:Penguin mailto:sage [2005/04/24(日) 03:33:43 ID:U52lbyvj] >>380 意図的に1次Upノードになることは公衆送信可能化権の侵害になることは明らかだが、 意図しない中継動作による2次以上のUpノードは明確には違法とはいえないのでは。 ただし、1次Upノードを、多数の中継Upノードの中に隠してしまうと、警察の捜査が 困難になることは認識していたと思われ。その意思が違法かどうかは微妙だが。 DownOnlyのノードがあったとしても、改造によるネットワークへの影響を調べていた という言い訳ができたりもする。 384 名前：login:Penguin mailto:sage [2005/04/26(火) 22:27:04 ID:b+Bgg3SS] っていうか中継動作が違法になるんなら、海外のエロページが見える国内のゲートウェイは全部違法だろ。 385 名前：login:Penguin mailto:sage [2005/05/06(金) 00:25:53 ID:fBpY2R2q] 中継動作をもって、それは合法ともいえないでしょ。しかも、中継動作なんて本質の部分ではないし。 「nyの否定」=[ネットの否定」ってのもぶっ飛びすぎでしょ。 47の目的は実験かもしれないけど、一般公開の実験にしては危険側によりすぎていると思うね。 386 名前：login:Penguin mailto:sage [2005/05/06(金) 10:42:22 ID:yIkyZYFZ] でも端から見てておもしろい実験だったよ。 387 名前：login:Penguin mailto:sage [2005/05/06(金) 20:51:18 ID:NC7j+KH8] >>385 つうかさ、それを言ったら、包丁作ったら逮捕。 みたいなのはどうなのよ。ぶっ飛んでませんか？ 388 名前：login:Penguin mailto:sage [2005/05/06(金) 22:15:02 ID:+qWs8XmI] Winnyでネギは切れそうもないので包丁は関係無いと思う。 389 名前：login:Penguin mailto:sage [2005/05/06(金) 23:09:51 ID:fBpY2R2q] >>388 激しく同意。 390 名前：login:Penguin mailto:sage [2005/05/07(土) 02:06:55 ID:VV46m7bs] >>388-389 お前ら・・・・ほんとに頭悪いんだな・・ 391 名前：login:Penguin mailto:sage [2005/05/07(土) 09:12:45 ID:N9jtnJjA] 包丁いっぱい作って無料で配りまくるのと似てるかも。 392 名前：login:Penguin mailto:sage [2005/05/07(土) 09:14:17 ID:wZZgaFg6] たとえ話は脱線しがちだからほどほどに。 393 名前：login:Penguin mailto:sage [2005/05/07(土) 10:07:08 ID:i/BfrLdB] サリンを誰にでも使えるようにして、俺は使ってないから無罪といいはるのと同様かと。 394 名前：login:Penguin mailto:sage [2005/05/07(土) 11:03:45 ID:T+EVrL8z] サリンって使い道あるの？ 包丁はちゃんとした使い道あるけど。 つまりnyもちゃんと使い方があって、それをちゃんと証明できるなら… 395 名前：login:Penguin mailto:sage [2005/05/07(土) 13:06:54 ID:tx50SVHK] 自作ポエ（ 396 名前：login:Penguin mailto:sage [2005/05/07(土) 16:32:40 ID:XnmIFUld] ブロードバンド時代に、プロバイダのバックボーンが耐えられるかの負荷テスト(ry 397 名前：login:Penguin mailto:sage [2005/05/07(土) 16:38:29 ID:hgkPuTxN] >>396 おまいは、厨房ともちゃでつか？ 398 名前：login:Penguin mailto:sage [2005/05/16(月) 22:51:09 ID:HnJ5Ynpd] ダウソ板で開発宣言したのがまずかったのかな。 399 名前：login:Penguin [2005/06/22(水) 20:48:18 ID:GGpxtaXf] 保守 400 名前：login:Penguin mailto:sage [2005/06/22(水) 22:57:54 ID:rSsOc9Il] 包丁でサリンを切るスレはここですか 401 名前：login:Penguin [2005/06/23(木) 14:56:46 ID:bF+VLH9U] Linny マンセー 早く作れ！ 402 名前：login:Penguin mailto:sage [2005/06/23(木) 18:40:29 ID:eVPle0x9] >>401 言いだしっぺ（ｒｙ 403 名前：login:Penguin mailto:sage [2005/06/28(火) 00:02:34 ID:/QQcXqnr] すごく出来が悪かろうと、公開さえしてくれれば 2ｃｈとしては反応がすごいのにな〜需要はあるだけに どなたか挑戦してみない？ 404 名前：login:Penguin mailto:sage [2005/06/28(火) 00:37:58 ID:sxypLrzh] >>403 開発したら何か得するの？ 405 名前：login:Penguin mailto:sage [2005/06/28(火) 01:12:49 ID:Woj5she8] >>404 いや、別に・・ 需要ってあるよね 406 名前：login:Penguin mailto:sage [2005/06/28(火) 01:35:17 ID:sxypLrzh] >>405 ちゃんと市場調査してくれよな。 407 名前：login:Penguin mailto:sage [2005/06/28(火) 01:39:16 ID:eyx1+LDG] やはりこういうソフトはプロジェクトじゃなくて、 社会的にアレなはみだしプログラマが、社会への恨みつらみを糧に 夜な夜なせっせと書き上げて、2chで無造作にバイナリのみ公開。 自分だけ吸い上げ専用バージョンを用意してｳﾏｰ、というのが収まりが良い。 408 名前：login:Penguin mailto:sage [2005/06/28(火) 01:40:30 ID:sxypLrzh] >>407 根拠きぼんぬ。 409 名前：login:Penguin mailto:sage [2005/06/28(火) 01:41:30 ID:n+gd5yH6] やっぱオープンソースだろ 410 名前：login:Penguin mailto:sage [2005/06/28(火) 16:33:52 ID:9XnSpYyO] >>407 アレな人は多いけど、技術と執念がないんだな 411 名前：login:Penguin mailto:sage [2005/06/28(火) 17:47:11 ID:sxypLrzh] >>410 ご自分のことでつか？ 412 名前：login:Penguin mailto:sage [2005/06/28(火) 20:43:23 ID:yfr2aRZu] オープンソースでも完全に成り立つ仕組みを考えればそれだけでも このスレの名は売れるだろう。 WinnyにしてもShareにしても暗号鍵をバイナリに埋め込むことで 保護している。ここの部分を何とかしないとオープンソースでは難しいだろう。 413 名前：login:Penguin mailto:sage [2005/06/28(火) 20:46:35 ID:n+gd5yH6] いっそ暗号化部分だけ切り離してしまって、バイナリだけの動的モジュールにしたら？ 414 名前：login:Penguin mailto:sage [2005/06/28(火) 20:51:09 ID:yfr2aRZu] それじゃあつまらなくない？ クラスタワードを鍵にするのも考えてみたけど、あんまりよくないね。 415 名前：login:Penguin mailto:sage [2005/06/28(火) 23:59:23 ID:n+gd5yH6] ちとつまらないかもしれませんね。 とりあえず俺はアホだが色々書籍を読み漁る予定。 416 名前：login:Penguin mailto:sage [2005/06/29(水) 03:11:34 ID:HU+dn+SH] >>413 隠すことによるセキュリティーは長続きしない。 根本的に、オープンでやっても維持できるシステムを構築すべき。 今までに出ているのは、ノードごとの相互監視をプロテクトにする案。 ちゃんとデータのやり取りをしているノード以外をネットワークから弾いてしまう、と。 末端同士のデータのやり取りの内容を隠す暗号化は、気分的なものと 中間ルータでキャプチャを簡単にはできなくするためだけであって、システムに 本質的に必要なものとは思わない。 Winnyのミソは、自分の保持データは、望んだものか中継なのかがわからず 機械的なプロクシとしての免責を企んでいる点。 417 名前：login:Penguin mailto:sage [2005/06/29(水) 03:22:47 ID:pkrk1XKs] ちゅーかx86がターゲットの時点でディスアセンブラで解析されるんだから。 418 名前：login:Penguin mailto:sage [2005/06/30(木) 21:18:29 ID:70M3Hd0P] Linnyのノードは完全に平等な権利をもたない。 419 名前：login:Penguin mailto:sage [2005/07/03(日) 15:06:07 ID:IZCijWVL] プログラマーとしてはダメダメだが、思いついたことを書いてみる。 ttp://www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html とかをまとめて見ると 要は、トラフィック解析した時に分かる「Winnyパケット」の「振る舞い」が、 問題になる。その「振る舞い」によって、らしきパケットは限定されてしまう １．無効なSYNパケットが多い ２．特定サイズの暗号化通信が連続する そして、限定されたパケットの中から詳細に分析しているのである。 1．の原因は恐らく、通信しようとした時にPCの電源が切られていることが多いから。 ２．の原因は恐らく「TCPの仕様」が原因である。と言うのも、大きなデータを 転送する際は、ネットワークを効率的に利用するためにMSSの最大レートで、 送られるパケットが大量に出るため、『不明なポート』から『不明なポート』へ 「不明なデータ」が大量に、「あるホスト」から「あるホストに」流れている事は すぐに分かる。現在の仕様では、どんなに頑張ってもトラフィックを観察されると ある程度,ファイルの流れはバレてしまう。(freenetでも同様) 420 名前：login:Penguin mailto:sage [2005/07/03(日) 15:07:28 ID:IZCijWVL] １．の解決方法 TCP接続前にUDPを使って、応答を待つ方法 TCP接続前にPingを使って、応答を待つ方法も考えられるが、 受信者が、Pingを切っている可能性もある。 しかし、特定のUDPパケットにICMP到達不能メッセージが多いと 結局イタチごっこになる。 そのため、ポート番号をUDP接続が成功するたびに、次回の接続を 変えてやる必要がある。 ２．の解決方法 UDPで新たな、ネットワーク層を偽装するトランスポート層を作成する。 つまり、「送信元IP」を偽装するのです。 できるようになれば、freenetより外部からの匿名性は高くなるが、 資源を思いっきり喰らう、ICMPメッセージは届かなくなる、 NAPTユーザは使えないなどの欠点がある。 考えられるアルゴリズムを、書いてみる。 421 名前：login:Penguin mailto:sage [2005/07/03(日) 15:08:56 ID:IZCijWVL] （１）各ホストには、IPと対応する「nodeID」を付ける。 （２）つける方法は何でもいいが、当然「nodeID」はユニークでないといけない。IPと無関係な十分に長い文字列(小学校のときの「将来の夢」作文に限定する)をハッシュにかけて、「nodeID」を生成するのが望ましい。 （３）TCP接続された制御用ポートで、ノードにnodeIDとIPを渡しあい、「ダミー送信元IP」を要求しあう(勿論、この通信はSSLで暗号化する) （４）要求されたノードは、接続されているホストのIPの中からランダムに選び、「ダミー送信元IP」を、要求したノードに渡す。 （５）「ダミー送信元IP」の寿命をどのように決めるかが問題。寿命が来れば、再び「ダミー送信元IP」を要求 （６）ノードでは、次のようなテーブルが作られる(イメージ) このテーブルによって、誰の通信が何処から来たかを見分ける -----nodeID-----|---realIP----|----dummyIP--|・・・・・・・(色々、必要なデータが続く) kad399ds&kldak3f|210.146.xx.xx|210.158.xx.xx|・・・・・・・ dsagju4ujfd85jd4|210.178.xx.xx|210.146.xx.xx|・・・・・・・ &'%UAGHUEGudsffh|210.101.xx.xx|210.178.xx.xx|・・・・・・・ '&BDSJhgww4'SEsd|210.158.xx.xx|210.101.xx.xx|・・・・・・・ ::::::::::::::::|:::::::::::::|:::::::::::::|・・・・・・・ ::::::::::::::::|:::::::::::::|:::::::::::::|・・・・・・・ 422 名前：login:Penguin mailto:sage [2005/07/03(日) 15:20:01 ID:IZCijWVL] （７）パケットのフォーマットは、TCP　over　UDP＋α的なもの -------------------------------------------------------------------- |Ver〜HeaderChecksum|///送信元IP(ダミー)////|///宛先IP(本物)///////| -------------------------------------------------------------------- |送信元ポート////|宛先ポート//////|/////Length/////|///Checksum////| -------------------------------------------------------------------- |/////////nodeID////////////////////////16オクテット///////////////|↓SSL暗号化範囲 -------------------------------------------------------------------- |///////////TCP////////////////////////40オクテット////////////////|ココのTCP通信のポートは固定にしておいても問題ない。4747版で固定なんてどうでしょうか？。 -------------------------------------------------------------------- |/////////DATA/////////////////////////////////////////////////////|↑SSL暗号化範囲 ----------------------------------- たとえ、SSLの暗号が破られても、外部の者はパケット単体から「nodeID」から本当の「送信元IP」を 割り出す事は出来ない。 （８）問題点は、所属するISPが自己ルーティングを規制している場合や、NAPTをしている場合。 423 名前：login:Penguin mailto:sage [2005/07/03(日) 15:46:30 ID:IZCijWVL] 上記の理由より、外部からの匿名性は高くなるが、 内部の「悪意あるノード」に対しては、対処出来ない。 むしろ、内部からの攻撃には非常に脆いと考えられる。 「認証」を、どのようにするか？コレが問題 424 名前：login:Penguin mailto:sage [2005/07/03(日) 18:51:41 ID:I4l1Sle2] 結局、プロバイダに対して偽装をするとなると、インターネットoverインターネットを 構築することになって激しく面倒。 どっちみち、むこうさんから見れば激しいUpトラフィックを打ち落とせばいいだけだし。 確か、ノードにIDを振り、自分以外の誰にもIPアドレスとの対応を明かさないで、 バケツリレーでたまたま自分のところにきたものを黙って受け取る、とかいうルーティングしてた P2Pソフトがあったと思われ。 muteだったはず。蟻がどうのこうののルーティング手法らしい。 425 名前：login:Penguin mailto:sage [2005/07/05(火) 23:27:28 ID:3m7vbi8S] 現在のWinnyを鍵と暗号化ファイルを別々に管理できる仕様、つまり、 暗号化ファイルだけダウンロード、鍵だけダウンロードできる仕様にする。 このとき、暗号化ファイルのファイル名などから、鍵を連想して、P2Pネット内から、検索、 鍵をダウンロード出来ないようにする。 『鍵』をハッシュにかけた値を暗号化ファイルのファイル名にするのが妥当だろうか? つまり、意味のある「キーワード検索」で引っかかるのは、鍵だけにする。 そして、鍵を落としたら、鍵をハッシュにかけて、再び検索クエリを流す。 理論的に、暗号化ファイルから、鍵を連想して、P2Pネット内から鍵を 落とす事は不可能になる。 鍵のキャッシュ保管用ディレクトリを、ハードディスクに物理的に1MBのパーミッションを 設定する。 ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・ 一瞬で終わるぞ・・・・(w そして、暗号化ファイルは論理的に「闇」に葬られる。 その後、暗号化ファイルは、まったく意味を成さないかと言うとそうでもない。 自分自身が、再び落としてくるファイルの中にキャッシュに含まれるファイルを 落とす可能性が高いからである。 鍵を落とすだけであれば、殆ど時間は要らないだろう。 コレだけで、匿名性は十分だと思うのだが・・・どうなのだろう? 426 名前：login:Penguin mailto:sage [2005/07/06(水) 01:23:30 ID:7XIcnn6N] そうか、P2Pネット上存在する鍵を全て落として、 虱潰しに調べれば可能なのか? 1000万の鍵があったとして、ダウンロードは、3日あれば出来るのかな? ハッシュに0.01秒、照合に0.001秒、かかると考えても、110000秒・・・・・30時間半 つまり、最悪４日程度あれば、キャッシュファイルの1つは、復号されてしまう。 50MBのファイルとして、復号には15秒程度かかるが・・・いくつか復号されるだけでも キャッシュファイルは、まる見え当然。 問題点は、ハッシュの計算は極めて速い点にあり、鍵から、暗号化ファイルの連想に 時間がかかれば問題なくなる。例えば、ハッシュを繰り返した10万回目の値とか・・・ 1000秒程度、連想時間があれば、最悪300年以上かかる・・・ 10倍の処理速度を持つ計算機でやっても30年・・・ 100倍の処理速度を持つ計算機でやっても40ヶ月・・・ 1000倍の処理速度を持つ計算機でやっても110日・・ しかし、これではユーザにも、足かせになるな。 ・・・なんせ、計算だけで16分もかかるから 427 名前：login:Penguin mailto:sage [2005/07/06(水) 03:31:05 ID:Vmpb7hhF] Winnyの例でいうと、(といってもその時代に参加してなかったが) 暗号化キーがかけられたファイルというのがあって、暗号化キーがわからない限り キャッシュが復号できない機能が存在してた。が、後になくなった。 消えた理由は、使われなくて不評だったから。 キャッシュですら消されてしまうのに、得体の知れない復号できないキャッシュを 残しておいてくれるお人よしな人はいなかったらしい。 簡単に復号できないキャッシュは、そういう運用をされることを考えた方がいいと思う。 なんかメリットがないか、ペナルティがないと持っててくれないと思う。 428 名前：login:Penguin mailto:sage [2005/07/06(水) 16:34:55 ID:pbi5Lyod] >>427 Winnyの暗号は、知っているもの同士が、集まって決めて、知らないものは 利用できなかったから、結果的に廃止になったのだと思う。 >>425の例では、クラスタワードに引っかかるのが、復号のための鍵の情報しか持っていない キーファイルだけにして、キーファイルからハッシュなどの方法で連想できる値を元に、 再び検索をかけているので、暗号化ファイルは誰からも閲覧可能である。 キーファイルから暗号化ファイルは連想できるが、暗号化ファイルからキーファイルが 連想できない原理は、「1632412」から「偶数」であることを「連想」できても、 「偶数」から、「1632412」が「連想」できないのと同じこと。 429 名前：login:Penguin mailto:pbi5Lyod [2005/07/06(水) 17:06:53 ID:665Lc0RY] >>426 ハッシュは、128bitあれば十分か？ 共通鍵は乱数で決めるとしても、衝突の危険性がない訳ではない。 キーファイルには、暗号化していないファイルのハッシュと共通鍵を 書いておき。暗号化ファイルのファイル名には、元ハッシュ値と共通鍵を 文字連結させて、決められた回数分だけ再びハッシュをかけたものを使う。 衝突の危険性は、低くなるだろう あと、1000秒ってのは長すぎるだろ？ どうにかして、10秒程度に抑える必要あり。 こうしては、どうだろうか？ 例えば、アプリ起動時にパスワード(英数字4文字で十分)を要求するようにする。 そのパスワードが書かれたファイルは、キーが保管されるパーミッションに保管される。 別に暗号化する必要はなく、昔のUNIXのpasswdファイルのように平分のままでもいい。 起動のパスワードを忘れたら、そのファイルを見ればいい。 アプリの隅っこに、「闇」ボタンがあり「闇」ボタンを押すと、 　　　　　　起動時パスワードをメモリに保存。 　　　　　　キーが保管されるパーミッションをフォーマット。 　　　　　　暗号化ファイルのファイル名を起動時パスワードで暗号化。 　　　　　　すべての設定をデフォルトにする。 430 名前：login:Penguin mailto:sage [2005/07/06(水) 17:10:19 ID:665Lc0RY] このときの暗号化強度は強いものである必要はないが、暗号化したかどうか 分からないようにすることが必要。つまり、ファイル名が16文字だった場合、 16文字のままでないといけない。誰かが、暗号化ファイルからデータを複合 しようとしても、ファイル名が暗号化されているかどうかは、本人しか知らない。 暗号化されていると分かって、シラミツブシにファイル名を復号して、ファイルを復号しようとしても、 　　　　　　500万のキーファイル 　　　　　　キーファイルから暗号化ファイルの連想に10秒かかる。 　　　　　　起動時パスワードは、数字だけ使っても10000通り。 辞書攻撃を受けても、3000〜2000年以上かかる計算になる。 ほとぼりが冷めた所で、暗号化ファイルのファイル名を復号すればいい。 起動時に毎回要求されているパスワードなので忘れることもないだろう。 起動時に要求するパスワードは、パスワードを覚えさせることを目的としているため 変えないほうがよいと考えられる。 さらに、中継ノードは暗号化ファイルはキャッシュするが、キーファイルはキャッシュしないとなどの 仕様をつけ足せば、無闇にキャッシュを消す事もなくなるだろう。自分のクラスタが特化されている場合、 暗号化ファイルの中に自分が欲しているファイルがある可能性がある。キーファイルは、1KB以下のファイル だが、暗号化ファイルは、それよりも遥かに大きい。よって、無闇にキャッシュを消すと、逆に欲しい ファイルを手に入れるのに時間がかかってしまう。 431 名前：login:Penguin mailto:sage [2005/07/07(木) 01:25:37 ID:Wgy7DjVN] キーファイルがある->キャッシュを消せる。 キーファイルがない->クラスタ化できない。 432 名前：login:Penguin mailto:sage [2005/07/07(木) 05:31:46 ID:4ekhGbja] >>428 キャッシュから直接に鍵が検索できない、っていう仕様であってる？ 中継ノードが復号できない仕様は、中継でたまったキャッシュを消される危険性が高いと思うんだが。 433 名前：425 mailto:sage [2005/07/07(木) 23:38:38 ID:SQnN0+8k] たぶん、>>426 >>428と同一人物です。 Linuxは使ってますが、プログラマじゃないです(SEでもないです だから、半ば「妄想」です。 ネットワークは、多少分かるので、オープンにしてもFreenet以上の匿名性が保て、 Winnyの70%ぐらいの使い心地のプロトコル「LINNY」を提案したいと思います。 間違えがあれば、どんどん指摘してください。 間違えがなくても、どんどん指摘してください。 錆び付いたこのスレを、皆で、暇つぶしに復活させましょう(w 434 名前：425 mailto:sage [2005/07/07(木) 23:39:34 ID:SQnN0+8k] >>431 基本的に、キーファイルのクラスタは、「自然言語」によってクラスタが特化されて行き、 暗号化ファイルのクラスタは、キーファイルから連想できる値（これを「連想鍵」と呼ぶ ことにする）によって、クラスタが特化されて行くので、まったく『独立』しています。 ですが、キーファイルを持っているノードは、高い確率で暗号化ファイルを持っているので 探索経路は、高い相関関係はあります。 つまり、キーファイルだけを見るとWinnyっぽいけど、暗号化ファイルの検索はFreenet的になる。 >>429-430 言ってることは、全体的に面白いし参考になります。 やはり、10秒ぐらいが妥当ですね。（「闇」ボタンは実装必須? しかし、キーファイルをキャッシュさせないってのは、意味が分かりません。 キーファイルを途中経路、暗号化するなりしてキャッシュさせない場合、 匿名性は向上するが、使い勝手は非情に悪い。 キーファイルの探索経路上に自分のノードがある場合、高い確率で暗号化ファイルの 探索経路上にもあるので、キーファイルをキャッシュさせた方が、無闇にキャッシュを 消される事もないと思います。 >>432 >中継でたまったキャッシュを消される危険性が高いと思うんだが。 その通りです。こればっかりは仕方がありません。70%ですから・・・ しかし、キャッシュされたキーファイルに対応する暗号化ファイルは、 高い確率で、キャッシュされているはずです。 435 名前：425 mailto:sage [2005/07/07(木) 23:41:59 ID:SQnN0+8k] 今後の課題 いちいち、キーファイル用のパーティションなんか用意しないで、FDとかの 別の外部記憶に保存した方が良さそうですね。 さらに言えば、暗号化ファイル以外、メモリースティックにアプリ自体を含め全ての データを保存した方がさらに良さそう(Linuxじゃメモリースティックは使えねーな 匿名性については、暗号化ファイルの受け渡しのみを見るとFreenetを超えていると思っています。 暗号化することで、ファイル自体に匿名性(何のファイルかわからない)があるからです。 上位ノードも、そのファイルが何かは、復号していない限りわからない。 下位ノードは、中継なのか、希望している「本人」なのか、上位ノードからは分からない。 しかし、普通にTCP使って、キーファイルの受け渡しを行った場合、匿名性はWinMX並になる。 ノード間の通信を暗号化しても、「外部」からの盗聴を阻止するだけで、内部の 「悪意あるノード」に対しては、簡単に盗聴を許してしまうからです。 そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が 提案しているような、ネットワークレベルで実現する方法を考えています。 問題点は、まだありそうな気もしますが、大枠は見えてきたので、また明日にでも書きます。 あと、「悪意あるノード」の定義や「外部からの攻撃」の定義もしていかないといけない 436 名前：login:Penguin mailto:sage [2005/07/08(金) 01:49:08 ID:kxCjllha] >425 ＞中継キャッシュを消される これを心配したのは、中継動作を理由にしらばっくれるつもりの仕様であれば、 ある程度の確率の中継キャッシュが残ることが必要だと思ったから。 今言われている仕様だと、中継ノードがキャッシュを持つ理由がなく (暗号化をキャッシュから直接復号できないので、直接メリットがユーザにみえない) キャッシュを持っているのが、放流主とリクエストした人だけという状況にならないかなと。 ＞内部の情報収集ノード対策 ある程度は諦めた方がいいと思う。 あるノードがファイルを要求するときに、あるクラスタ内で情報が閉鎖的になりすぎていると 検索ができないことになる。オープンソースでやるのなら、キー情報を溜めておいて ダウンを有利に進めようとする改良ノードが出てもおかしくない。 これらの正規の情報収集ノードと、悪意の情報収集ノードとが、システムからは 区別できないと思う。 437 名前：login:Penguin mailto:sage [2005/07/08(金) 23:32:43 ID:+d41giv6] 「鍵」から「ファイル」を「連想」するってあたりが、面白そうですね。 うまくいけば、本当に枠組み作れるかもしれませんよ。 >>436 >放流主とリクエストした人だけという状況にならないかなと。 勝手にレスさせてもらいますが、私はキャッシュされることは匿名性とは 無関係だと思います。 「中継」は、「誰」が「誰」に送っているか分からなくする為だけであり、 「キャッシュ」は、中継局の回線資源を有効に使うためだけに存在します。 最終的に、提供者と、もらった人だけがファイルを持ったとしても、 大事なのは、そのことが『誰にも分からない』ということです。 >>435 >キャッシュされたキーファイルに対応する暗号化ファイルは、 >高い確率で、キャッシュされているはずです。 ???? そんなはずはないと思いますよ。 私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で 「まったく違う」経路をたどると思います。 理由は、暗号化ファイルのクラスタは、連想鍵が似ている方向に探索クエリを 送信し、キーファイルのクラスタは、自然言語が似ている方向に探索クエリを 送信してするからです。 438 名前：login:Penguin mailto:sage [2005/07/08(金) 23:34:26 ID:+d41giv6] たとえば、Aのノードがキーファイルを自然言語で検索する時、 /**********************************************************************************/ 自然言語は、Bのノードに対して近い位置にあるとすると、キーファイルの検索は、Bのノードに委譲される。 そこで検索され、最終的にXで発見され、XからBのノードを経由して、Aが落とします。 Aは、キーファイルから連想鍵を生成して、暗号化ファイルを検索すると、連想鍵はCのノードに対して近い位置にある という場合が考えられる。いや、確率的に考えれば、むしろ、そのほうが高いはずです。 最終的にXで発見されたとしても、暗号化ファイルは、XからCのノードを経由して、Aに落とされます。 このとき、Bにはキーファイルがキャッシュされ、Cには暗号化ファイルがキャッシュされる。 /***********************************************************************************/ それぞれのノードが知っている情報をまとめると以下の通りになる。 　１）Cは、暗号化ファイルがXから来たこともAに送った事も知っています。しかし、中継かどうかは分かりません。暗号化ファイルの内容も意味も分かりません。 　２）Cは、Aがどのようにして、キーファイルを手に入れたのかも分かりません。 　３）Bは、キーファイルがXから来たこともAに送った事も知っています。しかし、中継かどうかは分かりません。Aにキーファイルを渡したあと、Aが暗号化ファイルを検索したのかどうか分かりません。 　４）『X』が、キーファイルと暗号化ファイルの『両方の検索クエリを中継している、または、両方を持っていることを知っている者』は、誰もいません。 439 名前：login:Penguin mailto:sage [2005/07/08(金) 23:36:27 ID:+d41giv6] つまり、暗号化ファイルの探索経路からキーファイルの探索経路が予測でいないので、 ファイル提供者『X』の匿名性は、Freenetぐらい高いと思います。 しかし、中継局は意味の分からないファイルをキャッシュさせられるので、使い勝手は、 Freenetに毛が生えた程度です。 特に、暗号化ファイルは中継局からすれば、わけの分からない「ごみ」です。 でも、分からないだけで、自分が落としたいファイルも暗号化ファイルのキャッシュの中にあるかも知れません。 キーファイルを落としてきて、暗号化ファイル検索したら自分の中にあったら、なんとなく得した気分にになり、 暗号化ファイルが「宝の山」に見えるような心掛けよう。 でも、そりゃ無理ですね。 >>436の言う通り、直接的なメリットは何もないので、「中継局に為らないやつは吊るし上げろ！」 (最終的に、親になってくれるノードがいなくなり孤立する)ってカンジのシステムを作るれば、 中継することを義務付けれます。そうすると、キャッシュを消してしまうと、同じ検索クエリが来たとき、 再度、回線資源を食われてしまいます。つまり、ディスク資源か、回線資源のどちらかを提供しないといけません。 ふつう、回線資源のほうが貴重(ダウンロードが遅くなるのはイヤ)だから、結果的にキャッシュを消すことも少なくなるでしょう。 >>430は、そういうことを言いたかったのではないでしょうか？ >そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が >提案しているような、ネットワークレベルで実現する方法を考えています。 ソフトイーサを利用したIP偽装とか聞いたことはありますが、管理が面倒だし、 逆にセキュリティホールになってしまいそうな気味します。 第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは? 440 名前：login:Penguin mailto:sage [2005/07/09(土) 00:05:42 ID:wPON5jd/] あかん・・・パラドックスや・・・ オープンソースでセキュアなP2Pなんてやっぱ無理やで 441 名前：login:Penguin mailto:sage [2005/07/09(土) 06:46:08 ID:c1VczgQE] >>440 どのあたりが矛盾しているかを書くのがいいと思われ。 人はいるみたいだし、何か知恵が出るかも。 442 名前：425 mailto:sage [2005/07/09(土) 08:28:10 ID:yQGfiko3] >>437 >私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で >「まったく違う」経路をたどると思います。 仰る通りです。私が勘違いしていました。 クラスタの独立は、匿名性の向上には繋がりますが、中継ホストに残った 暗号化ファイルは、ホストにとってはタダのゴミ。 中継を嫌がるホストが増えるので、システム全体として中継を拒むホストを 孤立させていくような仕組みが必要になりますね。 >第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは? 一応、内部からも分かりにくい方法を考えてみたのですが、逆に攻撃の対象にされてしまうかも知れませんし、 ネットワークに負荷がかかるので止めます。 ネットワーク偽造は、また問題があったときに考え直します。 しかも、上記のような、クラスタの独立による途中経路不一致から、 十分に、匿名性はありそうですし。 443 名前：425 mailto:sage [2005/07/09(土) 08:47:29 ID:Aqub9gDD] >>440 最終的に、内部ノードが通信相手のIPをかき集めれば、ネットワークに参加しているものが 見えてしまっても(これはしょうがないので諦めます)、「誰」が「何処」へ「何」を送って いるのか分からなくしてしまえば、まったく問題ありません。 >>238が説明してくれているように、ファイル提供者『X』の匿名性は十分守られています。 現実世界で目を付けられるような行動をしてない限り、この匿名性が破られる事はありません。 目星を付けられていても、ファイル提供者『X』は、ローカルにあるキーファイルを消しまえば 良いだけだと思うのだが、どうだろう?(w 落とすだけの輩も、中継ホストになって貰えば、システム上十分な役目を果たしてくれる。キャッシュされなくても、そのホストさえ通ってくれれば、 良い訳ですし、キャッシュしなかった場合、回線資源が喰われて、ダウンロードが遅くなります。 他に、情報が漏れてしまうような箇所はあるでしょうか？ 444 名前：425 mailto:sage [2005/07/09(土) 08:48:16 ID:Aqub9gDD] あとは、「クラッカー」対策 このシステム最大の弱点は、情報が書き換えられたキーファイルや、悪意あるノードが 初めから暗号化ファイルをが存在しないキーファイルを大量にネットワーク内に生成し、 大量に出回ると、対応する暗号化ファイルに辿り着けないキーファイルが出て来て、 結果ネットワークが機能しないと言う恐ろしい自体が起こります。 逆に、暗号化ファイルを書き換えられたりしても、キーファイルからは辿り着けない。 この問題を解決するには、2042bit公開鍵を使った署名システムが1番確実で安直でしょう。 キーファイルには、電子署名と公開鍵が付属し、途中で書き換えが起これば、 即座に分かります。 電子署名と公開鍵が双方とも書き換えられている場合は、連想した暗号化ファイルに問題、 または、ファイルが見つからないと言う事が続くようであれば、 その公開鍵が付属する、キーファイルを一切信用しないで捨てる。 このように、公開鍵を一種のIDとしても扱えます。 これは、公開鍵の設計に時間がかかる性質を利用したシステムです。 ファイルアップ用の公開鍵は、インストール時に作成し､その後、変える必要もありません。 445 名前：login:Penguin mailto:sage [2005/07/09(土) 11:50:32 ID:3O2EbHgy] ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。 この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。 かといって、毎回違う鍵を使えば、署名の意味が全くない。 446 名前：425 mailto:sage [2005/07/09(土) 22:44:19 ID:7r68v9eE] >>444の続きです 急用が出来たので、書いている途中で飛び出してしまいました。 公開鍵の暗号方式は、RSAです。 2042bitなのは、暗号の強度を上げるためではなく、公開鍵の設計を難しくするためです。 クラッカーが、大量に粗悪なキーファイル(暗号化ファイルを持たないキーファイル)を アップしたとしても公開鍵が同じであれば、全て無視できます。 よって、クラッカーは大量に公開鍵を設計する必要があります。 2042bitの鍵を生成するには、恐らく、最低十数秒はかかるので、 クラッカーに大きな負担となります。 一方、ユーザのは悪質な公開鍵を信用しなければいいし、逆に、常に 暗号化ファイルが存在する良い公開鍵を信用すればいいわけです。 ここで、ポイントとなるのは良い公開鍵になるためには、その公開鍵の秘密鍵を知らなければ不可能である事です。 これによって、良い公開鍵の成り済ましを防げます。 この公開鍵は、変えるのも自由ですが出来るだけ変えないほうが良いでしょう。 447 名前：425 mailto:sage [2005/07/09(土) 22:54:49 ID:7r68v9eE] さらに、キーファイルに信用性の無い公開鍵が載っていたとしても、そのキーファイル自体は良質(暗号化ファイル)が あれば、そのキーファイルを、別の人間が電子署名と公開鍵を上書き(公開鍵と電子署名を消して書き直)します。 ただし、その別の人間の公開鍵は分かっても、その人間が誰かは、本人しか知りえません。 その公開鍵が、信用性が高い公開鍵であれば信用できます。この動作を「信用性公開鍵の上書き認証」と呼ぶ事にします。 この「認証」は誰でも出来るようにします。と言うより、理論的に誰でも出来てしまいます。 ここで重要になってくるのは、「キーファイルに載っている公開鍵 = ファイル提供者の公開鍵」の公式が 必ずしも、一致しないと言う点です。逆にいえば、ファイル提供者の公開鍵である必要性はないと言うことです。 つまり、公開鍵は「このキーファイルの内容は私(誰か分からないが公開鍵は分かる)が保障する」程度の意味しかありません。 次に問題になってくる攻撃は、信用のある公開鍵が既に上書き認証しているキーファイルを、さらに悪質な公開鍵が認証を 上書きすると言うものです。 そこで、公開鍵を検索ワードに入れることを許す仕様にします。つまり、 「ある公開鍵」と「検索ワード」を含む検索を可能にすると言うコトです。 (念のため、言っておきますが、ここで言う「信用」は、基本的に、そのノードの「経験」によるものです。 つまり、ノードは公開鍵に関する経験をデータベース化しておく必要があります) 運用しだすと、認証を専門に行う「認証屋」が出てくると思います。 つまり、これの狙いは「認証局の分散処理」です。 448 名前：425 mailto:sage [2005/07/09(土) 22:59:22 ID:7r68v9eE] >>445 > ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。 > この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。 「ファイルアップ用」の公開鍵と別に、「ノード間経路暗号用」の公開鍵も実装させ、 これにより、外部からの参照を不可能になり、出来るのは内部ノードの情報収集のみになります。 内部のノードが可能な情報収集手段は極々限られている上、上位ノードから流れてきたキーファイルが、 中継なのかどうなのかも分かりません、トラフィックを分析した所で、キーファイルは小さすぎて、 別のトラフィックで埋もれてしまいます。 現実世界で、ボロを出さない限りまったく問題はありません。 「ノード間経路暗号用」の公開鍵は、ECC40bitあたりでどうかなと思っています。 これも、インストールした時点で決めます。(変えるのは、完全に自由です) 449 名前：425 mailto:sage [2005/07/10(日) 16:44:13 ID:m7iyk48S] クラッカー対策に、いろいろ考えていると、かなり大掛りなものになってしまった。 とりあえず、暫定的に考えている事を、全てまとめてみる。 ノード間通信 　検索、キーファイルの受け渡し　⇒　暗号化（SSLモドキ） 　暗号化ファイルの受け渡し　　　⇒　暗号化なし(元々してある)　　　 基本構成 　「元ファイル」から、「キーファイル」 と 「暗号化ファイル」を生成し、 　この2つを、「共有」する。 　「キーファイル」は、データを元に「連想鍵」を生成し、 　「連想鍵」を元に、「暗号化ファイル」を検索する。 　 終端ノードで「連想鍵」から「暗号化ファイル」が発見されると、そのノードは、 　「暗号化ファイル」から「暗号化チェックサム・キー」を返す。 　「暗号化チェックサム・キー」のキャッシュは起こりません。 　 (キャッシュした所で、共有できない無意味なデータになる) 　「暗号化チェックサム・キー」から、「絶対連想鍵」を生成し、 　「絶対連想鍵」を元に、再び「暗号化ファイル」を検索する。 　つまり、 　「キーファイル」(自然言語)のクラスタ 　「連想鍵」(暗号化ファイル)のクラスタ 　「絶対連想鍵」(信用性情報)のクラスタ 　の３つのクラスタが形成され、やや煩雑なものになる。 450 名前：425 mailto:sage [2005/07/10(日) 16:46:00 ID:m7iyk48S] キーファイルが持っている情報 　1-1）自然言語のクラスタキーワード 　1-2）鍵（暗号化ファイルの共通鍵） 　1-3）暗号化チェックサム 　1-4）1-1),1-2),1-3)の電子署名 　1-5）4)に対する公開鍵(RSA 2048bit)　　　　　　　 暗号化ファイルが持っている情報 　　　　 　2-1）連想鍵(MD5) 　2-2）絶対連想鍵(MD5) 　2-3）暗号化チェックサム・キー 　2-3）データフィールド(元ファイルの暗号化データ) 451 名前：425 mailto:sage [2005/07/10(日) 16:50:15 ID:m7iyk48S] 連想鍵 　暫定的には、1-2),1-3)を文字連結させ、それを数千回(何回にするかは検討中) ハッシュにかけた値。ここで使うハッシュは衝突対策で、MD5を想定している。 　冗長性などの問題から、計算方法は変わる可能性あり。 絶対連想鍵 　絶対連想鍵は、ノードにキャッシュされる度、毎回計算され上書きされる。2-3)をMD4で 　ハッシュにかけた値を、連想鍵と文字連結させ、さらにMD5でハッシュにかけた値。 　『最終的』に、この値によってダウンロードするファイルを決定する。 452 名前：425 mailto:sage [2005/07/10(日) 16:51:40 ID:m7iyk48S] 暗号化チェックサム・キー 　3-1）連想鍵 　3-2) 暗号化チェックサムの共通鍵 　3-3）3-1),3-2)の電子署名 　3-4）3-2)に対する公開鍵(RSA 2048bit) 以上4つのフィールドを、1-2)で「暗号化」したもの。 　つまり、正しい「キーファイル」がないと、「暗号化チェックサム・キー」は復号できない。 　そして、「暗号化ファイル」単体では、意味を成さないフィールド。 暗号化チェックサム 　4-1）2-3)データフィールドのハッシュ値(MD4)　 を、3-2)で「暗号化」したもの。 　つまり、正しい3-1)が無ければ、「暗号化チェックサム」は復号できない。 　そして、「キーファイル」単体では、意味を成さないフィールド。 様々な、情報があるが、これらを美味く使えば、悪質なノードを排除したり、 壊れた暗号化ファイルを、出回らなくするように出来るでしょう。 例外処理は、今日はしんどいので、また今度書きます。 453 名前：425 mailto:sage [2005/07/10(日) 17:00:37 ID:m7iyk48S] 訂正 　2-1）連想鍵(MD5) 　2-2）絶対連想鍵(MD5) 　2-3）暗号化チェックサム・キー 　2-4）データフィールド(元ファイルの暗号化データ) //////////////////////////////////////////////// 絶対連想鍵は、ノードにキャッシュされる度、毎回計算され上書きされる。2-4)をMD4で 　ハッシュにかけた値を、連想鍵と文字連結させ、さらにMD5でハッシュにかけた値。 ////////////////////////////////////////////////////////// 4-1）2-4)データフィールドのハッシュ値(MD4)　 を、3-2)で「暗号化」したもの。 ////////////////////////////////////////////////////////// 　つまり、正しい3-2)が無ければ、「暗号化チェックサム」は復号できない 説明で、横着するとろくなコトがない・・・ 454 名前：login:Penguin mailto:sage [2005/07/10(日) 17:39:23 ID:m7iyk48S] >425 ソンナメンドクサソウナモンダレガツカウ？ って言いたい所だが、オープンソースってのに既に問題があるんじゃないの？ プロトコル名に「LINNY」ってのも、どうなんだ？ オープン仕様、オープンソースならば、Windowsでもいいわけだが・・・ プロトコル名は、「Anonymous Winny」をもじって、「ANONY」に一票。 455 名前：login:Penguin mailto:sage [2005/07/10(日) 18:24:15 ID:hZ/9wEx5] 「ONANY」 456 名前：login:Penguin mailto:sage [2005/07/10(日) 23:06:13 ID:pnHySe/b] まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。 457 名前：login:Penguin mailto:sage [2005/07/10(日) 23:14:38 ID:kOFHOXTv] 鍵の長さって、現時点で論じるべきことなのかと思うがね。 458 名前：login:Penguin mailto:sage [2005/07/10(日) 23:22:09 ID:SZNYDAl1] 最初は無暗号で徐々に暗号化を実装とかは？ 459 名前：login:Penguin mailto:sage [2005/07/10(日) 23:23:12 ID:rhhJYpWd] で、コード書くやつはいるのか 460 名前：login:Penguin mailto:sage [2005/07/10(日) 23:31:36 ID:kOFHOXTv] リスクを背負う事無く安全に流通させる経路さえあれば誰か書くんじゃない？ 461 名前：425 mailto:sage [2005/07/11(月) 01:33:11 ID:MZK+5YtJ] >>456 >まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。 やっぱり、そう思います？ やはり、「匿名性」と「セキュリティ」と言う相反するものを同居させるには かなりムリがでてきますね。 この世界、あまりにOSIモデルのように、厳密で繁雑なシステムは 嫌われるので、もう少し簡略化したプロトコルが必要。 簡略化をする方法の1つは、連想鍵と言う概念を無くす方法です。 つまり、 キーファイルに暗号化ファイルのハッシュ値を直接貼り付けておき、 そのハッシュ値を元に、暗号化ファイルを探す方法 詳細は抜きにして、メリット・デメリットについて。 メリット 　 　検索は高速。仕組みは簡単なので、暗号化ファイルの改ざん対策が容易 デメリット 　「暗号化ファイル」から「キーファイル」が、解かってしまう。 つまり、キーファイルがなくても、ハードディスクを没収されると、P2Pネット内から キーファイルを落として、復号されてしまう危険性がある 「キーファイル」検索条件に制限をかけるなどの対策を取れば、ある程度OK? プロトコル名は、>>454にあやかって「Simple ANonymous winNY」を もじって「SANNY」なんてのを考えてみる。 462 名前：login:Penguin mailto:sage [2005/07/11(月) 16:32:40 ID:/TB8jfv9] 階層がわかりにくい…だれか図示してくれ… 何に対しての匿名性を確保して、何に対しての改変耐性を確保する予定なのかを 示してもらえると、もう少しわかりやすくなるかも。 連想鍵で１階層噛ましているの理由がよくわからん。 正規の検索かければ誰でも復号できるんでしょ？ 攻撃側に対する耐性になってないと思う。 463 名前：425 mailto:sage [2005/07/11(月) 22:29:31 ID:iaGb8hb0] >>462 >何に対しての匿名性を確保して 「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、 「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。 「暗号化ファイル」単体では、何のファイルで何がかかれているか、 まったく不明にするコトで、完全な匿名性を実現しようとしたもの。 要は､国が本気で動いても、よく言われる「匿名の度合い」での、 「疑いの域を出ない」(Level 5)を実現しようとしたもの。 勿論、「言論の自由」のために(w >何に対しての改変耐性を確保する予定なのか 運用しだすと、よくありそうなのは、「暗号化ファイル」を落としてみると どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延 キーファイルだけ作りまくる輩・・・など 464 名前：425 mailto:sage [2005/07/11(月) 22:33:50 ID:iaGb8hb0] >連想鍵で１階層噛ましているの理由がよくわからん。 何故こんなに煩雑なものになったのかと言うと、 キーファイル　 ⇒　暗号化ファイル　は、分かっても、 暗号化ファイル ⇒　キーファイル　 は、絶対に分からなくする。 つまり、「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってはいけない。 という、前提条件があるからです。 具体的に言うと、壊れていたり、改ざんされている暗号化ファイルを ネットワーク内で、蔓延させないためには、 暗号化ファイルを キャッシュしたノードは、毎回、暗号化ファイルのハッシュを 行い、その値を公開する。 そして、検索者はそのハッシュ値を元に暗号化ファイルを検索し、 落とすと、壊れたり、改ざんされている暗号化ファイルは、 それ以上、蔓延することは無く消えていく。 これは、Freenetで実装されている技術です(ただし、暗号化はされていない)。 じゃあ、キーファイルに、「暗号化ファイルのハッシュ」を 直接貼り付けると、どう言う事が起こるでしょうか? 暗号化ファイルのハッシュ値は、暗号化ファイルから直ぐに分かってしまい、結果、 「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってしまっている。 で、こんなのになったワケ。 よく見ていただくと分かると思うが、「キーファイル」と「暗号化ファイル」は「同じデータ」を 一つも持っていません。(持っていますが、暗号化されていて分かりません) ま、はっきり言って、私も､まともに動くとは思えない。（システム全体が重過ぎる もう少し、使い勝手のいい、安易なものの方がいい。 465 名前：login:Penguin mailto:sage [2005/07/11(月) 22:53:31 ID:/qz9fPP7] ttp://s2net.s41.xrea.com/ アイデアだけはいっぱい出ているし、国内外問わず研究論文もたくさんある。 問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと いうこともあるし いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない だったら誰も使わないだろう 466 名前：login:Penguin mailto:sage [2005/07/11(月) 23:20:09 ID:wBE6vaKT] > いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない > だったら誰も使わないだろう そこはオープンソースなんだから、UI は誰かが作ってくれるだろう。 通信部分は Winny の時に散々ループしてた dll なり so なりにすればいいじゃん。 467 名前：425 mailto:sage [2005/07/12(火) 02:03:25 ID:cTi5k0J7] >>465 >問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと 確かにいえる。ノードは、全て信用できるものであれば、簡単でしょうけど 規模が大きくなれば、なるほど信用性は薄くなる。 Winnyでも、ウイルス流れたしね。 468 名前：login:Penguin mailto:sage [2005/07/12(火) 11:11:49 ID:nQBkc+7e] > Winnyでも、ウイルス流れたしね。 どんなウィルス？ 469 名前：login:Penguin mailto:sage [2005/07/12(火) 13:43:43 ID:nQBkc+7e] ん？ > ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・ なんだこれ。 470 名前：login:Penguin mailto:sage [2005/07/12(火) 14:16:23 ID:5JN9Gt1s] >>463 ＞「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、 ＞「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。 「意図してダウンロードを開始した、末端ノード」に対しては、 「あるファイル(の暗号化されたもの)」であることはわかるのでは。 「意図して最初にシステムに投入した、末端ノード」に対しても 同様ではないか。 その情報がどこまで伝播してしまうか、で。 隣から見た場合、意図してダウンロードを始めたか否かで 「知っているかどうか」を知ることができるのは危険かなと。 ＞どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延 「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは 実際にファイルを展開できたノードにしか判定できない。 その情報を伝播させて大丈夫かな。 それとは別に、システムで検知できる改変(チェックサムが違うとか)は これだと弾けそうだけど。 471 名前：425 mailto:sage [2005/07/13(水) 00:34:25 ID:dIg+n2Qr] >「意図してダウンロードを開始した、末端ノード」に対しては、 >〜中略〜「知っているかどうか」を知ることができるのは危険かなと。 言っている意味が、分かりにくいので、良ければ、具体例を上げて その危険性を、教えて欲しえてくれませんか?。 >「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは >実際にファイルを展開できたノードにしか判定できない。 キーファイルが、「信用」出来る場合を考えてみますと、 ハッシュ値、つまり「メッセージダイジェスト」は、データ情報の特徴を圧縮したもので、同じデータを ハッシュにかければ、同じ値になるが、1バイトでも違うと、まったく違う値になります。 要は、ハッシュ値が一緒であればファイル内容も同じ(厳密に言うと、非常に低い確率で違う場合もあり) であると言うことです。 つまり、ハッシュ値を元に検索を行えば、改ざんや破壊が起こっていないファイルを 探す事がで来ます。 そして、改ざんや破壊が起こったファイルは、参照される事無くいつしか消えていきます。 472 名前：470 mailto:sage [2005/07/13(水) 03:23:59 ID:MNJFxM92] >>471 ちゃんと理解できてないんで、誤解してると思うけど。 例えば、このスレの過去ログをネットワークに投入したいとする。 投入する1次upノードは、当然内容を知っているはず。 ネットワークから、このスレの過去ログをダウンロードしようとしたノードは、 (その情報が確かなら)そのデータは過去ログであることを知っているはず。 隣接ノードに、1次upノードであること、またはダウン要求ノードであることが (ダウン要求の内容(この場合は過去ログであること)も含めて)ばれてしまうことは、 例えどんな暗号化がされていようとも、内容を知った上で送受信しているという事になる。 これは、このスレの過去ログが発禁扱いになっていて、政府が監視中であるなら 危険なことだと思う。言論の自由を目指すんだしw ダウン要求の内容がばれてしまうことは、ある要求をシステムでの要求に変えることと等価である。 あるファイルが落とせるってことは、投入側と取得側でなんらかの同意がいるってことでしょ。 取得するのと同じやり方で、取得方法だけ持っておいて、ネットワークを流れる要求を 監視されたらやばいんでないの、という意味。 当然中継ノードなら、内容は知らずに、P2Pネットワークとしての責務として ただ踏み台にされただけだから、(現時点の世界では)こういう心配はしなくていいのでは、と。 473 名前：470 mailto:sage [2005/07/13(水) 03:32:35 ID:MNJFxM92] ＞後段 キーファイルが信頼できるかどうかがそもそもやばいんで内科医ということ。 プロトコル的に、データが改変損傷してないのは保障するとして、 例でいうところの、このスレの過去ログではなく、Winny本スレの過去ログがおちてくる場合 そのキーファイルやら暗号化データはどうするのってこと。 そういうことする香具師はたくさんいるし、ミスってそうなることもあるよ。 内容知っている人にしかネットワークの暗号データは評価できないんだけど、どうやって排除すべきか。 内容が合ってるかどうかを流すことのできるノードも、情報を知っていることになって監視対象入りかも。 そういうことも含めて、誰が何の情報を知っていて、何の情報を知っていることになっていて 隠すべきものは何かな、と考えてたらよくわからなくなってしまって聞いたんだけど。 474 名前：425 mailto:sage [2005/07/13(水) 15:46:02 ID:OdrjvaIG] このシステムは、Winnyと言うより、Freenet的だったので、 さまざまな部分で、効率が悪い。 今度は、Winnyベースの高速な匿名性ファイル共有で、特にファイル提供者の 匿名性が非常に高い物を思いついたので、まとまり次第うｐします。 (キーファイルと暗号化ファイルに分けるという点は変わりません。) >>472 　このシステムにおいて、Freenetのような、アップデートの概念はありません。 　あるのは、「検索」と「ダウンロード」だけです。 　まず、「あるファイル」を自分の公開領域に置き、その存在をネットワークに知らせます、 　知らせる、といっても、「ここにあるよ」と言ったら、匿名性もへったくれもないので、 　ネットワークに、そのファイルの「検索クエリ」を送信します。 　そして、その検索クエリは、高い確率で自分のノードに戻ってきます。 　その時、自分自身で返事を返してやれば、誰にも悟られずに、そのファイルを 　ネットワークのクラスタに追加できます。 　しかし、キーファイルのような軽いファイルであれば問題ないが、重いファイルの場合、 　Freenet同様問題がでてくるので、根本的な見直しが必要 475 名前：425 mailto:sage [2005/07/13(水) 15:54:48 ID:OdrjvaIG] >>473 　まぁ、人間ミスするのでそれは、大した問題ではないと思う(笑 　そう言うのは、排除する必要もないんじゃ? 　問題になってくるのは、例えば『ダイエット本』で検索した時、『ダイエット本』に 　関係するキーファイルが落とされます。 　しかし、『ダイエット本』と書きながら、暗号化ファイルを落として復号してみたら、 　何故か『サラ金の広告』だった場合は問題です。 　このための公開鍵です。要は、公開鍵はIDです。信用できないIDは、信用しなければいいだけです。 　（その公開鍵であれば、無条件で消す） 　そして、このような信用できない公開鍵があれば、信用できる公開鍵も存在するはずです。 　公開鍵は、一種のIDです。ならば、信用性のある公開鍵の「なりかわり」の心配はないか? 　それは、公開鍵に対する秘密鍵が分からない限り、不可能です。 476 名前：login:Penguin mailto:sage [2005/07/13(水) 18:17:25 ID:4rsiUBe0] で、いつごろまで屁理屈こねくりまわすの？ 477 名前：login:Penguin mailto:sage [2005/07/13(水) 18:28:32 ID:+oLOISW/] おまえがしびれを切らして愚痴るまで。 つまりあともう少しだな。 478 名前：login:Penguin mailto:sage [2005/07/13(水) 20:32:46 ID:MNJFxM92] >>474 Freenetよか遅いのは考える意味がないw この案はこの辺りが潮時か… ＞｢検索クエリ｣ この送受信を傍受されたらどうするのって言ってるんだが。 ＞公開鍵 信用できる鍵にあたるまでがんばれってか。 攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。 >>445　で指摘されてるように、固定は危険だし。 479 名前：login:Penguin mailto:sage [2005/07/13(水) 20:59:14 ID:4rsiUBe0] >>477 すでに愚痴ってるわけだが。 480 名前：425 mailto:sage [2005/07/14(木) 16:51:28 ID:5jVfH12S] >>478 >Freenetよか遅いのは考える意味がないw 　私もそう思います。ですが、キーファイルの通信は非常に軽いので 　そのあたりで使えると思っています。 >この案はこの辺りが潮時か… 　一応、暗号化ファイルの通信を独立させた、次の案があるので、 　もう、暫く付き合っていただけませんか? >この送受信を傍受されたらどうするのって言ってるんだが。 　通信を暗号化したレイヤでトンネリング(SSLっぽいの)すれば、外部からのチャプチャリングは、 　シャットアウトできます。 　内部ノードは、自分の上位ノードと下位ノードのことしか、分からないので、 　どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。 481 名前：425 mailto:sage [2005/07/14(木) 16:52:55 ID:5jVfH12S] ・・・続き >信用できる鍵にあたるまでがんばれってか。 　むしろ、信用できる鍵の方が多くなると私は考えています。 　RSA2048bit公開鍵の鍵セットを作るには、どんなに強力なマシンでも 　かなり時間を喰らうのにくらべ、「除外(一切受け付けない)」のは一瞬で終わる。 　「攻撃者」が、鍵セットを作り続けたとしても、どっちが不利かといえば、 　圧倒的に「攻撃者」が不利。 　かといって、「攻撃者」は、「他の公開鍵」に成り代わろうとしても、 　相手の「秘密鍵」を、知らなければいけない。 　その「攻撃者」が、RSA2048bitをクラックできるとしたら、ネットバンキングは 　とっくの昔に破綻しています。 　ならば、そんな馬鹿な事を実際にする香具師は、殆ど現れないはずです。 482 名前：425 mailto:sage [2005/07/14(木) 16:54:57 ID:5jVfH12S] >攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。 　上記の理由で、「なりかわり」は、理論上できません。 　となれば、「同じ鍵」であれば「同一人物」です。 　要は、「あなたは、何を基準に『人』を信用しますか？」ということです。 　　少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は 　　「信用できない」 　　5回連続で、きちんとした暗号化ファイルが存在するキーファイルの鍵は、ある程度は、 　　「信用できる」 　って、ことです。 　上記のような簡単な判断は、アプリ側に任せていいと思います。 　あと、公開鍵の情報を保存しておく必要もあります。 >>445　で指摘されてるように、固定は危険だし。 外部からの、キャブチャリングは暗号化してしまえば、不可能です。 内部ノードは、上位ノードと下位ノードの事しか知りません。 その状況で、「公開鍵」の発信元を調べるのは、非常に困難を極めます。 「公開鍵」の発信元を調べるスピードよりも、ファイルが拡がるスピードの方が 圧倒的に速いからです。 一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。 483 名前：login:Penguin mailto:sage [2005/07/14(木) 17:31:19 ID:D9NFH06e] で、何%までできた？。机上の空論もいいけど、コード書いて実装できなきゃ 意味ないぞｗ 484 名前：login:Penguin mailto:sage [2005/07/14(木) 17:39:02 ID:TU8gjza9] よし、使用言語はObj-Cで決まり。 485 名前：login:Penguin mailto:sage [2005/07/14(木) 18:27:54 ID:+fLeQjmb] >>482 > 　　少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は > 　　「信用できない」 これだと単純すぎると思う。 暗号化ファイルはちゃんと存在するけど、内容が期待したのと違うっていうような攻撃が来るんじゃないかな。 こういう攻撃だと、除外する側は暗号化ファイルを受信して、内容を調べて判断しなきゃいけない。 鍵を作る手間に比べて、受信した内容を確認・判断する手間って、むしろ大きいんじゃないかな。 期待通りのファイルかどうかを判断するのは、自動化が難しい問題だろうし。 486 名前：login:Penguin mailto:sage [2005/07/14(木) 20:11:14 ID:PKmLnshm] 実際にコード書いて検証すればいいだけだのに、 どうして机上の空論を書くのに精を出しているのだろう。 487 名前：login:Penguin mailto:sage [2005/07/14(木) 21:13:19 ID:E+/HEPIn] しびれを切らして愚痴りだした香具師がいるなｗ 机上の空論、大いに結構。 488 名前：login:Penguin mailto:sage [2005/07/14(木) 21:20:30 ID:PKmLnshm] はて。 476 ：login:Penguin ：sage ：2005/07/13(水) 18:17:25 (p)ID:4rsiUBe0(2) で、いつごろまで屁理屈こねくりまわすの？ 477 ：login:Penguin ：sage ：2005/07/13(水) 18:28:32 ID:+oLOISW/ おまえがしびれを切らして愚痴るまで。 つまりあともう少しだな。 489 名前：login:Penguin mailto:sage [2005/07/14(木) 21:35:52 ID:ey7oBSjc] 425は机上の空論の妄想野郎。 >>433で本人が認めてるし。こいつ自身は実装やる能力がない。 そんな、脳ナシに標準化なんか出来るか。Freenetに任せとけ。 490 名前：login:Penguin mailto:sage [2005/07/14(木) 23:14:16 ID:HLeFWI2x] わからんかなぁ ほら、あれと同じ雰囲気を楽しむスレなんだよここは。 居酒屋や串焼き屋でだ、仲間内で出来もしない事を熱く議論することがあるだろ。 そういう空気が好きなんだよ俺等 491 名前：login:Penguin mailto:sage [2005/07/14(木) 23:26:53 ID:PKmLnshm] 釣り堀スレか。 492 名前：きたろう mailto:sage [2005/07/14(木) 23:38:17 ID:3X5YI5cJ] 常に欲求不満でイライラしている。 自分の能力に劣等感を持っている。 出る杭は徹底的に叩かないと気が済まない。 そんなネガティブな感情に流されてる暇人の存在を感じます、父さん！ 493 名前：login:Penguin mailto:sage [2005/07/16(土) 03:35:55 ID:qxGyOozH] >>486 実際に手を動かせるくらいできてればこんなところで考える前に ダウソで"ちょっとまちなー"ができるって。 システムが中途半端だとコーディングする意味ないし。 >>480 ＞通信の傍受 外部からの、ではなく、内部からのってこと。 つまり(正規の動作をある程度行う)スパイノードの存在は大丈夫かなと思って。 ＞どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。 検索システムがどのように予定されてるのかはわからないけど。 例えばクエリが帰ってくるようにリターンアドレスを入れておくような実装だと、 「誰が」リクエストを出したのかがばれてしまう、というような情報漏れを心配している。 ＞一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。 1次Upノードが特に危険だと思うんだが。 Shareとかは強制拡散してるみたいだし、Freenetとかはバッファにプッシュして 所持ノードの概念がなくなるみたいだし、いろいろ工夫してると思う。 Winnyは、何もしない、という戦略をとったが。 494 名前：425 mailto:sage [2005/07/16(土) 23:10:58 ID:jAChWphq] 新案をコトコト煮詰めています。 暗号化ファイルは、StaticNATを使った面白いネットワーク偽装を 考えています。 >>493 キーファイルの共有は、完全なFreenetスタイルを考えています。 つまり探索とかもいっしょ、大量のノードが協力しない限り、 要求者を求めるのは難しい。 >1次Upノードが特に危険だと思うんだが。 「自分自身」で「自分自身しか持っていないファイル」を探索するクエリを、 隣のノードに送信すると、どうなると思います？ Freenetでは、経路上に多くのループが発生します。 つまり、必ず探索クエリは、自分自身に戻ってきます。 そこで、アップロードしながらダウンロードしたらどうなるでしょうか? 自分の下位ノードは、自分がそのファイルを中継しているか、アップしている かは分かっても、誰がその要求を出しているのか分かりません。 逆に、上位ノードは、自分がそのファイルを中継しているか、要求している かはわかっても、そのファイルが何処から流れてきているのかわかりません。 そして、途中経路では「複製」が出来ます。 つまり、1次Upノードは、誰にも悟られる事なくネットワーク上にファイルの 複製を作れます。 つまり、これで誰が1次Upノードかは謎になる。 495 名前：login:Penguin mailto:sage [2005/07/17(日) 00:28:28 ID:iMIptb/B] ほんとにできてるの？何％くらい 496 名前：login:Penguin mailto:sage [2005/07/17(日) 01:26:26 ID:ksRYqrdf] >>495 >>489 497 名前：login:Penguin mailto:sage [2005/07/17(日) 09:10:57 ID:3e1zqbRW] >>495-496 早漏は損だよ 498 名前：login:Penguin mailto:sage [2005/07/17(日) 17:36:40 ID:hmmV4Rhb] >>494 ＞1次Upノード保護 経路のループを利用して自己偽装Down要求ってことですな。 ＞Freenetでは、経路上に多くのループが発生します。 ＞つまり、必ず探索クエリは、自分自身に戻ってきます。 このループはある程度大きくないと効果が期待できないと思うんですが、 あまり大きいと、中継転送による速度の低下が心配されると思いますが バランスとかはどうなるでしょうか。 確実にクエリが戻ってくることは期待して大丈夫ですかね。 繋ぎ変えがおこるネットワークならば、ループが切れたりしないかな。 ＞ネットワーク偽装 期待してます。よろ。 499 名前：425 mailto:sage [2005/07/18(月) 18:56:18 ID:juv970X8] 「HannyNet（Hashing anonymous winny Network）」案 ちょっとは、まとまった思うので書いてみる。 「HoneyNet」(行動の一部始終を監視できるように設計されたネットワーク)の 真逆を逝っているので、何となくつけてみたくなった。 匿名性の重要度 　ファイル提供者　>> ファイル要求者 　ファイル提供者の匿名性は最優先される。 　なぜなら、「提供する者」がいなくなれば、 「共有」は存在しえないからである。 　つまり、ファイルを提供すればするほど、匿名性の保障に優位に立つことができて、逆に、 吸いとるだけの輩は、匿名性を保障しないようにシステム全体が推移するような仕組みが 望ましい。 500 名前：425 mailto:sage [2005/07/18(月) 18:57:13 ID:juv970X8] ファイル構成 1.キーファイル（テキスト形式） 　 　　1-0)キーワード情報 　　　　クラスタ化に必要な自然言語パターン 　　1-1)暗号化ファイル共通鍵 　　　　読んで字の如く、暗号化ファイルの共通鍵。 　　1-2)暗号化ハッシュコード　　　　 　　　　2-1)のハッシュコードを、1-3)の秘密鍵で、暗号化したもの。 　　　　(べつに、1-1)で暗号化しても問題ない。) 　　　　意味がないように思えるが、非常に意味がある。 　　　　暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。 　　　　つまり、「暗号化ファイル」から「キーファイル」は分からない。 　　1-3)IP/ポート交換ワンタイム公開鍵(RSA 128bit) 　　　　IPとポート番号を申請するときに使う。 　　　　詳しくは、後述。 501 名前：425 mailto:sage [2005/07/18(月) 18:58:06 ID:juv970X8] 1-4)公開鍵(RSA 2048bit) 　　　　1-5)の公開鍵。　　 　　1-5)電子署名 　　　　1)〜4)の電子署名。こうした方が、たぶん都合がいい。 　　1-6)1-4)のハッシュコード 　　　　ノードにキャッシュされる度、随時上書きされる。 　　　　キーファイルの検索では、同時に公開鍵の参照も許しているが、 　　　　256バイトのデータを毎回参照していたのでは、ノードに対する 　　　　負担が大きい。 　　　　そこで、ハッシュを用いて大まかに検索して送信する。そして、 　　　　最終的な判断は、検索クエリを出したノード自体に委譲する。 　　　　ここで、使うハッシュ関数は、MD5やMD4のように厳密なものではなく 　　　　計算量が、非常に軽いものが望ましい。固定ビット長なので、上手い 　　　　方法があるはずです。 502 名前：425 mailto:sage [2005/07/18(月) 18:59:12 ID:juv970X8] 2.暗号化ファイル（バイナリ形式） 　　2-1)ハッシュコード 　　　　2-2),2-3)のファイルの内容をハッシュにかけた値(MD5) 　　　　要は、ファイル名。 　　　　ノードにキャッシュされる度、随時上書きされる。 　　2-2)データフィールド 　　　　暗号化された、データが入っています。 　　2-3)IP/ポート交換ワンタイム秘密鍵(RSA 128bit) 　　　　ファイル最後尾から、128bitが1-3)に対する秘密鍵になっている。　　　　 　　　　詳しくは、後述。 503 名前：425 mailto:sage [2005/07/18(月) 19:00:32 ID:juv970X8] 3.通信ポート 　　 　　3-1)管理ポート(TCP)　 　　 ポート番号：　インストール時に決定 　　　　 　　　　主に､キーファイルの検索/受け渡しをする。 　　　　暗号化ファイルのプロキシ要求(後述)や、NAT要求(後述)もこのポートで行う。 　　　　この通信は、暗号化される。 　　　　要は、コマンドもファイルも一緒に送り、暗号化の手間を軽減する。 　　　　処理の優先度は、 　　　　NAT要求 > 検索クエリ > キーファイルの送受信 > プロキシ要求　　　　 3-2)暗号化ファイル検索ポート(UDP) ポート番号：　インストール時に決定 3-1)の通信でコネクションが張られていないIPからの要求は、 　　　　全て遮断することとする(応答は受け入れる)。 　　　　この通信は暗号化されない。 504 名前：425 mailto:sage [2005/07/18(月) 19:01:18 ID:juv970X8] 　　3-3)暗号化ファイル転送ポート(TCP) 　　　　ポート番号：随時決定 　　　　特に説明ナシ。この通信も暗号化されない。 　　3-4)ICMPエコー要求(ICMP) 　　　　イワユル、「ping」コマンドで、セキュリティ上は切っておいた方が望ましいが、 　　　　相手のマシンが、起動しているかどうかを調べるのに最も楽な方法。 　　　　TCPコネクションを確立させる前にpingを送れば、余計なSYNパケットを出さなくてすむ。 505 名前：425 mailto:sage [2005/07/18(月) 19:02:07 ID:juv970X8] コマンド・パケットフォーマットなど 今の段階では適当。とりあえず、決まっている物から 　(所詮、暇人の考える程度の事ですから) 4.暗号化ファイル検索パケット(UDP通信) 　　4-1)余命(8bit) 　　　　そのパケットのが後、どれ位生きれるのかを示す。1つノードを通過すると、 　　　　年をとって余命が減るかもしれない。また、減らないかもしれないし、 　　　　一気に老けてしまうかもしれない(要は適当に決まる)。 　　　　勿論、0になった地点で死にます。 4-2)乱数(24bit) 　　　　通信を区別するために、適当な乱数を設ける。 　　4-3)ハッシュコード(128bit)　 　　　　暗号化ファイルのハッシュ値 506 名前：425 mailto:sage [2005/07/18(月) 19:03:03 ID:juv970X8] 　　4-4)暗号化IP/返信ポート(128bit) 要求ノードのIPと返信ポートを1-3)で暗号化したもの。 　　　　暗号化ファイル、つまり、1-3)の秘密鍵である2-3)を所持している者だけが分かる。 　　　　暗号化ファイルを所持していたとしても、キーファイルを所持していなかった場合、 　　　　ファイルの内容は分かりません。 　　　　128bitRSA暗号なので、公開鍵が分かれば、本気になれば解ける程度の強度。 　　　　つまり、キーファイルから暗号が解けるかもしれない。 　　　　　 　　　　ですが、キーファイルがあればの話しですし、公開鍵も不明な状態で解けるほど 　　　　軟な暗号じゃありません。 　　　　キーファイルあっても、ハッシュコードから、直接キーファイルは分からないので 　　　　ないも同然。 　　　　勿論、所持しているキーファイルの1-2)暗号化ハッシュコードを復号していた場合なら、 　　　　公開鍵は、分かってしまいます。 　　　　しかし、匿名性の本質は、暗号化の強度では決まりません。 つまり、要求ノードが「ファイル要求者」だとは、限らないということです。 507 名前：425 mailto:sage [2005/07/18(月) 19:06:51 ID:sTNmNfe5] 5.プロキシ要求コマンド　必要引数 5-1)ハッシュコード 暗号化ファイルのハッシュ値 5-2)IP/ポート交換ワンタイム公開鍵(RSA 128bit) キーファイルの1-3)と同じ NAT要求コマンド 　　ポート貸与要求、延長要求、開放要求の3つがあるが、詳しくは後述する。 6.通信体系 　　6-1)留意点 　　 　仕様的に、NAPTユーザーは、使用不可能になる。 　　 　まぁ、人(会社､学校)の回線を使って、P2Pするな。 　　 　自己責任でせんかい！　 　　 　って、意味もあります。(どっちにしろコイツ等、吸い取り専門ですし) 　　6-2)キーファイル通信 　　　　キーファイルの通信は、Freenet的で、ノード間の通信は暗号化されます。 　　　　Freenetとの違いは、検索が「自然言語」である事。 　　　　「自然言語+公開鍵(のハッシュ)」の検索も可。 　　　　Freenetは、小さいファイルを扱うには、非常に優れています。 508 名前：425 mailto:sage [2005/07/18(月) 19:08:34 ID:sTNmNfe5] 　　6-3)暗号化ファイル通信(基本検索､基本通信) 　　　　暗号化ファイル通信の通信は、「基本通信」､「プロキシ通信」、「NAT通信」に分かれます。 　　　　まずは、基本となる「基本通信」について説明します。 　　　　基本通信は、完全な「直接通信」です。この段階では、通信が行われる2つのノード間では 　　　　匿名性もへったくれもありません。ですが、「2つのノード」以外には、通信している事は 　　　　悟られません。勿論、「2つのノード」のどちらかに悪意がある場合は別になります。 　　　　この段階では、匿名性はないに等しいことになります。 　　　　検索は、UDPポートを使った、一斉広報による検索方式です。 　　　　トラフィックが無駄に膨れ上がる恐れがありますが、上手くいけば高速な回答が予測できます。 検索方法は、まずファイル要求ノードが、現在接続されている全てのノードに検索パケットを送信する。 　　　　検索パケットを、受け取ったノードは、自分の公開領域の中から、暗号化ファイルを探します。 　　　　暗号化ファイルが存在すれば、暗号化ファイルに埋め込まれている2-3)IP/ポート交換ワンタイム秘密鍵で復号します。 　　　　復号すれば、IPと返信ポートとが分かるので、自分のIPと接続を許すポートを付加した応答パケットを『直接』送ります。 　　　　「自分のIPと接続を許すポート」は、中間ノードを通らないので暗号化する必要性はないのですが、応答パケットと、 　　　　検索パケットの区別を外部から難しくするために、あえて2-3)IP/ポート交換ワンタイム秘密鍵で暗号化して送ります。 509 名前：425 mailto:sage [2005/07/18(月) 19:09:17 ID:sTNmNfe5] 　　　　これで、要求ノードは、ファイルの存在場所を知る事ができます。匿名性はないに等しいのですが、これが基本となります。 　　　　暗号化ファイルを探しなければ、余命を更新して、現在接続されている全てのノードに検索パケットを 　　　　送信する(ただし、送信元ノードには送らない) 　　　　余命をいくつ減らすかを乱数でランダムに決めますが、余命によって重み付けが変わってきます。 (この例は、適当で極端な例です) 　　　　余命　１: 7割の確率で1減らす。3割の確率で減らさない。 余命　２: 5割の確率で1減らす。2割の確率で2減らす。3割の確率で減らさない。 　　　　余命 ３: 5:2:1:2 = 1減らす:2減らす:3減らす:減らさない 　　　　余命 ４: 4:2:2:1:1 = 1減らす:2減らす:3減らす:4減らす:減らさない 　　　　余命 ５: 4:2:2:1:1:0 = 1減らす:2減らす:3減らす:4減らす:5減らす:減らさない 検索パケットは、余命が0になった地点で消滅します。 検索パケットの余命は、第１回一斉広報は、「1」。第２回一斉広報は、「2」と段々深くなっていきます。 　　　 どの程度の深さまで、探せば良いのかは数学的モデルを立ててやる必要があるかもしれない。 510 名前：425 mailto:sage [2005/07/18(月) 19:10:02 ID:sTNmNfe5] 　　6-4)暗号化ファイル通信(プロキシ通信) 　　　　普通のプロキシ通信ですが、プロキシの選び方はまったくの「デタラメ」です。 まず、接続されているノードの中から適当に、「プロキシ要求コマンド」を送信します。 　　　　プロキシ要求コマンドには、5-1)『ハッシュコード』と、5-2)『IP/ポート交換ワンタイム公開鍵』が 　　　　含まれます。 　　　　プロキシ要求コマンドを受け取ったノードは、9割の確率で、6-3)「基本検索､基本通信」に移行し、 　　　　ファイルを中継します。 　　　　のこり、1割の確率で、そのノードは、さらに接続されているノードの中から適当に、 　　　 「プロキシ要求コマンド」を送信します。 　　　　90%以下の確率で、 　　　　　　　　　要求ノード　＝＝＝　中継ノード　＝＝＝　提供ノード 　　　　99%以下の確率で、上のパターンか、 　　　　　　　　　要求ノード　＝＝＝　中継ノード　＝＝＝　中継ノード　＝＝＝　提供ノード 　　　　つまり、誰が始めに「プロキシ要求コマンド」を出したかを、分かりにくくするのが目的。 　　　　中継ノードは、中継ファイルをキャッシュするが、中間ノードの役割は要求者に対するフィルタです。 　　　　ですから、キャッシュの消去は個人の自由です。 　　　　キャッシュを消去しなっかった場合、6-3)「基本検索､基本通信」で引っかかって、提供ノードに 　　　　なってくれます。 511 名前：425 mailto:sage [2005/07/18(月) 19:10:51 ID:sTNmNfe5] 　　6-4)暗号化ファイル通信(プロキシ通信) 　　　　普通のプロキシ通信ですが、プロキシの選び方はまったくの「デタラメ」です。 まず、接続されているノードの中から適当に、「プロキシ要求コマンド」を送信します。 　　　　プロキシ要求コマンドには、5-1)『ハッシュコード』と、5-2)『IP/ポート交換ワンタイム公開鍵』が 　　　　含まれます。 　　　　プロキシ要求コマンドを受け取ったノードは、9割の確率で、6-3)「基本検索､基本通信」に移行し、 　　　　ファイルを中継します。 　　　　のこり、1割の確率で、そのノードは、さらに接続されているノードの中から適当に、 　　　 「プロキシ要求コマンド」を送信します。 　　　　90%以下の確率で、 　　　　　　　　　要求ノード　＝＝＝　中継ノード　＝＝＝　提供ノード 　　　　99%以下の確率で、上のパターンか、 　　　　　　　　　要求ノード　＝＝＝　中継ノード　＝＝＝　中継ノード　＝＝＝　提供ノード 　　　　つまり、誰が始めに「プロキシ要求コマンド」を出したかを、分かりにくくするのが目的。 　　　　中継ノードは、中継ファイルをキャッシュするが、中間ノードの役割は要求者に対するフィルタです。 　　　　ですから、キャッシュの消去は個人の自由です。 　　　　キャッシュを消去しなっかった場合、6-3)「基本検索､基本通信」で引っかかって、提供ノードに 　　　　なってくれます。 512 名前：425 mailto:sage [2005/07/18(月) 19:13:05 ID:NWEvQOcw] 6-5)暗号化ファイル通信(NAT通信) 　　　　(説明は、大雑把です) 　　　　今回の目玉である「提供ノード」の匿名性を上げる目的で考えたもので、提供ノードに必須な機能です。 　　　　 　　　　これは、StaticNATをネットワーク偽装です。StaticNATとは、NATテーブルを元に、自分のあるポートに 　　　　アクセスしたパケットを、別のIPに書き換えて、転送する技術です。 　　　　LAN内のプライベートIPが割り振られたWWWサーバーなどに、外部からアクセスするために使われます。 　　　　それらを駆使して、要求ノードAは、Bと通信していると思い込んでいるが、実はCと「直接通信」している。 　　　　と言う、なんとも「あやふや」な事ができます。 　　　　原理は、こう言うことです。 　　　　まず事前に、ノードC(192.168.1.32/24)は周りのノードに適当に「ポート貸与要求」を出します。 　　　 ノードB(172.168.5.123/24)に「ポート貸与要求」が来ると、空いているポートをランダムに選びます。 　　　　ここでは、「4747」とします。これをノードCに通知します。 513 名前：425 mailto:sage [2005/07/18(月) 19:13:45 ID:NWEvQOcw] 　　　　貸与要求したノードCも、「4747」が開いていれば、「OK」を返し、開いていなければ、 　　　　同じ動作を繰り返します(普通､開いています。) 　　　　ノードBは、「4747　⇒　ノードC(192.168.1.32/24)」と言う情報をNATテーブルに書き込みます。 さらに、「192.168.1.32 ⇒ 172.168.5.254」とルーティング情報を書き加える。 　　　 (なお、172.168.5.254は、ノードB(172.168.5.123/24)のデフォルトゲートウェイ) これで、「4747」にアクセスされたパケットは、無条件で、ノードBに送られます。 　　　　(出来なかったら、仮想ネットワークカードを作ってやる必要があります。) 　　　　しかし、このままでは不正利用を招くので、ノードBには、TCPのPSHパケットと、UDPパケットは 　　　　転送しないよう設定します。 　　　　これで、ノードBの設定はおわりです。 514 名前：425 mailto:sage [2005/07/18(月) 19:14:32 ID:NWEvQOcw] 　　　　ノードCは、ノードBと「同じIP」を持つ、仮想ネットワークカード「X(172.168.5.123/24)」を作成します。 　　　　物理ネットワークカードから、「4747」にアクセスされたパケットを、仮想ネットワークカード「X」に 　　　　送るために、「4747　⇒　X(172.168.5.123/24)」と言う情報をNATテーブルに書き込んみます。 　　　　これで、物理ネットワークカードから、「4747」にアクセスしたパケットは、無条件で全て、 　　　　仮想ネットワークカード「X」に送られます。 　　　　これで全ての下準備は、完了しました。 　　　　ノードCに検索パケットが届いて、調べてみるとその暗号化ファイルを発見。 　　　　復号してみると、ノードA(10.1.1.2/24)から届いた物である事が分かった。 　　　　ここで、「10.1.1.2 ⇒ 192.168.1.254」とルーティング情報を書き加える。 仮想ネットワークカード「X(172.168.5.123/24)」から、応答パケットを送信。 　　　　 　　　　ノードAは、172.168.5.123(ノードBと見せかけた「X」)が、「4747」の接続を許可したしてくれたと知る。 　　　　ノードAは、172.168.5.123(ノードB)の「4747」に、SYNパケットを送る。 　　　　ノードBは、192.168.1.32(ノードC)の「4747」に、SYNパケットを転送。 　　　　ノードCは、172.168.5.123( 「X」)の「4747」に、SYNパケットを転送。 　　　　「X」 は、10.1.1.2(ノードA)の送信元ポートに、ACK,SYNパケットを転送。 　　　　（以下省略） 　　　　どうなっているかを図で説明すると、 　　　　ノードＢ ------------------------------┐ ↑　　　　　　　　　　　 ｌ ｌ　　　　　　　　　　　 ｜ 　　　　　　ｌ　　　　　　　　　　　　　　　　 ↓ 　　　　ノードＡ　<---------- 仮想カード ← ノードC 515 名前：425 mailto:sage [2005/07/18(月) 19:16:58 ID:NWEvQOcw] 　　　　つまり、ノードA からの通信は、A→B→Cとなるが、ノードCからの通信は、C→Bとなる。 こうすると、何がいいのかと言うと 　　　　(1) 高速転送 ノードA からの通信量より、ノードCからの通信量はの方が遥かに多い。 　　　　　　そのため、直接通信と変わらない速度が期待できる。 　　　　(2) ファイル提供者の匿名性が高い(最重要) 　　　　　　ファイル提供者の匿名性について考えてみると、 　　　　　　＊ノードAは、『あるファイル』を、ノードＢから落としているようにしか見えない。 ＊ノードBは、「ノードC」と「ノードA」が通信している事は分かるが、「ノードC」が、 　　　　　　「ノードA」に、『どういうファイル』を送っているかは、ノードＢを中継しないので、 　　　　　　『物理的』に、わからない。 　　　　　　しかし、ノードAが「ファイル要求者」の場合、ノードCからは、モロで見えているので、 　　　　　　完全な通信モデル図はこうなる。 　　　　　　　　　　　　　　　NATノード ----------------------------------┐ 　　　　　　　　　　　　　　　　　↑　　　　　　　　　　　　　　　　　　　ｌ 　　　　　　　　　　　　　　　　　ｌ　　　　　　　　　　　　　　　　　　　｜ 　　　　　　　　　　　　　　　　　ｌ　　　　　　　　　　　　　　　　　　　↓ 　　　　　　要求ノード　＝＝＝　中継ノード　<---------- 仮想カード ← 提供ノード つまり、最終的には、Winnyと同程度のスピードで、クラスタ化はされないので 　　　　　　少々、使い勝手は悪い物になると思われます(前ほどではないが)。 516 名前：425 mailto:sage [2005/07/18(月) 19:18:16 ID:NWEvQOcw] 新手のアラシさんみたいな量になってしまった(笑 517 名前：525 mailto:sage [2005/07/18(月) 20:26:26 ID:UC0vJmtQ] なんだかよう分からんが期待しとるよ 518 名前：login:Penguin mailto:sage [2005/07/18(月) 22:52:22 ID:g7t80EI+] >>517 >>490 519 名前：login:Penguin mailto:sage [2005/07/19(火) 03:08:32 ID:K55Dj3jz] ざっとしか読んでないんで間違ってたら訂正よろ。 重要な点をまとめると 1)キーファイルにワンタイムRSA公開鍵、暗号化本体ファイルにワンタイムRSA秘密鍵を仕込んでおく。 ある暗号化本体ファイルを要求するノードは、返答先をキーファイルの公開鍵で暗号化する。 暗号化本体ファイルを持っているノードのみが、これを復号して通信できる。返答の中の保持ノードの アクセス先は秘密鍵で暗号化され、キーファイルを持っているノードのみ復号できる。 2)キーファイルから、暗号化本体ファイルを落としたいノードは、自分のIPアドレスとポートを ワンタイム公開鍵で暗号化し、ブロードキャストする。この本体検索要求は、TTLを仕込んでおき 転送されているうちにある程度で破棄されるようにする。 応答があれば、復号した所持ノード情報を元に直接ダウンロードする。 3)もしくは、暗号化本体ファイルのハッシュと、ワンタイム公開鍵を、隣接ノードにプロクシ転送要求をかける。 要求されたノードは、適切な確率で再転送か、2)で示したダウンロードを実行する。 4)自分のIPアドレスとあるポートを、他のノードに貸し出すこともできる。 この場合、貸し出したポートへの通信はすべて転送される。 520 名前：login:Penguin mailto:sage [2005/07/19(火) 03:15:47 ID:K55Dj3jz] ごめん。正直NATの説明がよくわからなかった。 これって実装の手間を考えたら、効果ってそんなにあるの？ NATに応じなくてもネットワーク的にペナルティないんだったら俺なら応じてやんない。 プロクシ転送要求に応じれば、自分のHDDと帯域は使われるかもしれない。 けれども、自分の出した要求が、他の人の要求の結果だという言い訳ができるし、 ひょっとしたらお宝ファイルかもという期待がある。 転送の中身見れないなら、踏み台になる意味ないじゃん。 >>500 暗号化ファイルのハッシュがわかんないと落とせないんだったら キーファイルに書いてないと、人間言語からの検索が不可能になるのでは。 521 名前：425 mailto:sage [2005/07/19(火) 21:40:31 ID:mMosH/WX] >>519 　スマソ。大体、そんな感じです。 >>520 　>ごめん。正直NATの説明がよくわからなかった。 　　くわしくは、「StaticNAT」か「ポートフォワーディング」でぐぐってください。 　 　>これって実装の手間を考えたら、効果ってそんなにあるの？ 　　私もプログラマじゃないので詳しい事は言えないが、Linuxで実装するなら、 　　そこまで難しくないと考えられる。 　　ここに書いていることは、Linuxカーネルが提供するサービスを 　　サーバOSならば当然持っている機能を組み合わせただけです。 　　つまり、適当にOS呼び出して使うだけでOK(のはず) 　　 　　逆に､Windowsでは、面倒かも。 522 名前：425 mailto:sage [2005/07/19(火) 21:45:21 ID:mMosH/WX] 続き・・・ 　>NATに応じなくてもネットワーク的にペナルティないんだったら俺なら応じてやんない。 　　べつに、大して重い処理じゃないし、単に転送するだけし、主にACKパケットを 　　中継するだけなので、帯域を犯される心配もない。ISDNでもOK(笑 　　ペナルティではなく、応じてくれた相手に対して報酬になるようした方が 　　よいのでしょうけど、今は詳しくは考えていません。 　>プロクシ転送要求に応じれば、自分のHDDと帯域は使われるかもしれない。 　>けれども、自分の出した要求が、他の人の要求の結果だという言い訳ができるし、 　>ひょっとしたらお宝ファイルかもという期待がある。 　>転送の中身見れないなら、踏み台になる意味ないじゃん。 　　はっきり言って、中継ノードにされることは『踏み台』にされるだけで、 　　何のメリットもない 　　(積極的にファイル供給者になると少し変わってくるが、そのことは、また今度) 　　お宝ファイルがあったとしても、それに対応するキーファイルが見つかる 　　可能性は、この仕様では薄い。 　　別に、『踏み台』になるかならないかは、そのノードの自由だと考えています。 　　ですが、『踏み台』に成らないノードに対して、誰が『踏み台』になろうと思います？ 　　結果、そういうノードは、孤立していきます。 　　別にプロキシ無しでも通信可能ですし、『言論の自由』を求めない方には丁度いいのかも(w 523 名前：425 mailto:sage [2005/07/19(火) 21:47:03 ID:mMosH/WX] 続き・・・ >>500 　>暗号化ファイルのハッシュがわかんないと落とせないんだったら 　>キーファイルに書いてないと、人間言語からの検索が不可能になるのでは。 1-0)キーワード情報 　　　　クラスタ化に必要な自然言語パターン ↑これのことですか? 　　　これには、色々なキーワードを、URLエンコードされた形で入れておきます。 　　　キーワードは、アップ時に「ジャンル」と「ファイル名」のような物を要求し、 　　　適当にアプリ側で文法解析させて、キーワード情報として入れておきます。 　　　 　　　これで、キーファイルを「自然言語」で検索して、キーファイルに付いている 　　　ハッシュの暗号化を、これもまたキーファイルに付いている鍵で復号して、 　　　そのハッシュ値で、暗号化ファイルを検索します。 524 名前：425 mailto:sage [2005/07/19(火) 21:50:39 ID:mMosH/WX] 訂正: クラスタ化 →　検索 結構、書き貯めしていたので、なぜこんな間違いを書いたのかは まったく記憶にない。 525 名前：login:Penguin mailto:sage [2005/07/20(水) 00:28:12 ID:IaDxISng] >>523 読み間違えてました。 キーファイルから暗号化本体ファイルへのリンクとなるハッシュは、ワンタイムRSA秘密鍵で 暗号化されてるのね。キーファイルに公開鍵が含まれるから解けると。 ＞暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。 ＞つまり、「暗号化ファイル」から「キーファイル」は分からない。 ってどういう意味？暗号化ファイルを持っていれば、公開者RSA 1-4) 1-5)を除いて キーファイルは生成できるんじゃ。 >>521 StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、 プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね) めんどくさそうと。 プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、 インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。 そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、 他で代替可能でないのかについて、ちょっとよくわからなかった。 526 名前：login:Penguin mailto:sage [2005/07/20(水) 00:30:31 ID:IaDxISng] ちなみに。 RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ 信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。 527 名前：login:Penguin mailto:sage [2005/07/20(水) 00:38:55 ID:zmMtfR5C] NAT は Skype とかが使ってる UDP なんちゃらで解決しないのか？ 528 名前：425 mailto:sage [2005/07/20(水) 21:48:47 ID:d8u1kb3S] >>525 >＞暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。 >＞つまり、「暗号化ファイル」から「キーファイル」は分からない。 >ってどういう意味？暗号化ファイルを持っていれば、公開者RSA 1-4) 1-5)を除いて >キーファイルは生成できるんじゃ。 暗号化ファイル自体は、500>>の 1-1)暗号化ファイル共通鍵 　　　　読んで字の如く、暗号化ファイルの共通鍵。 によって暗号化されており、キーファイルがなければ解読不可能です。 >＞つまり、「暗号化ファイル」から「キーファイル」は分からない。 これについては、分かりやすいモデルで説明しますと、こう言うことです。 (実際は、ちょっと違います) 529 名前：425 mailto:sage [2005/07/20(水) 21:51:17 ID:d8u1kb3S] キーファイルA　　　523*769 キーファイルB　　　617*857 キーファイルC　　　677*787 キーファイルD　　　727*643 キーファイルE　　　809*661 キーファイルF　　　563*619 キーファイルG　　　467*647 キーファイルH　　　503*991 暗号化ファイルA　　534749 暗号化ファイルB　　498473 暗号化ファイルC　　402187 キーファイルの右に書いているのが、「暗号化ハッシュコード」で 暗号化ファイルの右に書いているのが、「ハッシュコード」です。 キーファイルから、暗号化ファイルを見つけるには、 キーファイルAの「暗号化ハッシュコード」は、「523*769」 　　　　　523*769 = 402187 なので、「キーファイルA」の暗号化ファイルは「暗号化ファイルC」だと 簡単に分かります。 暗号化ファイルAに対する、キーファイルはどれでしょうか？(制限時間30秒) 普通、ムリですよね？ つまり、「キーファイル」から「暗号化ファイル」は分かっても、 「暗号化ファイル」から「キーファイル」は分からない。 530 名前：425 mailto:sage [2005/07/20(水) 22:38:29 ID:X6ELMDVA] >StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、 >プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね) >めんどくさそうと。 　まず、P2Pやるなら市販のパーソナルFWは消しときましょう。 　(つうか、linux用のパーソナルFWってあるのか？) 　つまり、使ってないポートは、全部斬って置いて、使うポートは、アプリ(デーモン)自体が、 　アクセス制限かけないといけません。(httpdとかsendmailとかも、全部そうなってます。) 　パーソナルFWは、全自動で使ってないポートは、全部斬ってくれるだけで、 　他は大した事はやってくれません(FWとウイルス対策ソフトは基本的に違うモノです)。 　つまり、P2Pといっても『サーバ』なので外からの、アクセスを許すことになるので、 　必ず、それ相応のリスクは必ず伴います(Winnyのウイルスとか)。 　まぁ、デーモンの起動ユーザをプロセスごとに複数の一般ユーザ分ければ、 　実質的な被害は、あまり出ないでしょうけど。 531 名前：425 mailto:sage [2005/07/20(水) 22:39:39 ID:X6ELMDVA] >プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、 >インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。 >そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、 >他で代替可能でないのかについて、ちょっとよくわからなかった。 　結論から言うと、プロキシの方が、セキュリティ面をしっかり考えなければならない。 　「ポートフォワード」で、セキュリティが懸念されるのは、ネットワークの内側(LAN内)に 　 ネットワークの外側（インターネット）からアクセスがあるからです。 　 これでは、FWを付けても、その穴から突破されれば、無防備なLAN内のPCに簡単に 　 アクセスされてしまいます。 　一方、P2Pは、「自分」と「その他」の概念しかなく、BがCに「ポートフォワード」して、 　AがCにアクセスした所で、セキュリティー的には、AがCに直接アクセスするのと変わりません。 　Bは、単なるルータにすぎません。 　しかし、プロキシの場合、デーモンつまり、アプリ自身が提供するサービスなので、 　アプリ自体に、バグがある場合、速攻で攻撃対象になります。 532 名前：425 mailto:sage [2005/07/20(水) 23:16:59 ID:fW484GcX] >ちなみに。 >RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ 「RSA公開鍵ペア」はIPを交換する鍵ですよね？ 「書き換える」ためには、「キーファイル」と「暗号化ファイル」の双方を所持していかないと、 書き換えられません、さらに、書き換えた「キーファイル」と「暗号化ファイル」を流通させないと いけません。 とても、面倒で時間がかかります。そんな事しなくても「キーファイル」と「暗号化ファイル」を もっていれば、どこの「中間ノード」と思われるノードが、「どんな」ファイルを 欲しているかは分かります。 じゃあ、何故「中間ノード」を攻撃するのか?　単にクラックが目的であれば、中間ノードなど 関係無しに、当たりかまわず攻撃しまくればいい。 つまり、結論としては、単なる「クラッカー対策」 クラッカー対策は、全てに通じるもので、P2Pに限った問題ではありません。 (それが難しいのですけどね。) 533 名前：425 mailto:sage [2005/07/20(水) 23:18:49 ID:fW484GcX] >信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。 　信用を集めてから、粗悪なファイルを流すということですか？ 　攻撃にしては、時間がかかりすぎると考えられるし、さらに信用を集めるための 　ファイルは、何処から持ってくるのかという問題がある。 　さらに、匿名性自体を犯す攻撃じゃありません。 　結局、得するのは信用を集めている間に、ファイルを得た人々だけです。 534 名前：425 mailto:sage [2005/07/20(水) 23:39:06 ID:BeHtAV13] >>527 >NAT は Skype とかが使ってる UDP なんちゃらで解決しないのか？ UDP hole punching のことですね。 私も、あまり知らないんで詳しい事はいえませんが、 これは、あるサーバーが、IPとポートを貸し出し、通信を ネットワークレベルで仲介してくれる技術です。 まぁ、これをP2Pと呼べるのか？という疑問もありますし、 匿名性の概念はありません（と思う） さらにいえば、現在の仕様では、NATの中は通してもらえません。 535 名前：login:Penguin mailto:sage [2005/07/21(木) 02:58:11 ID:z2CP8IVj] >>532 中間者は、自分用のRSA鍵ペア(ポート用とファイル用)を作っておき、キーファイルの伝播の際に 1-3) 1-4)を自分用のものにすりかえて、1-2) 1-5)をあわせておく。 暗号化ファイル検索要求が来れば、おもむろに自分の秘密鍵で検索をかけたノードを復号できる。 この書き換えは、もともとのキーファイルを持っているだけでよく、 (中身を知る必要がなければ)暗号化ファイルは必要ない。 システム的に排除できる可能性は、1-4)の公開鍵が実績があるかどうかでキーの信頼度を 決めることだろうけど、簡単に信頼度を集められるようにすると、少し正常動作をしてあとは釣り人に なればいいだけだし、あまり難しくすると長い間同じ鍵を使わなくてはならなくなるのでノードの特定に 繋がったりしそう。 完全に書き換える必要はない。単に、キーファイルが「それっぽい」だけでいいんだから。 せっかくRSAで検索送信者保護をしても間に入られたら意味ないなとふと思っただけだけ。 要求の転送で隠せるからある程度はいいけど、Winnyと同程度になっちゃうな。 536 名前：login:Penguin mailto:sage [2005/07/21(木) 03:05:45 ID:iQmD7UoW] データ本体のキャッシュの寿命の方はどうなってんの？ 完全なるクラスタになっていないかぎり、キャッシュ中のデータのほとんどが要、不要がわからないデータなわけだろ？ 要不要が即わかるほどキーファイルが流通するネットワークなら、 わざわざデータファイルのメタデータを隠蔽する意味が不明だし。 転送機能なんてほぼ意味ないよ。 となりがキャッシュをはじめから持ってるのと、いまからキャッシュにし始めるということと、どう違うわけ？クラスタ化されていない状態なら、無駄なキャッシュが増えるだけ。 いかれたパケットを送出するのに、root権限が必要なのだが、それはどうでもいいの？ っつーか、ノード数、ファイルサイズ、ファイル数、各ノードのキャッシュ容量とかどの程度のものを考えてるのかね。 537 名前：login:Penguin mailto:sage [2005/07/21(木) 03:20:49 ID:z2CP8IVj] >>531 A->B->Cのポートフォワードがおこっているということは、CがBに依頼したということでOK？ この状況で、B->Cのポートフォワードが悪用されたらBはインターネット的に責任をまぬかれるのか、 ということを心配したんだけど。 Cに依頼されたので、Cが落とされるようなパケットが転送されたとしても、依頼したCが悪いんです。 で問題ないか。 もしBが悪意のノードで暇人で、来たパケットを転送する前にごにょごにょ書き換えて送ったとしても Cは依頼する前にBの悪意を見抜けなかったから泣いて下さい、でシステム的にはOKか。 パケット転送はファイルの転送のみに使用して、コネクションを管理するポートには使わなければ 致命的にはならないね。 538 名前：login:Penguin mailto:sage [2005/07/21(木) 13:39:18 ID:+geUQqPb] (´-`).｡ｏO(今度こそモノになるかな） 539 名前：login:Penguin mailto:sage [2005/07/21(木) 14:28:00 ID:RTcoM3Vh] ｌｉｎｕｘ普及のためにOOoに匹敵するプロジェクト 完成を期待します。 540 名前：login:Penguin mailto:sage [2005/07/22(金) 21:09:49 ID:ySzGffYS] ネタ切れか 541 名前：login:Penguin mailto:sage [2005/07/22(金) 21:11:58 ID:tBkDAb44] 誰か僕にネットワークプログラミングのやり方を教えてください。 542 名前：login:Penguin mailto:sage [2005/07/22(金) 23:31:16 ID:eHH1w66m] しばらく見ない間に随分賑やかになっとるなぁ 少し読んでみたのが実際に動き出した時、これがどの程度動くのか、わしにゃ分からん。 >>502 2-3)IP/ポート交換ワンタイム秘密鍵(RSA 128bit) 　　　　ファイル最後尾から、128bitが1-3)に対する秘密鍵になっている。　　　　 　　　　詳しくは、後述。 「ファイル最後尾」に意味はまったくない。 キーファイルの公開鍵でIPを暗号化して、暗号化ファイルの所有者だけに分かるように渡すんでしょ？ ファイルの先頭につけると秘密鍵だけを抜き取られてしまうと考えたんだと思うけど、 レジューム機能を実装させると、まったく意味がないような気するがどうなの? まぁ、批判は簡単なので暗号化ファイルを全部落とさないと、秘密鍵が分からない仕様を考えてみた。 要は、ハッシュコード生成を少し変え、秘密鍵に非常に軽量な暗号をかける。 543 名前：login:Penguin mailto:sage [2005/07/22(金) 23:34:12 ID:eHH1w66m] 2.暗号化ファイル（バイナリ形式） 　　2-1)ハッシュコード (変更) 　　　　2-4)をハッシュにかけた値(MD5) を、さらに2-3)を連結させて 　　　　再度、ハッシュにかけた値(MD5) 　　　　ノードにキャッシュされる度、随時上書きされる。 2-2)IP/ポート交換ワンタイム秘密鍵 ノードで毎回、計算される。 　　　　 　　　　計算方法は、2-4)をハッシュにかけた値(MD5)と2-3)の 　　　　XORをとった値が、IP/ポート交換ワンタイム秘密鍵となる。 　　　　2-4)をハッシュにかけた値(MD5)は、2-1)を生成する際に計算したものを 　　　　利用できるので、計算量としては大した事はない。 これは、ファイルとは直接関係ないトランザクションデータとして扱われる。 　　2-3)XOR_IP/ポート交換ワンタイム秘密鍵(RSA 128bit) (変更) 　　　　「ファイル先頭」から128bit。 　　　　単に、2-4)をハッシュにかけた値(MD5)とIP/ポート交換ワンタイム秘密鍵のXORをとった値。もう一度、2-4)をハッシュにかけた値(MD5)でXORをとると元に戻る。つまり、完全な2-4)がない限り2-3)から2-2)は分からないってコト。 　　　　非常に単純な方法だが、手強いはずだ(w 　　2-4)データフィールド 　　　　暗号化された、データが入っています。 ま、わしにゃ、こんな事ぐらいしか思い浮かばんが、ガンバっとくれい。 544 名前：login:Penguin mailto:sage [2005/07/23(土) 00:07:29 ID:vcii9dn+] 乗りかかった船なので、私的に、明かに的外れだと思われる質問に勝手に答えてみる。 >>537 >>513 　しかし、このままでは不正利用を招くので、ノードBには、TCPのPSHパケットと、UDPパケットは 　転送しないよう設定します。 要は、ノードBからは、TCPのコントロールパケットしか飛んで来ないわけだ。 つまり､ACKパケットを、RSTパケットに変えて送った所で、通信が切断されるだけ。 そんな事を、するだけであれば単に中継しなければいい(中継すると契約しといて実はしない)。 しかも、書き換えて攻撃するなど、ややこしい。セキュリティ的には直接攻撃されているのと 変わらん。やる意味がない。攻撃といっても、単に一方的にファイルを送りつけるだけのポートに できる事って何がある? さらにいえば、どちらかと言えば、悪意あるノードがノードBを踏み台に攻撃する方が 多いと考えられる。だから、上記の>>513のような一文が加えられているのだと思う。 あってるよね? > 425 つうか、今この質問に答えていて思ったのだが、レジュームの実装って難しいんじゃねぇのか? 545 名前：login:Penguin mailto:sage [2005/07/23(土) 11:32:29 ID:jtlytnMJ] 　　　　　　　　　　　　　　　　　　　　　　た 　　　　　　　　　　　　　　　　　　　　し 　　　　　　　　　　　　　　　　　　ま 　　　　　　　　　　　　　　　　り 　　　　　　　　　　　　　　い 　　　　　　　　　　　　ま 　　　　　　　　　　て 　　　　　　　　っ 　　　　　　が 　　　　上 　　り 盛 546 名前：425 mailto:sage [2005/07/24(日) 23:41:51 ID:hPPfaUHc] 私用PCが・・・クラッシュしちまった＿|￣|○ さらに、夏風邪をこじらして寝込んでしまった。 気を取り直していきましょう。 なんか、活気付いてきましたね。どんどん、意見交換して行きましょう(w ここで提示しているのは、単なる案ですから、ここをこういう風にした方がいい って意見は、特に大歓迎です。 >>534 　自己レスです。UDP hole punching について、私の中で勘違いがあったので、書き直しておきます。 　「UDP hole punching」は、IPマスカレード(NAPT)によって書き換えられた、送り元ポート番号,IPアドレスを 　親サーバ上で交換し合い、UDPで通信する仕組みです。上手いこと、システムを騙した通信で面白い。 　ですが、必ず、交換し合う親サーバが必要なのと、親サーバが十分信用できないとセキュリィティが守れません。 　あと、匿名性の概念もまったくありません。 　しかも、そのUDPパケットがFWで弾かれることが多いので、実質的に使える機会は非常に少なかったりします。 547 名前：425 mailto:sage [2005/07/24(日) 23:45:22 ID:hPPfaUHc] >>535 >中間者は、自分用のRSA鍵ペア(ポート用とファイル用)を作っておき、 　『鍵ペア』って、そう言う意味だったんですね。 　 　私自身は、1-4)とノードの関係は、現実世界で余ほど目に余る行動を取らない限り、 　バレる事はまずあり得ないと、考えています。 　仮にバレたところで、1-4)は、『情報の保障』をしている一文であって、 　ファイル提供者かどうかを、定めている一文ではありません。 548 名前：425 mailto:sage [2005/07/24(日) 23:46:38 ID:hPPfaUHc] >キーファイルの伝播の際に 1-3) 1-4)を自分用のものにすりかえて、1-2) 1-5)をあわせておく。 　「匿名性」や「セキュリティ」を犯す攻撃にはなりえないと考えられます。 　理由は以下の通り。 　1)暗号化ファイルが見つからない → 公開鍵の評価が下がる。 　　『1-3)IP/ポート交換ワンタイム公開鍵』を　入れ替えてしまうので、暗号化ファイルにある 　　『2-3)IP/ポート交換ワンタイム秘密鍵』で、復号不可能になる。 　　つまり、検索パケットを送ったノードに応答パケットを返せないので、暗号化ファイルが見つからない 　　よって、公開鍵の評価が下がる。　つまり、相当の信用を得ていない限り、直ぐに「信用できない公開鍵」 　　として学習され、攻撃ノードは、今後その鍵での攻撃は不可能になる。 　2)中間ノードのIP/ポート番号が分かった所で、「匿名性」は犯されない。 　　中間ノードが、一斉広報で検索をかける際、攻撃者に、そのパケットが届き、 　　自分が摩り替えた鍵の秘密鍵で復号して、IP/ポート番号が分かった所で、 　　中間ノードと思われるノードの「IP/ポート番号」が分かったに過ぎない。 　　さらに、1)の理由で、それが長い間続くわけではない。 　　中間ノードが分かった所で、長期間に及ぶ大規模な調査がない限り「匿名性」は犯されません。 549 名前：425 mailto:sage [2005/07/24(日) 23:49:53 ID:hPPfaUHc] >>536 >データ本体のキャッシュの寿命の方はどうなってんの？ 　静的関係のキャッシュに過ぎないので、寿命の概念はまったくありません。 　いつでもいい、好きな時に消していいし、消さなくてもいい。 ハードディスクの資源は有限なので、その辺は、適当に設定する。 >要不要が即わかるほどキーファイルが流通するネットワークなら、 >わざわざデータファイルのメタデータを隠蔽する意味が不明だし。 　キーファイルが、いくら流通した所で、要か不要かは、データファイルのメタデータ 　つまり、キーファイルの暗号化ハッシュコードを復号してみないと分からないと思ういますが? 　>>535のような、もう少し具体的な説明をしてもらえませんか? >となりがキャッシュをはじめから持ってるのと、いまからキャッシュにし始めるということと、 >どう違うわけ？ 　一応、当り前のことだと思って書きませんでしたが、プロキシ要求を受けたノードは 　とりあえず、自分のキャッシュを探し、あれば、それをそのまま返します。 　つまり、違いありません。 550 名前：425 mailto:sage [2005/07/24(日) 23:55:29 ID:hPPfaUHc] >クラスタ化されていない状態なら、無駄なキャッシュが増えるだけ。 　暗号化ファイルのレベルでは、クラスタ化はありませんが、キーファイルのレベルでは存在します。 　どう、言うことかといいますと、プロキシ要求は、3-1)で起こります。 　さらに、検索パケットは、3-1)のポートが開いている相手にのみ送るので、 　結果として、暗号化ファイルはキーファイルの通信によって、形成されたクラスタの周りを 　うろちょろするだけです。 　カッコよく言えば、暗号化ファイルは、キーファイルのクラスタを継承します。 　この辺はまた詳しく話します。 >いかれたパケットを送出するのに、root権限が必要なのだが、それはどうでもいいの？ 　その辺が、UNIX系の鬱陶しいところですよね。適当にエージェントを挟むなり、すれば 　root権限まで取られる事はないのかな。 　P2P専用として使うのなら、落ちたって大した事はない思っていたりする。 >っつーか、ノード数、ファイルサイズ、ファイル数、各ノードのキャッシュ容量とかどの程度のものを考えてるのかね。　 　ネックとなるのは、キーファイルの通信になります。この辺の仕様を、はっきり決めない事には、分かりません。 　現在分かっているのは、各ノードの暗号化ファイルのキャッシュ容量は、まったく自由です。 　Freenetを「公開鍵暗号方式」と例えるならば、HannyNetは、「ハイブリッド暗号方式」を徹底的に目指してみたい。 551 名前：login:Penguin mailto:sage [2005/07/25(月) 02:43:41 ID:HNMfL4hb] キーファイルをみても要不要かわからないってことは、 キーファイルにはファイル名もキーワードもはいってないってことか？ それじゃあ、どうやって検索とかクラスタ化するわけ？ どうにしろ、キャッシュされることを考えていないってのは全く持って意味不明。 流通の効率を全く考えてないって言ってるのと同等じゃないか。 552 名前：login:Penguin mailto:sage [2005/07/25(月) 15:52:46 ID:DS/oy6EW] HannyNet(仮)とやらは参加ノード全てがハイレベルクラッカーなわけ？ 相手のPCを攻撃しながらファイル共有でもしているのかｗ 膨大なクエリでネットワークが埋め尽くされ、キーロスト多発 マルチソースDLどころかレジュームすらまともにできずにゴミキャッシュが 増えるだけの予感 553 名前：login:Penguin mailto:sage [2005/07/26(火) 07:56:10 ID:LfvsKzx0] 横レスですが >>551 キーファイルを見ても要不要がわからない、というのは、 実体のファイルを落とすまで本当のファイルとしては何かわからないというのと同義でしょう。 WinnyでもWebでも本質的には同じことで、codecがないから再生できないっていう状況も あるから、ネットワークのシステム自体が判定することは無理でしょう。 で、この仕様だと自然言語からキーファイルをFreenet的に検索するみたいなんで （自然言語→キーファイルは暗号化されていない）クラスタ化は可能かと。 キーファイルの流通に関しては結構やばそうな感じはするけど。 WinnyでもキーにTTLみたいなのを持たせて、あんまりクラスタ距離的に遠くまでは キーが流通しにくくしてダウンロード枠を確保してたみたいだけど。 >>548 どんな感じのキー流通になるかはあまり言及がないのであれだけど。 535攻撃は、キーファイルの配布速度と範囲によって有効だとは思う。 ｢信頼できる配布公開鍵(1-5)｣の情報が伝わらない(基本的には自分で試してみるしかない) わけで、ダウンロード枠待ちor失敗と、攻撃を受けていること、をすぐには見分けられないかも。 中間者がIPアドレスを知ったところで、Winnyと同程度までしか匿名性は落ちないけど いろいろしてる割にしょぼくなるな…と思ってしまった。 ちょっとしたダウンロード妨害の嫌がらせ攻撃としても有効だと思うし。 554 名前：login:Penguin [2005/07/26(火) 19:00:18 ID:8pmsTF99] テスターやりますよ。期待age 555 名前：425 mailto:sage [2005/07/27(水) 00:54:52 ID:if8zYisn] レスが追いつかないので、横レス大歓迎です。 >>542-543 　レジュームのことを、すっかり忘れていました。この暗号(?)は使えそうですね。 　非常に単純ですけど、強度は十分だと思います。 　最も手っ取り早いのは、検索パケットに「先頭からバイト数」(*)の情報を加えて応答パケットに、 　「ファイル長(バイト)」から(*)の差を載せて送るようにする方法でしょうね。 　検索パケット自体は、IP/ポート番号などを含め、128bitまでの情報を載せることができますから、 　IPアドレス + ポート番号 = 48bitなので、十分余裕はあります。 >>544 　言葉に若干トゲがありますが、大体そう言うことです(笑　 　Aの通信が、Bによって書き換えられ、Cを攻撃したのであれば、 　Cは、Bに直接攻撃されたのと変わりません。 　つまり、Bの攻撃によってCがクラックされた場合、Cのセキュリティが甘かっただけ。 　Bが攻撃者である事も分かります(クラック対策は比較的容易)。 　むしろ、Aの通信に悪意があり、Bを中継し、Cを攻撃した場合の方が問題。 　そのため、Bは、転送するポートに送られたUDPおよびPSHパケットを排除します。 556 名前：425 mailto:sage [2005/07/27(水) 01:05:00 ID:if8zYisn] >>551 　>>553を参照してください。 　キャッシュされたファイルがあるノードは、検索パケットに対して応答するので、 　無駄にはならない。 　ただし、暗号化ファイルは、ある程度キーファイル上のクラスタをウロウロする事は 　予測できますが、実際問題としてモデルを組まないと正確な事はわからない。 >>552 　単に、どんな攻撃が存在するかを適当に言いまくっているだけ。実際には、 　純粋(?)にクラックが目的のクラッカーは、タダのPCに魅力は感じないので、 　まず来ないでしょう。 　 　検索パケットの最大余命なども決めなければ、帯域を圧迫する恐れあるので 　モデルを組んで考えなければならない。 　プロキシを使ったマルチソースDL(ファイルの分割化が必要)は仕様として考えていませんが、使わないのであれば、 　クライアント側の仕様を適当に変えるだけで、マルチソースDLは可能です。 　プロキシ使わなくても、UP側はいつでも匿名ですし、Down側もある程度の匿名性も維持できると思います。 557 名前：425 mailto:sage [2005/07/27(水) 01:06:33 ID:if8zYisn] >>553 　>535攻撃は、キーファイルの配布速度と範囲によって有効だとは思う。 　 　確かに言える。しかし、攻撃者がキーファイルを書き換えて攻撃しようとすると、そのキーファイルは 　『人気のあるキーファイル』であると予測される物でないと効果は期待できない。 　しかし、『人気のあるキーファイル』であると予測される物であれば、高い確率でかなりの量が 　流通しているはずです。そのような中で、『書き換えられたキーファイル』が広く流通するとは、 　考えにくい。よって、被害を受けるのは極僅か。しかも、匿名性を犯すものではない。 　逆に、『人気のないキーファイル』であると予測される物であっても、今度は検索クエリが自分の 　場所に届く保障はない。 　さらに、同一ノードに関しては、公開鍵の評価が下がっていくので、その公開鍵を使った攻撃は 　無意味な物になっていきます。 　つまり、攻撃として手間がかかる割に小規模な攻撃しか出来ない。 　>中間者がIPアドレスを知ったところで、Winnyと同程度までしか匿名性は落ちないけど 　>いろいろしてる割にしょぼくなるな…と思ってしまった。 　例えが悪いと思いますが、懲役10,000年の囚人が司法取引で懲役100年になったとします。 　たしかに、99,000年も刑期が短くなったわけですが、実際問題として大して変わりません。 　その程度だと、考えてもらっていいと思います。　 558 名前：login:Penguin mailto:sage [2005/07/27(水) 01:24:16 ID:AFPD/rL/] ttp://homepage3.nifty.com/toremoro/p2p/p2p.html ここは読んでみたか？ 559 名前：login:Penguin mailto:sage [2005/07/27(水) 08:43:34 ID:sGzAtD+q] >>557 Winnyではクローズドだったから特には問題にならなかったけど、 キーファイルの改竄は、結構システムとしてやばめの攻撃だと考えている。 チェックサムとか署名でのシステム的な保護をするのはもちろんだけど、 キーファイルというものはリンクであるわけだから、有効なキーファイルかどうかは 実際落として見ないとわからないわけだ。 (スレ立てするときにテンプレの関連スレが有効かどうかを調べるみたいに) 末端ノードでは、自分のチェックした結果と、（もしするなら）伝播してくる信頼度の噂 によって、キーの有効度をテストしなくてはならない。 攻撃側は、いくらでも評価0の公開鍵を作ることができる。 正規配布ノードの公開鍵の評価を上げるシステムか、攻撃者公開鍵の評価を下げる システムが必要となるけども、この評価伝播システムは、それ自体が攻撃対象となってしまう。 入れないというのもひとつの手だとは思うけど(自分以外みんな敵)、 PGPみたいに信頼のネットワークを導入するのもありかなとは思う。 キーの伝播にどんなシステムが適当かわからないし、システムによるとは思うけど、 攻撃の手間のわりに、結構被害がでかいと私は思っている。 Winnyのキー伝播を仮定すると、"ファイルの公開者トリップを書き換えて遊ぶ"というのが 一時流行ったけど、あれはかなりな効果範囲だった。 IPアドレス収集までいかなくとも、ゴミキーが混ざるだけでも結構検索に支障が出ると思うし。 560 名前：login:Penguin mailto:sage [2005/07/27(水) 09:00:00 ID:sGzAtD+q] >>558 見てみました。まとまってますね。 425プロトコルは、基本的には多段プロクシに分類されるのかな。 これみて思い出したけど、Winnyで課金可能性についてでてましたけど、 このシステムでは実装可能ですかね。 当時、ぼろくそに言われてましたが、可能かどうかだけでも検討しておいた方が なにかと良いかと思います。 結局のところ、"監視することができない"というシステムにするなら以前から言われる ｢投げ銭システム｣しかないと思います。 オープンソースシステムでは、不正ノード防止のための工夫が必要になると思いますが この防止には、結局他ノードの目というのが必要となってくると思います。 例えば、転送量監視だとか、データの損傷(署名が一致するか)だとか、ゴミキーを送ってこないかとか。 そういったシステムを流用して、間接的な監視というものが実現できれば、 PureP2Pでも、課金ができるかもとか考えたりしたんですが、いいシステムは思いついてません… 今のがっちがちなインターネットの課金システムほどは確実には取れないと思いますが、 ちゃんと投げ銭できれば、現状よか使い勝手よく少しは取れるになるのではと思ったり。 561 名前：425 mailto:sage [2005/07/27(水) 20:18:17 ID:pqX40aYh] 人大杉で読めないよ。 しょうがないので携帯からアクセス。 >>558 　P2Pの基本と言っても、結局TCP/IPの基本に他ならないと思います。 >>559 　実装されるようになると、エンドユーザからは、キーファイルや暗号化ファイルを、 　あまり意識する必要がないような、インターフェ―スになると考えられます。 　つまり、あるキーワード入れると、全自動であるキーワードに引っかかるキーファイルが 　全部落とされてきて、暗号化ファイルのダウンロードも同時進行で行う。 　Winnyの基本である『待ち』ですね。待ってれば、落とされます。 　その中で、公開鍵の集計を取っていけば、信用性にかける公開鍵はふるいに掛けられます。 　落としてきたキーファイルの中にゴミキー30%混じっていた所で、検索にちょっと時間がかかるだけで 　信用性にかける公開鍵は、次々とふるいに掛けられるので検索速度は向上していきます。 562 名前：425 mailto:sage [2005/07/27(水) 20:27:50 ID:hYL+POH6] 続き・・・ 　逆に、攻撃者が全自動でゴミキーを作っていたとしましょう。 　信用性にかける公開鍵は、次々とふるいに掛けられるので、攻撃するには新たに公開鍵を 　作ってやる必要があります。 　さて、ここで問題です。 　攻撃者が、RSA2048bitの鍵ペアを作る時間と、探索者が『信用性にかける公開鍵』を 　見つける時間は、どちらの方が短いでしょうか? 　また、どちらの方のマシンが先に悲鳴を上げるでしょうか?(w 　どんな攻撃を仕掛けてきても、「RSA2048bit」という馬鹿みたいに長い鍵のせいで、 　長期戦は出来ず、超短期決戦になります。短期決戦では、『匿名性』は崩れる事は 　ありません。 563 名前：425 mailto:sage [2005/07/27(水) 20:30:06 ID:hYL+POH6] >>560 　>425プロトコルは、基本的には多段プロクシに分類されるのかな。 　基本が、WinnyとFreeNetですからそうなりますね。 　暗号化ファイルの検索が帯域を圧迫する恐れがあるので、 　そのあたりもう少し考えなけれななりません。 564 名前：login:Penguin mailto:sage [2005/07/27(水) 23:26:59 ID:IJEnt68s] 短期決戦？まさか。 暗号化ファイルが得られるまでキーの妥当性なんか判別できないんだろ。 しかも、人間が判別するわけだろ。 何が先に悲鳴をあげるでしょうか(www 565 名前：login:Penguin mailto:sage [2005/07/28(木) 02:29:02 ID:fAaYvFoP] >暗号化ファイルが得られるまでキーの妥当性なんか判別できないんだろ。 　少なくとも､明らかに「暗号化ファイル」が存在しないものは 　システムで見つける事は可能だと思うが? 　>>535に対する回答としては十分でないか？ 566 名前：login:Penguin mailto:sage [2005/07/28(木) 08:07:59 ID:eeVn6bw9] >>565 明らかに存在しないのか、単にレアものなのかの区別はどうする？ (キーの配布拡散方針にもよるが)暗号化本体ファイル(2)を持ってるノードがダウンして キーだけ出回っている状況とどう見分けるのかってこと。 >>562 1000〜のオーダーで順次回されたら、攻撃者鍵と初回ダウンロードな鍵とを 見分けられないのでは。(各ノードはそんなにたくさん鍵を覚えておくのか) ちなみに以前某所で使った、俺様実装なRSAプログラムでは2048bit鍵生成に1500msでした。 真面目に(攻撃されないように配慮して)鍵を作るのには時間がかかるけど、 それなりにチューンされた多倍長ルーチンを持っていれば 1024bit程度の素数かどうかチェックは秒行くか行かないかな速さでできます。 (´-`).｡oO(自分でしこしこ組んだのより、gmpというルーチンは10倍以上速かった…) 567 名前：login:Penguin mailto:sage [2005/07/28(木) 14:40:26 ID:d4j3xM1r] 前から出てるけど、暗号化ファイルと無関係なキーワード並べたキーファイルをばらまく攻撃ができるよ。 公開鍵生成しながら、適当に検索かけて、流れてくるキーファイル受信しとく。 検索が来たら、受信したキーファイルの 1-1) を一致するキーワードに書き換えて、ついでにランダムなキーワードも追加。 1-4) を生成しといた鍵に差し換えて、 1-5) の署名をして、検索した人に返信すればいい。 検索した人は、無関係な経路から無関係な暗号化ファイルを受信することになる。 もちろん、復号して確認するまで、無関係な暗号化ファイルかどうかはわからない。 568 名前：login:Penguin mailto:sage [2005/07/28(木) 18:25:16 ID:oqKZ/QOz] >>566 最低でも15秒はかかると思っていましたが、速いモノですね。 確かに、鍵を作るだけであれば、200個の素数から1090組の 鍵ペアが出来ちゃうんですよね(^^; いよいよ、公開鍵を元に不正なキーファイルをノード単体で、 探すのは困難になってきたわけですか。 その辺は、前々からちょっと思っていたのですが、「信用できる公開鍵の情報」を 共有してしまえば、「信用性のない公開鍵」を排除できると思います。 自分が分かってる「信用できる公開鍵」の書いたテキストを、キーファイルと 暗号化ファイルにエンコードして公開するだけ。 しかし、そんな親切な人いないので、システム側で支援すべき。 まぁ、データ圧縮や不可逆性の点から考えても「信用できる公開鍵」の情報は、検索時に利用される (ますよね？)公開鍵のハッシュコードをだけを書いた方がいいのかもしれない。 無事、ファイルが公開できたとしても、今度は、「信用できる公開鍵の情報」のキーファイルの 「公開鍵」が「信用できる公開鍵」なのかという問題が、起こってきたり、来なかったり。 まさに、「もし、この島の人間は皆、ウソツキなので気をつけなされ」状態。 でも、不正なノードもある程度ネットワークが大きくなければ出て来ないでしょうから、 その間に、いかに信頼関係を気付いていくかが問題なんでしょうね。 どちらかと言うと、ソーシャルネットワーク見ないなもんなのかな。 569 名前：login:Penguin mailto:sage [2005/07/29(金) 05:00:12 ID:LUTJPErB] 議論がキーの信用問題になってるけど、他にも弱点を指摘よろです。 >>568 キーファイルの有効性については、1-4)1-5)にある公開鍵による署名をよりどころにする という認識でok? ゴミファイルor捏造であるかどうかを含めて、公開鍵の評価に反映させる、と。 極論すれば、｢信頼のない公開鍵で認証されたキーファイルは破棄する｣とかいうシステムですな。 となると、攻撃対象は"公開鍵の信用性の伝播"に移ると思うんですが、耐性はあるかな。 外部からファイルを投入してくれる「職人さん」というのがあるけど、ファイルの有効性を確かめて 信頼情報を流してくれる"情報職人"というのができればいいけど。 信頼情報の署名を含めて、PGPでの信頼の輪みたいに共有していくシステムがいるね。 ネットワークに参加する際、一番初めの「信頼できる公開鍵」を何にするかという問題もあるな。 公開鍵の信頼の輪が、意見の相違によっていくつかに分かれたりもするかも。 信頼の輪にクラスタ化がいるのかもね。 570 名前：login:Penguin mailto:sage [2005/07/29(金) 05:04:53 ID:LUTJPErB] 情報屋は大変かも。一度でも間違えた評価をするとみんなから評価してもらえなくなったりとか。 評価の伝播は、＋〜0だけでマイナスは伝播しないようにしたほうがいいのかな。 それとも、マイナスだけ流した方がいいのかな。 どっちが攻撃に対して強いのかな。 571 名前：425 mailto:sage [2005/08/03(水) 12:00:36 ID:dOb0lEGI] 振替休日万歳！ ちと、今の仕様だと完全にDMZに置かないと話にならないので、 もう少し安易な物を考えている。 winny上でwinnyする仕様(winny over winny?) 　現在同様、自分のキャッシュに入ってる内容は、まったく 分からないし、中継されるファイルの内容も選べないが、 上手くいくとWinnyより早くダウンロードが始まる。 (言うだけはタダ) 公開鍵やキーファイルについての議論がありますが、 これは、既にWinnyでも実装済みの機能だったりします。 キーファイルは、winnyで言う所のキー(ファイル情報) 公開鍵は、winnyで言う所のトリップですね。 ただし、winnyのキーは、暗号化ファイルのインデックスで あるだけなので、暗号化ファイルからインデックスを逆に 検索を掛けれるので、winnyの暗号化ファイルは可逆で あります。 そこで、暗号化を不可逆にして、暗号化ファイルからインデックスの 逆参照を不可能にしようと思ったのが、そもそもの始まりです。 572 名前：425 mailto:sage [2005/08/03(水) 12:15:10 ID:4RkUfwZp] それと､匿名性以前の問題でWinnyでは、コネクションの確立 方法は、β1.0から全て共通です。 つまり、どんなP2Pソフトでもコネクション接続要求の パケットを止められてしまうと何処とも接続できない。 コントロールポートをUDPに限定すれば、UDP53番ポートを使うとか、RTPヘッダをつけるとか、いくつか打開策はあり。 573 名前：login:Penguin mailto:sage [2005/08/03(水) 18:13:41 ID:vcqACEF4] >>572 パケットを蹴られないようにするだけなら、HTTPリクエストに偽装するとか方法はあると思う。 (流石にWeb閲覧を全面的に蹴るプロバイダはいないだろうし) パケットが通るかどうかまで心配するとなると、それこそインターネットの再発明になるから 実装する気にもなんないんだけど。 Winnyのネゴは結構正直にやりすぎな気はするんである程度の偽装は必要かもしれないけど 細かいところに凝りすぎて、全体を見失ないつつある気がする。 「通信している内容は単独復号できない」 「通信をしているのはノードの意思ではない場合がある」 これだけで、多段プロクシとしての匿名性は得られてるんじゃないかな。 574 名前：login:Penguin mailto:sage [2005/08/03(水) 20:33:33 ID:huf+rSCg] 通信がノードの意思でなくとも警察が要求すれば ログの提出しなきゃならないってことはないの？ 575 名前：425 mailto:sage [2005/08/03(水) 21:13:48 ID:bxsn0g1D] パケットの量は、80番(HTTP)より53番(DNS)の方が多かったりする。 あと、サーバ動かしていたら、そのポートつかえません。 well-knownポート使った偽装は、明らかな偽装なので、面白みに 欠けるのでRTPヘッダを使った方が面白いかもしれません。 リアルタイム通信のパケットを時間をかけて調べる事は出来ません からね(w 576 名前：login:Penguin mailto:sage [2005/08/03(水) 22:47:17 ID:2/5EZX4h] ログ以前に、中継してるだけで限りなく黒に近い。特にwinnyみたいに99%違法流通してるようなところでは。 577 名前：login:Penguin mailto:sage [2005/08/03(水) 23:24:14 ID:huf+rSCg] どうせユーザ数が多くないと話にならないだろうし、だったら 2ch的なものと混ぜてしまえばいい。 2chブラウザより使い勝手を良くして、2chやその他bbsのログを 一本化して共有、●なくても読み書き可能にすれば2chは用済み、 2chのユーザ+nyのユーザを乗っ取れば膨大な掲示板トラフィックと 区別が付かなくなる。 578 名前：425 mailto:sage [2005/08/04(木) 01:10:23 ID:WsgB/OyK] >>576 >中継してるだけで限りなく黒に近い。 と言うか、黒なファイルが中継されるであろうクラスタに 属している事自体に法的問題があると思われる。 つまり、winnyの暗号化ファイルが可逆である事がそもそもの発端。 中継動作しているものに暗号化ファイルが何であるか不明にすれば いいだけ。 >577 　>どうせユーザ数が多くないと話にならないだろうし 　ユーザが少なければ、逆に表沙汰にならないので 　　逆に問題ない。 　1024以下はroot権限ないと起動できないから、その辺が鬱陶しい。 　Xenと併用するのであれば、問題ないが面倒。 　 RTPヘッダを使うと、リアルタイム通信として扱われるので、 　下手に、通信のタイミングをずらすような処理が出来ないのが 　ポイント(w 　あとは、適当にRTPヘッダを使う大義名分を考えればいいか・・・ 579 名前：login:Penguin mailto:sage [2005/08/04(木) 01:38:50 ID:iT6MgWDt] ばかじゃねーの。もし、winnyのキャッシュがキーなしで復号できなくても、黒は黒だろ。 winnyのネットワーク自体が真っ黒なんだから。 何が問題ないんだか。 580 名前：login:Penguin mailto:sage [2005/08/04(木) 01:48:24 ID:CWTMyEJZ] >>579 うｐろだの管理人も真っ黒になってしまいますね 581 名前：login:Penguin mailto:sage [2005/08/04(木) 08:47:47 ID:mCeiRwwd] 当然でしょう 582 名前：login:Penguin mailto:sage [2005/08/04(木) 09:02:27 ID:lKwo9ozd] 復号できないのに黒だとわかる>>579ってすごいですね。 でも証明できないんじゃ意味がないですよね。 583 名前：login:Penguin mailto:sage [2005/08/07(日) 23:49:45 ID:MAErsDxd] けんか腰の奴と一緒になってけんか腰で議論する必要はないない 584 名前：login:Penguin mailto:sage [2005/08/08(月) 03:26:21 ID:GElm0bvw] まだですか。 bitなんたらで洋物エロ動画落としてるんだけど、全然速度でねぇしjavaのazura何とか すげぇメモリ食うからやだし。 そもそもそういう用途に使うもんじゃないから匿名性なんてまったくないし。繋がってる相手丸見えだもんよ。 585 名前：login:Penguin mailto:sage [2005/08/12(金) 16:49:10 ID:++zxKhYc] ｗｉｎｎｙて 1　匿名性 2　分配方式 の2点が特徴に思いますが 2のみだけでもオープンソースでできれば 後は勝手に1を満たすよう誰かが進化させてしまうんじゃないでしょうか 誰か匿名性の無い分配式共有ソフトをつくってくれませんかね　（厨房より） 586 名前：＿ mailto:sage [2005/08/15(月) 00:39:47 ID:kuEK/e6W] つうか、Winnyのソースって出回ってるだろ? ある種のオープンソースでねーか? 587 名前：login:Penguin mailto:sage [2005/08/15(月) 06:24:45 ID:WYCWTctv] >>586 UpとDownの著しい不均衡とか、キーがちっとも広がらないとかいう問題は、 クローズドだからこその解決法でなんとかしてたわけで。 もし、全盛期に改造ビルトが流行ってたらネットワークは維持できてなかったと思う。 v4キーの書き換え(キーハッシュの衝突の脆弱性)でも一時やばかったわけだし。 そういうとこを含めて、公開しても大丈夫なシステムが組めればいいなと >>585 BitTorrentじゃないの、それって。 588 名前：login:Penguin mailto:sage [2005/08/28(日) 21:06:16 ID:jFvBDF3F] よくよく考えてみると、47氏はwinnyを開発した事による 著作権幇助の疑いで捕まったわけですよね？ オープンソースで、バイナリではなく、ソフトをソース配布すれば、 技術のない房は弾けるし、「表現の自由」によって「憲法」で 保護されると思うのだがどうよ。 ソースはCのような高級言語でなくても、アセンブリでも問題ないと思われ。 47氏も、アセンブリでソース配布すれば、めんどくさい裁判を受けなくて住んだかも? 589 名前：login:Penguin mailto:sage [2005/08/29(月) 12:10:02 ID:8UYsqZTy] >>588 ひょっとしてそれはギャグで（ｒｙ 590 名前：login:Penguin [2005/08/29(月) 15:48:03 ID:Lic1bBnN] *+*++*+/.,/.,/.,/.,//,/:;*+*+*+*+ ＿｜￣｜○ *+*+*+*+・。、・。、・。、＊＋＊＋？＜？＋ ：；：?。*；+*>*＞？＜＞？？＜＞＊＋・。、・。、＊＋ 591 名前：login:Penguin mailto:sage [2005/08/30(火) 15:57:40 ID:4Ij1IBiF] decss? 592 名前：login:Penguin mailto:sage [2005/09/04(日) 01:44:20 ID:hmo/M5vH] 所 詮 パ ク リ 593 名前：login:Penguin mailto:sage [2005/09/04(日) 14:39:29 ID:pXpKd7Rm] そ れ 以 前 の 問 題 だ と 思 う が 594 名前：login:Penguin mailto:sage [2005/09/20(火) 13:51:25 ID:PscRxDnC] いざ作ってみるとなかなか難しいものだな。 595 名前：login:Penguin mailto:sage [2005/09/22(木) 05:05:33 ID:jWL/+1Tx] 製作者ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !! (´-`).｡oO(というか真面目にむずいよな） 596 名前：login:Penguin mailto:sage [2005/09/22(木) 19:33:00 ID:hK6hjCOG] > オープンソースで、バイナリではなく、ソフトをソース配布すれば、 > 技術のない房は弾けるし、 勝手にコンパイルして配布する人や、まとめサイトを作ってくれる人に 関してはどう対処する？ > 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。 憲法をどう解釈するかに関しては、裁判所でどうぞ。 597 名前：login:Penguin mailto:sage [2005/09/24(土) 15:57:21 ID:on+fKY/Q] ○学生の出てくるエロ漫画を描いても、表現の自由で保護され･･･たっけ？ 598 名前：login:Penguin mailto:sage [2005/09/24(土) 16:05:18 ID:uOc/XLUk] >>597 宗教ならおｋじゃなかったか？ 599 名前：login:Penguin [2005/09/25(日) 01:33:10 ID:/r0bHCUi] 47氏の本が出版されるらしいね。Linny開発に弾みがつくといいな。 600 名前：login:Penguin mailto:sage [2005/09/28(水) 17:26:52 ID:Ej2805fD] その本をスキャンしたやつをlinnyに流そうぜ 601 名前：login:Penguin mailto:sage [2005/09/29(木) 22:05:37 ID:BIai3mBJ] > 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。 要は、「爆弾の作り方」は書いても言いが、「爆弾を作ってはいけない」 ってことだな。バイナリで流してる奴がいたら、そいつが捕まって、 はい、オシマイってわけ？人生そんな上手くはいかないよ。 602 名前：login:Penguin mailto:sage [2005/09/30(金) 02:55:59 ID:G/RjxJmT] 作り方と作ることを、バイナリとソースの対比で言い出したら、 バイナリでもOS上で実行しない限り走らな(ry とかになってくるし。 アイデアは良くて、アルゴリズムはダメでとか、 アルゴリズムはいいけど、走るソースはダメだとか。 結局、何を配布したとしても、最終的に自分の意志での実行コマンドの発行が必要である以上 ウイルスとかの自動実行系の配布とは一線を画するとは思うんだが。 603 名前：login:Penguin mailto:sage [2005/09/30(金) 13:26:30 ID:U0TBEIz/] 京都府警はおろか司法の中の人たちも、この手の新しいテクノロズィに関する お話になると、どうも理解があやしい。 挙句、既成概念の外からやって来た”異物”に対して、理論的根拠なきまま 攻撃的に排除する方向で対応している。 社会システムの理性であるべき司法も所詮、硬直化した官僚組織だ。 構造改革は行財政だけでなく、司法にも直接メスを入れる必要があるな。 604 名前：login:Penguin mailto:sage [2005/09/30(金) 13:29:14 ID:os075Rrp] >>603 藻前が何を熱く語ったところで、世の中変わらないから安心して妄想汁。 605 名前：login:Penguin mailto:sage [2005/09/30(金) 13:44:53 ID:U0TBEIz/] これはこれは。 素早い反応、乙であります。 606 名前：login:Penguin mailto:sage [2005/10/02(日) 02:27:49 ID:akB9j0NI] 603が一番理解があやしそうだが。 607 名前：login:Penguin mailto:sage [2005/10/02(日) 03:31:25 ID:XdmTWX16] >>603 既成の概念を破ることを悪いとは言わないが、 破ることによって新たに得られる物がまだ準備できない段階で、 むやみに破壊するってのもやばいでしょう。 異物が成功することのほうが少ないんだし、排除しようとする動きは当然かも。 608 名前：login:Penguin mailto:sage [2005/10/03(月) 22:23:47 ID:lHDFlLbA] > 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。 まぁ、未だに64kの低速回線でファイル共有自体には興味はないが、 これはあながち間違ってはいない。 と言うのは、Winnyによる著作権侵害の問題が社会問題にまで発展したの には、マスメディアの力によるものが大きい。それでも、マスメディアが 「表現の自由」に守られているからです。 かつて、「OPEN-SSL」の輸入が米国の法律上の関係で、認められない時期がありました。 しかし、何処かの頭のいい馬鹿が、ソースをプリントアウトして日本に持ち込みました。 その時代、電子データは「人が読めるもの」であっても「文書」には当たらなかったのですが、 プリントアウトして、尚且つソースは「人に読める」ので「文書」になります。 「文書」になった地点で「表現の自由」が認められ、晴れて輸入できたわけですね。 現在では、「電子データ」であっても、人が読めるものであれば「文書」になるので、 「表現の自由」が認められるワケですね。 あ、でも昔、コレと似たような問題として「偽造テレカ」の問題がありました。 当時の法律では、コレを「偽造」とするのには難しい物があり裁判所が、 ムリヤリこじつけて有罪にしてました。 興味がある方は調べてみてください。 609 名前：login:Penguin [2005/10/03(月) 22:34:53 ID:lHDFlLbA] 一応、関連分野だけど、どうでもいいネタを思い出した。 SQLインジェクション攻撃は、多くの場合、日本の法律では「不正アクセス」には なりません。 だって、名前を書く欄に人間が読める文字(SQL)を打ち込んだら、 「頼んでもいないのに」　「勝ってに」　「向こうから」 情報を送ってきますからね。 610 名前：login:Penguin mailto:sage [2005/10/04(火) 00:04:49 ID:3MN3X/VT] >> 609 勝手に送られてきた情報でも、悪用すれば損害賠償に発展するし 利益が伴えば横領だろうから、よい個はやらないように 611 名前：login:Penguin mailto:sage [2005/10/06(木) 20:54:13 ID:d52gi3Mh] 882 ：47 ◆KbtLZwerNc ：sage ：03/06/19 08:50 ID:AhStOI42 Winny作者ですが あれがクローズドシステムになっているのは、好きでそうしているわけではなく、 こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが 導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。 その際には現在のWinnyとの互換性はなくなると思いますが。 今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、 オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。 とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。 だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で オープンにできないのであればUNIX版ができることは無いと思います。 612 名前：login:Penguin [2005/10/06(木) 21:04:34 ID:Fgb6CUKR] 47氏に「こちらの設計能力不足によるもの」なんて言われても・・・ 613 名前：login:Penguin mailto:sage [2005/10/10(月) 14:04:07 ID:rLVx9fSs] 47氏の本を読んだ人、なんか言うことあったらどーぞ 614 名前：login:Penguin mailto:sage [2005/10/10(月) 18:21:40 ID:7ub5fEMT] ﾉｼ ・pthread使えよ ・コネクション開けすぎだろ ・DOM対策は黙殺かよ 615 名前：login:Penguin mailto:sage [2005/10/10(月) 23:20:57 ID:qNvmUTIs] >>614 つーかDOM対策の仕方が分かんないからオープンソースにできないんでしょ？ 616 名前：login:Penguin mailto:sage [2005/10/11(火) 01:45:25 ID:kh40LmyH] つうか、回線資源が豊富な時代のファイル交換ではない「ファイル共有」に、 『DOM対策』と言うのは、多発する自動販売機荒らしのためにガードマンを 雇うようなものだろう・・・放置で問題ないのでは？ あと、帯域制御ではなく、パケット優先制御にするって手もありそうだが実装が面倒だろうな。 617 名前：login:Penguin mailto:sage [2005/10/11(火) 10:11:42 ID:PfV9tu8k] >>614 Windows用のソフトでpthread使えと言う方がどうかと思うが 618 名前：login:Penguin mailto:sage [2005/10/13(木) 20:30:00 ID:aQX6KbtT] Linnyへの言及は無かったの？ 619 名前：login:Penguin mailto:sage [2005/10/16(日) 14:22:14 ID:Pzhwvu3/] 俺が47氏と対談してやろうか？ 確か東大教授だったか。 いやマジで。 620 名前：600 mailto:sage [2005/10/18(火) 18:32:18 ID:OVuRaYPv] 金子勇氏が『winnyの技術』PDF版の配布を開始 news19.2ch.net/test/read.cgi/news/1129625712/ 621 名前：login:Penguin mailto:sage [2005/10/19(水) 18:54:23 ID:wirADuqX] 47氏の逮捕が残念でならない。 あと、数年逮捕がなければ ｌｉｎｎｙは実現してたんじゃないかと それは、ｌｉｎｕｘの普及に弾みを付けたであったろうに 金子さん残念です。できそうにないっす（ノ＿・、） 622 名前：login:Penguin mailto:sage [2005/11/01(火) 18:58:39 ID:AD9WRUWi] www.2chlinux.org/index.php?Winny wine de winny これを使えばｌｉｎｎｙは不要なんだね 623 名前：login:Penguin mailto:sage [2005/11/06(日) 17:17:06 ID:Tn4QjnGn] 前スレくらいに、47氏が来てたきがする。 624 名前：login:Penguin mailto:sage [2005/11/06(日) 21:04:51 ID:XTX2yjfR] >>623 Linny開発プロジェクト pc.2ch.net/test/read.cgi/linux/1053087824/882 882 ：47 ◆KbtLZwerNc [sage] ：03/06/19 08:50 ID:AhStOI42 Winny作者ですが あれがクローズドシステムになっているのは、好きでそうしているわけではなく、 こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが 導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。 その際には現在のWinnyとの互換性はなくなると思いますが。 今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、 オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。 とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。 だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で オープンにできないのであればUNIX版ができることは無いと思います。 625 名前：login:Penguin [2005/12/16(金) 20:57:31 ID:Kqp2Iu7t] Project page not found 626 名前：login:Penguin [2005/12/16(金) 21:15:51 ID:xaaeI0JY] 掛け声ばかりで何もしないのが犬糞ｸｵﾘﾃｨ 627 名前：login:Penguin [2005/12/17(土) 07:19:10 ID:TnkcQday] Azureusでいいんじゃないかな？トラッカー不要だし、匿名でもできるんでしょ。 628 名前：login:Penguin mailto:sage [2006/03/12(日) 18:35:31 ID:pV0uMcQl] poenyとか作っちゃった人いるし。 629 名前：安倍 [2006/03/15(水) 22:18:54 ID:6/zNNY2A] ここも閉鎖してくださいね 630 名前：login:Penguin mailto:sage [2006/03/15(水) 23:04:18 ID:ZjUHtBRx] >>629 なにげにIDにNYはいってるな。 631 名前：login:Penguin mailto:sage [2006/04/08(土) 23:52:50 ID:1z63VHJc] お宝動画.mpg .sh* 632 名前：login:Penguin mailto:sage [2006/04/10(月) 17:24:40 ID:Qx/LpCHc] >>631 ./お宝動画.mpg.sh 633 名前：login:Penguin mailto:sage [2006/04/17(月) 02:23:40 ID:lVQElzvx] poenyのコードが出ているからLinuxに移植して、shareにも対応させてくれ。 634 名前：login:Penguin mailto:sage [2006/04/17(月) 04:51:08 ID:dIINE0d7] >>633 pyny ってのなら OS independent みたいだが。 pyny.sourceforge.net/ 635 名前：login:Penguin mailto:sage [2006/04/18(火) 00:34:17 ID:7qWnvAZT] いいね。まだ完成は遠そうだけども。 636 名前：login:Penguin mailto:sage [2006/04/19(水) 08:49:27 ID:fuiVWiVy] 何このスレ… ただ議論してるだけの口だけですか、ざっと見たところコードの一つも書かれてないしねぇ。 ダメだねこりゃ。 ま、ネタだからいっか！ 637 名前：login:Penguin mailto:sage [2006/04/19(水) 18:12:57 ID:aO8UYN14] オープンソースでもうまくいくアイデアが出てきてないのに コード書いてどうすんの？ 638 名前：login:Penguin mailto:sage [2006/04/19(水) 23:38:54 ID:iW2WqGmJ] この程度のはさらっと無視しようよ。 639 名前：login:Penguin mailto:sage [2006/04/20(木) 02:01:26 ID:PojcW3ph] >>638 真性の馬鹿かよ…お前。 今まで議論してきたんならそれをまとめ上げて設計を煮詰めることぐらいできるはずだろう？ しかもオープンソースでもうまくいくアイデアて…。 それよりも進める、進めるべき問題があるだろうに…所詮ここに居る人間は ただWinnyのLinux版が欲しいだけの、ただの無能なんだろうよ。 絶対に完成することは無いと断言する。 まぁそれでも馬鹿みたいにナーナー喚いてたいなら、そうしてればいいんじゃないの？ 640 名前：login:Penguin mailto:sage [2006/04/20(木) 11:45:35 ID:kn8mRmOs] 春だな。 641 名前：login:Penguin mailto:sage [2006/04/23(日) 16:24:21 ID:4/zRYzSe] 639がなんでそんなに必死なのかわからんな。 ﾏﾀｰﾘｦﾁの邪魔すんじゃねぇよｳﾞｫｹが。 642 名前：login:Penguin [2006/05/09(火) 21:58:56 ID:BY7OQNQc] んで、どこまで進んでるの？ 643 名前：login:Penguin mailto:sage [2006/05/09(火) 23:01:55 ID:+PKMm0aS] ネタスレ上げんな 644 名前：login:Penguin mailto:sage [2006/05/10(水) 00:28:44 ID:q5RoQNNY] オープンソースの必要なし、それに、匿名で、つくらないと警察がうるさいのでだめだろう。 645 名前：login:Penguin [2006/05/16(火) 18:02:37 ID:bb3cOoYb] 勇気あるやつはいないの？ 俺は形式的にやめとけと言っとくけど。 646 名前：login:Penguin mailto:sage [2006/05/17(水) 12:48:33 ID:pJkTeqZ7] 勇気は、あるけど、つくる技術がない。 つくれたらWinnyで匿名で流す。 647 名前：login:Penguin mailto:sage [2006/05/17(水) 12:53:25 ID:2TSMmOa8] 俺は勇気と技術はあるが、やる気がない。 大半の奴がそうだろ。やる気さえあれば全部ついてくる。 648 名前：login:Penguin mailto:sage [2006/05/17(水) 20:15:43 ID:/kiMxzMb] 俺はやる気がないから、技術がない。 大半の奴がそうだろ。やる気さえあれば全部ついてくる。 649 名前：login:Penguin mailto:sage [2006/05/18(木) 01:05:34 ID:6S1wN1WK] やる気があっても、技術はなかなか身につかないんだよ。 簡単にいうな。 650 名前：login:Penguin mailto:sage [2006/05/18(木) 09:22:16 ID:Z8fGq0bJ] 納期のある仕事じゃないだろ。身につくまでやるだけさ。 651 名前：login:Penguin mailto:sage [2006/05/19(金) 01:15:22 ID:TU/BQMI9] とりあえず、JAVAを勉強すればいいのか？ 652 名前：login:Penguin mailto:sage [2006/05/19(金) 03:08:09 ID:TU/BQMI9] perl　や　Javascriptでは、無理か？ 653 名前：login:Penguin mailto:sage [2006/05/19(金) 04:17:38 ID:aTw9MFAu] perl は POE でできるんじゃね？ Javascript って、常駐プロセスできるの？ 654 名前：login:Penguin [2006/05/21(日) 01:15:24 ID:BV3/rKWP] 最近のISPポート遮断も考慮に入れないとな… 655 名前：login:Penguin mailto:sage [2006/05/21(日) 02:14:01 ID:7NI4CdpF] 7743 でいいんじゃね？ 656 名前：login:Penguin mailto:sage [2006/05/22(月) 05:42:41 ID:wwhT7Auj] やっぱりperlじゃ無理だろ。 JAVAでつくることにして、JAVAでも勉強するか。 657 名前：login:Penguin [2006/06/11(日) 15:12:52 ID:j2Yz1QFx] DOM除外についてちょっと考えてみた 保証者認証機能 A:Bの保証済リストに入っていないとする A>>B データ要求 A<<B 保証者リスト要求 (必要な保証者数) A>>B 保証者リスト送信 *<<B 保証済認証要求 1. *>>B 保証者の一定量の該当なし A<<B 要求拒否 AはBを保証者リストから削除（任意） 2. C>>B 保証者該当 A<<B 要求受入 658 名前：妄想2 [2006/06/11(日) 15:15:13 ID:j2Yz1QFx] ・保証済みリストの追加は… 該当のノードから一定量のデータ供給があった場合 保証者認証にて保証済みと認定された場合…などなど ・保証無しノードについて 保証無しノードを一方的に拒否すると ノードがネットワークへ参入ができない 回避策としては保証済みと保証無しノードで 優先度(帯域制限とか)を変える ・仕様のバグ 保証者認証要求を何でもOKと返すノードが増えると全く意味なし 各ノード毎に優秀なデータベースが必要 トラフィック量が認証の通信だけでﾊﾝﾊﾟﾈｪ 仕様のバグあったら指摘よろしく やる気でたらそのうちコード書くんでよろしく 自分プログラミング初心者なんでよろしく 659 名前：login:Penguin mailto:sage [2006/06/14(水) 23:12:12 ID:3WQsyC6y] 初心者ならまず作ってみてそれが可能か確かめることだ 660 名前：login:Penguin mailto:sage [2006/06/15(木) 02:46:48 ID:ikJkVB7c] 理論的には不可能じゃない。 処理能力的に不可能。 661 名前：login:Penguin [2006/06/30(金) 12:45:51 ID:8rNwoRlz] Winny今日でオワリ＼(^o^)／ 662 名前：login:Penguin [2006/11/08(水) 13:31:51 ID:W7dud1LU] 進展あり 663 名前：login:Penguin [2006/12/31(日) 12:30:02 ID:VZWpvELQ] ttp://linny.sourceforge.jp/ 404出てるが。。 664 名前：login:Penguin [2007/01/12(金) 21:38:38 ID:5RZHoj7P] なんかすげぇｗｗｗ 665 名前：login:Penguin [2007/01/13(土) 05:29:57 ID:+PPdjV/T] このプロジェクト復活するのかな 666 名前：login:Penguin [2007/01/13(土) 07:58:59 ID:DaWyErcl] wine+winnypでいいじゃん 667 名前：login:Penguin mailto:sage [2007/01/13(土) 10:40:54 ID:BfnrT5+F] ひろゆきは嫌いだけど2chは好き。是非開発してほしい。 668 名前：login:Penguin mailto:sage [2007/01/13(土) 11:38:40 ID:+PPdjV/T] Linuxの爆発的普及のきっかけになるかも知れないのに・・・ 669 名前：login:Penguin [2007/01/13(土) 11:49:27 ID:TsrbH3i8] Linnyが普及すれば、掲示板もあるし、アップローダも付いてるし、Linux普及を盛り上げてWindowsのシェアを大幅に下げる祭りができるし、良いことずくめ。 670 名前：login:Penguin mailto:sage [2007/01/13(土) 12:36:05 ID:0o36Q73e] winny開発が有罪なんだからlinnyも・・・ 671 名前：login:Penguin mailto:sage [2007/01/13(土) 12:41:18 ID:TsrbH3i8] ばれなきゃ良いんだよ。 672 名前：login:Penguin mailto:sage [2007/01/13(土) 14:01:39 ID:iK5MOlrr] グリーンダヨ！ 673 名前：login:Penguin mailto:sage [2007/01/13(土) 20:52:42 ID:BfnrT5+F] P2P掲示板だけでいいから誰か作ってYO!!! 674 名前：login:Penguin mailto:sage [2007/01/13(土) 21:40:17 ID:TsrbH3i8] >>673 ほらよ shingetsu.info/index.ja 675 名前：login:Penguin mailto:sage [2007/03/27(火) 11:14:35 ID:5bVcjYXr] いまだにできないということは日本の ハッカー、LINUXER、２ｃｈねらーは レベルが低いということでよろしいか 676 名前：login:Penguin mailto:sage [2007/04/01(日) 10:21:45 ID:Ef2nx0n0] 日本人にハッカーなんていないでしょ。 せいぜいHP書き換えたりクレカ番号盗んだりするスクリプトキッズがいるだけで。 677 名前：login:Penguin mailto:sage [2007/04/01(日) 10:26:18 ID:liwrsMPf] ハッカーですって言う奴いるの？ 678 名前：login:Penguin mailto:sage [2007/04/01(日) 16:03:10 ID:WazxHIEt] 金子勇 679 名前：login:Penguin mailto:sage [2007/04/03(火) 04:56:44 ID:wNn/7D39] 何かスースーするね。 これ何？ ハッカー！！！！！ 680 名前：login:Penguin mailto:sage [2007/04/04(水) 13:37:57 ID:yYIflZC3] 荷物預けたいなぁ。 あ、あそこにあった。 ロッカー！！！！！ 681 名前：login:Penguin mailto:sage [2007/05/23(水) 19:50:11 ID:yn77ijmC] poenyをLinuxで使えたりはしないのかな？ 682 名前：login:Penguin [2007/07/27(金) 11:08:51 ID:ktyIqQnV] あれからいろいろあって・・・ もうこのプロジェクトのニーズもすっかりしぼんじゃったね。 683 名前：login:Penguin mailto:sage [2007/07/27(金) 13:00:08 ID:LeXmC4Lv] ニーズに応えようとするとロクな事にならん 684 名前：login:Penguin mailto:sage [2007/07/27(金) 23:49:08 ID:AgtN6pgh] 行動するやつがいねーから全然駄目ジャン 685 名前：login:Penguin mailto:sage [2007/07/28(土) 16:28:29 ID:SX3ABxnb] そりゃそうだよ 誰もが変なファイルを欲しがると思っちゃイカン 686 名前：名無しさん＠そうだ選挙に行こう [2007/07/29(日) 18:15:56 ID:lmuP9iVu] え！？ LinnyってWinnyでもう放流されてじゃん もうVer1.42だにょん 687 名前：login:Penguin mailto:sage [2007/07/29(日) 23:31:04 ID:3vNf8O1V0] 釣ろうったってそうはいかんざき 688 名前：login:Penguin mailto:sage [2007/08/14(火) 07:14:41 ID:dAO75AnG] limewireで十分 689 名前：login:Penguin mailto:sage [2007/11/10(土) 16:35:15 ID:e1dttwm1] Linny 1.43aがdebのパッケージであった 690 名前：login:Penguin [2007/11/10(土) 17:59:07 ID:x1O44yXp] どうでもいいけどwinnyの規格でwinnyのプロトコルとネットワークを利用して 「対抗する」とはどういうことだw

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef