[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 12/11 15:11 / Filesize : 237 KB / Number-of Response : 691
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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のアカウントを取得してください。

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ベースの高速な匿名性ファイル共有で、特にファイル提供者の
匿名性が非常に高い物を思いついたので、まとまり次第うpします。

(キーファイルと暗号化ファイルに分けるという点は変わりません。)

>>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]
で、何%までできた?。机上の空論もいいけど、コード書いて実装できなきゃ
意味ないぞw

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]
しびれを切らして愚痴りだした香具師がいるなw
机上の空論、大いに結構。



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]
    これで、要求ノードは、ファイルの存在場所を知る事ができます。匿名性はないに等しいのですが、これが基本となります。

    暗号化ファイルを探しなければ、余命を更新して、現在接続されている全てのノードに検索パケットを
    送信する(ただし、送信元ノードには送らない)

    余命をいくつ減らすかを乱数でランダムに決めますが、余命によって重み付けが変わってきます。

(この例は、適当で極端な例です)
    余命 1: 7割の確率で1減らす。3割の確率で減らさない。
余命 2: 5割の確率で1減らす。2割の確率で2減らす。3割の確率で減らさない。
    余命 3: 5:2:1:2 = 1減らす:2減らす:3減らす:減らさない
    余命 4: 4:2:2:1:1 = 1減らす:2減らす:3減らす:4減らす:減らさない
    余命 5: 4:2:2:1:1:0 = 1減らす:2減らす:3減らす:4減らす:5減らす:減らさない

検索パケットは、余命が0になった地点で消滅します。

検索パケットの余命は、第1回一斉広報は、「1」。第2回一斉広報は、「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パケットを転送。
    (以下省略)

    どうなっているかを図で説明すると、

    ノードB ------------------------------┐
↑            l
l            |
      l                 ↓
    ノードA <---------- 仮想カード ← ノード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から落としているようにしか見えない。

*ノードBは、「ノードC」と「ノードA」が通信している事は分かるが、「ノードC」が、
      「ノードA」に、『どういうファイル』を送っているかは、ノードBを中継しないので、
      『物理的』に、わからない。

      しかし、ノードAが「ファイル要求者」の場合、ノードCからは、モロで見えているので、
      完全な通信モデル図はこうなる。

               NATノード ----------------------------------┐
                 ↑                   l
                 l                   |
                 l                   ↓
      要求ノード === 中継ノード <---------- 仮想カード ← 提供ノード

つまり、最終的には、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]
(´-`).。oO(今度こそモノになるかな)

539 名前:login:Penguin mailto:sage [2005/07/21(木) 14:28:00 ID:RTcoM3Vh]
linux普及のために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を攻撃しながらファイル共有でもしているのかw
膨大なクエリでネットワークが埋め尽くされ、キーロスト多発
マルチソース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
うpろだの管理人も真っ黒になってしまいますね

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]
winnyて
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
ひょっとしてそれはギャグで(ry

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
宗教ならおkじゃなかったか?

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氏の逮捕が残念でならない。
あと、数年逮捕がなければ
linnyは実現してたんじゃないかと
それは、linuxの普及に弾みを付けたであったろうに
金子さん残念です。できそうにないっす(ノ_・、)

622 名前:login:Penguin mailto:sage [2005/11/01(火) 18:58:39 ID:AD9WRUWi]
www.2chlinux.org/index.php?Winny
wine de winny
これを使えばlinnyは不要なんだね


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]
なんかすげぇwww

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、2chねらーは
レベルが低いということでよろしいか

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) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<237KB

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