■ このスレッドは過去ログ倉庫に格納されています
Linny開発プロジェクト Part2
- 1 ：login:Penguin：03/06/22 19:40 ID:zhqumg4k.net
- 今までのP2Pファイル共有ソフトに負けない機能、手軽さ、匿名性を備えた
全く新しいWWWベースのファイル共有ソフトを作るプロジェクトです。
-------------------- 535 ◆HO0OFh2RXI 氏による最初の発言 --------------------
03/04/30 23:19
http://pc.2ch.net/test/read.cgi/linux/1024473956/535
> みんなでデーモンとして動くようなLinux版Winnyつくらない？
> デーモンとして動かなくてもコンソールで使えればいいです。
> どうでしょうか？自分は、Linux C(C++)プログラマーです。
前スレ
Linny開発プロジェクト
http://pc.2ch.net/test/read.cgi/linux/1053087824/
Project Page
http://linny.sourceforge.jp/
議論用Wiki
http://linny.sourceforge.jp/wiki/
※プロジェクト参加希望の方は535氏<burner@users.sourceforge.jp>まで連絡してください。
また、本格的に参加する場合はSourceForge.jpのアカウントを取得してください。
- 2 ：login:Penguin：03/06/22 19:40 ID:g9C0juo7.net
- （ ´,_ゝ｀）ﾌﾟｯ
- 3 ：login:Penguin：03/06/22 19:43 ID:9UhLFzGM.net
- 分かりやすく書くと
535氏を代表とするLinnyは47氏を代表とするWinnyに全面的に対抗する
ってことです
- 4 ：535 ◆HO0OFh2RXI ：03/06/22 19:45 ID:W9K0Zob1.net
- >>1
乙です。Project Pageのｽﾚのｱﾄﾞﾚｽ変えときます。
- 5 ：login:Penguin：03/06/22 19:47 ID:9UhLFzGM.net
- >>4
何故かWinnyのスレになってますね(^^;
貼り間違えたのかな？
- 6 ：535 ◆HO0OFh2RXI ：03/06/22 19:53 ID:W9K0Zob1.net
- >>5
aki様がこうしたのです。あと、信じていただけないと思いますが本人です。
次から新しいﾄﾘｯﾌﾟにします。
- 7 ：535 ◆HO0OFh2RXI ：03/06/22 19:56 ID:W9K0Zob1.net
- 更新しました。信じてもらえるでしょうか？
- 8 ：535 ◆HO0OFh2RXI ：03/06/22 19:57 ID:W9K0Zob1.net
- もっと、きれいなﾍﾟｰｼﾞが作れる人がいましたら登録お願いします。
- 9 ：login:Penguin：03/06/22 19:59 ID:qY1Cg6zb.net
- 535様でしたか、久し振りです。
>Winnyのオープンソース化を考えるスレ 現本スレ
ここがまだ間違ってますよ
- 10 ：login:Penguin：03/06/22 20:03 ID:W9K0Zob1.net
- >>9
訂正しました。指摘ありがとうございます。
よかったらｱｶｳﾝﾄ取ってﾒﾝﾊﾞｰになりませんか？
- 11 ：login:Penguin：03/06/22 20:04 ID:LAE0hWdI.net
- >Winnyのオープンソース化を考えるスレ
これは対抗スレであって関連スレじゃないですよ。
こっから案をパクったらLinnyを作る意味がないですし。
- 12 ：535 ◆HO0OFh2RXI ：03/06/22 21:01 ID:W9K0Zob1.net
- >>11
今から外します。
- 13 ：535 ◆HO0OFh2RXI ：03/06/22 21:05 ID:W9K0Zob1.net
- 外しました。
それではこの辺から本格的に議論に入りましょうか。
ってまた言い訳とかいわれるかもしれませんが明日から期末ﾃｽﾄなので
ずっと2chばっかりできない状態です。なるべく時間取りますが。
- 14 ：login:Penguin：03/06/22 21:10 ID:PRiwesXB.net
- 早く新しいトリップにしる！
- 15 ：login:Penguin：03/06/22 21:13 ID:W9K0Zob1.net
- >>14
新しいﾄﾘｯﾌﾟもつけますが、今の間は名無しでいいかなと思います。
- 16 ：535 ◆rllaU5stOw ：03/06/22 21:18 ID:W9K0Zob1.net
- ﾄﾘｯﾌﾟﾃｽﾄ
- 17 ：login:Penguin：03/06/22 21:36 ID:SJi7a5oq.net
- 本人ならここにトリップ書いといてよ。
http://sourceforge.jp/developer/diary.php?diary_user=5040
- 18 ：login:Penguin：03/06/22 21:40 ID:W9K0Zob1.net
- >>17
どうでしょうか？
- 19 ：login:Penguin：03/06/22 21:57 ID:SJi7a5oq.net
- >>18
OK
- 20 ：login:Penguin：03/06/22 21:58 ID:W9K0Zob1.net
- 以後、必要な時以外は匿名で逝きます。
- 21 ：aki：03/06/22 23:26 ID:HRNFS7wF.net
- （´-`）.｡oO(LinnyとオープンソースWinnyは結局別スレッドになるんですね。)
(´-`).｡oO(ちょっと先走ってました。申し訳ない。)
とりあえずループを避けるためにも前スレのまとめが最優先かな？
47氏がオープンソース化に触れたことで多少人も増えているようですし。
- 22 ：535 ◆rllaU5stOw ：03/06/23 00:18 ID:5Rd9hoSZ.net
- >>21
aki様
いつもご迷惑おかけしております、535です。
>>all
Winny全面対抗という考えの方もいるようですが、
個人的には対抗する必要はない気がします。
Winnyｽﾚ側でｵｰﾌﾟﾝｿｰｽでの完全なWinnyができたら
そのﾗｲｾﾝｽはGPLになると思うのでLinny側でそれを参考に相互に接続できた方がいいと思います。
その方が、ﾌｧｲﾙ数などは圧倒的に多くなりますしWindows版を考えなくていいようになります。
- 23 ：login:Penguin：03/06/23 00:28 ID:a26IWp8t.net
- >>22
Windows 版とか言ってる時点で、勉強不足と思われ。
- 24 ：login:Penguin：03/06/23 01:00 ID:HpYaxmb4.net
- >>22
Winnyの方は３週間ほどでまた新しいβバージョンが出たわけですが
対抗する気がないというのはどういうスタンスなのでしょう。
Winnyがオープンソース化されたらそのソースを参考に改良しようという事ですか。
もしそうであれば見当違いです。
さまざまな問題が先に解決されなければオープンソース化はありえません。
２ヶ月ほどたった事ですしもしよろしければ現在の開発状況のスクリーンショット
などを見せてもらえるといいのですが。
- 25 ：login:Penguin：03/06/23 01:24 ID:ubI6qRDc.net
- >>22
はぁ？
全く新しいファイル共有ソフトなんだろ？
最初からパクる気満々か？
とっととプロジェクトページ削除してこい
- 26 ：login:Penguin：03/06/23 01:41 ID:xC67Hzw3.net
- 未だに47氏の名前が出てくるという事はだ、
「案だけ出して、47氏に全部作ってもらおう。
そして、いつか言うんだ。俺達が頑張ってLinnyを作ったんだと。」
みたいな魂胆が露骨に見えます。
正直、関わらない方がいいよ。47氏さん。
- 27 ：login:Penguin：03/06/23 01:52 ID:V7hJkcQI.net
- >>26
>「案だけ出して、47氏に全部作ってもらおう。
> そして、いつか言うんだ。俺達が頑張ってLinnyを作ったんだと。」
違う違う
案も出さずに、47氏に全部作ってもらおう。
そして、名前を変えて言うんだ。「俺」が頑張ってLinnyを作ったんだと。
って535の魂胆なんだよ
代表の535以外に得する人間は一人もいない。
どのみちWinnyが成功すれば多くのUI形態で配布されることになるからな
通信部をパクるならWinnyの一形態として公開すればいいだけだ。
akiさんは早く手を引いた方がいい。
- 28 ：login:Penguin：03/06/23 02:35 ID:a26IWp8t.net
- 開発に対するプライオリティが部活より低い 535 に何を期待してるんですか?
そもそも最初からネタなわｋ（ｒｙ
- 29 ：login:Penguin：03/06/23 04:04 ID:y/vXpR9g.net
- 名前はどうであれ、オープンソースで効率的なファイル共有ソフトが
できるかどうかが重要なわけで。
できるならその方法、できないならその理由を考えてはどうですか
- 30 ：login:Penguin：03/06/23 04:05 ID:a26IWp8t.net
- とりあえず、DOM対策厨が議論に混ざらないようにすることが先決かもね。
- 31 ：login:Penguin：03/06/23 10:05 ID:FwxXxaFM.net
- >>27
それでもいいと思うけどｗ
535氏には広告塔以外の役目無いし。
世間的にも「Linnyプロジェクトを引っ張るのはなんと厨学生！」
てのはかなり使えそうｗ
なんにしてももうちょい頑張って欲しいな・・・
- 32 ：login:Penguin：03/06/23 12:41 ID:fauPhWJw.net
- >>25
削除方法が分かりません。
- 33 ：login:Penguin：03/06/23 14:01 ID:fauPhWJw.net
- 現在、削除要求出しています。もうしばらくお待ちください。
- 34 ：535 ◆rllaU5stOw ：03/06/23 15:36 ID:fauPhWJw.net
- 今から最終確認ですが、削除してもよろしいでしょうか？
>>aki様
wiki等はﾊﾞｯｸｱｯﾌﾟ取っております。削除してもいいでしょうか？
- 35 ：login:Penguin：03/06/23 15:54 ID:ijm2KPIl.net
- 人に何か言われただけでホイホイ削除って…
- 36 ：login:Penguin：03/06/23 16:02 ID:Bi+gTjza.net
- >>34
俺はいいと思うぞ。やれるもんならやってみろ。
- 37 ：aki：03/06/23 16:23 ID:a26IWp8t.net
- どうぞ。
- 38 ：login:Penguin：03/06/23 16:54 ID:FwxXxaFM.net
- >>21
前スレ>>72氏の
P2P-HTTP
P2P-FTP
が良さげ。
winny云々は考えるスレに任せて、
こちらはSix/Four路線でどうよ？
2chで使えるﾌﾟﾛｸｼほとんど無いし、需要はあると思う。
つか正直、ファイル共有より欲しい（ｗ
- 39 ：login:Penguin：03/06/23 17:17 ID:ijm2KPIl.net
- >>38
freenetのようなP2Pインフラを狙うわけですね。
freenetを参考にしたP2P-IRCプロキシでIIPというのがあるんですが、
IRC以外の用途にも使えるP2Pプロキシがあると面白そうですよね。
- 40 ：535 ◆rllaU5stOw ：03/06/23 17:17 ID:0iEhA2Nk.net
- >>37
すいません、本人確認ができません。
ﾒｰﾙで送るかﾌﾟﾛｼﾞｪｸﾄﾒﾝﾊﾞｰからはずれるかして意志表現をお願いします。
- 41 ：535 ◆rllaU5stOw ：03/06/23 17:29 ID:0iEhA2Nk.net
- 削除します。
- 42 ：535 ◆rllaU5stOw ：03/06/23 17:38 ID:0iEhA2Nk.net
- 削除しました。
ttp://sourceforge.jp/projects/linny/
- 43 ：535 ◆rllaU5stOw ：03/06/23 17:41 ID:0iEhA2Nk.net
- 誘導
今までありがとうございました。&ご迷惑おかけしてすいません。
今後のｶｷｺは
Winnyのオープンソース化を考えるスレ
http://pc.2ch.net/test/read.cgi/linux/1056020225/
でお願いします。削除依頼出してきます。
- 44 ：login:Penguin：03/06/23 17:45 ID:FwxXxaFM.net
- 終了かよ（ｗ
まぁ乙かれ・・・
色々大変だったねｗ
- 45 ：login:Penguin：03/06/23 17:48 ID:1hWmVwc7.net
- 気分すっきりWinnyｽﾚでがんばりましょう！
- 46 ：login:Penguin：03/06/23 17:57 ID:j/t68km4.net
- 結局、「削除しろ」って言ってて本当に削除されたら寂しいな（ｗ
- 47 ：login:Penguin：03/06/23 18:01 ID:kKDGGKZH.net
-
- 48 ：login:Penguin：03/06/23 18:10 ID:a26IWp8t.net
- で、私は aki と名前欄に書いただけの aki の中の人ではないのだが。
- 49 ：login:Penguin：03/06/23 18:14 ID:j/t68km4.net
- このスレが止まったらなぜかWinnyスレも止まる罠
- 50 ：login:Penguin：03/06/23 18:29 ID:a26IWp8t.net
- 向こうの馬鹿ウゼえなぁ
- 51 ：login:Penguin：03/06/23 18:40 ID:FwxXxaFM.net
- 終了した途端にこの荒れようか。
a26IWp8tよ、向こうのスレは荒らすな。
Linux版winnyは永遠に出ない気がしてきた。
- 52 ：login:Penguin：03/06/23 18:42 ID:a26IWp8t.net
- [w
- 53 ：aki__：03/06/23 19:39 ID:aS6bPXdP.net
- (´-`).｡oO(体調崩して寝てました……。)
とりあえず、私もバックアップ捕獲できたので、
後で適当に加工してinfoのwikiあたりにでもこっそり上げときます。
535さんに一言だけ。
荒らし耐性なさすぎです(w。
2ちゃんと言うくらいで荒らされてなんぼ、荒らしは放置を貫かないとなにもできませんぜ。
ともあれお疲れ様でした。
少なくとも47氏に動きを見せることが出来たという意味でも
何らかの価値があったのではないかと。
- 54 ：535 ◆rllaU5stOw ：03/06/23 19:46 ID:0egOb3Cx.net
- >>53
お体の方大丈夫でしょうか？
aki様もお疲れ様でした。
このﾌﾟﾛｼﾞｪｸﾄでは自分よりaki様の方が色々な意味で貢献されたのではないでしょうか？
Linnyのｻｲﾄの方はすぐには消えないみたいです。
> 後で適当に加工してinfoのwikiあたりにでもこっそり上げときます。
わざわざありがとうございます。多謝
> 少なくとも47氏に動きを見せることが出来たという意味でも
> 何らかの価値があったのではないかと。
そうですね。これからはWinny for Linuxでがんばていきましょう。
- 55 ：login:Penguin：03/06/23 19:50 ID:BUi/rKqN.net
- うははははあははははははは 終了かよっ！
- 56 ：login:Penguin：03/06/23 19:55 ID:S3RBKkWJ.net
- 糸冬了に驚いてる人大杉
- 57 ：login:Penguin：03/06/23 21:14 ID:ZLzr3b8R.net
- akiってどっかで聞いたことのある名前だと思ったら・・・
>>38のやつよさそうですよね
串を使いたい人が集まって誰が書き込んだかわからなくする・・・みたいな
- 58 ：login:Penguin：03/06/25 02:50 ID:UCRj9U1U.net
- プロプライエタリの必死の煽りによって、無事Linnyプロジェクトは崩壊を向かえたのであった
著作権を守るため、今日も戦え！
- 59 ：login:Penguin：03/06/25 12:50 ID:Yvy2it1l.net
- まじに参加しようと思ってるんですけど、
http://linny.sourceforge.jp/
が Not Found なのですが、、
- 60 ：login:Penguin：03/06/25 13:08 ID:/2H4NHHL.net
- >>59
何もはじまってないプロジェクトだったから、残念がる事はないよ。
マジならばイチから立ち上げてみてはどうか。
立ち上げるのは嫌だけど、一寸口出しして参加したつもりになりたかったのに・・・程度の思いならまぁ誰かがまた始めるのを待つしか無いだろね。
- 61 ：login:Penguin：03/06/25 14:05 ID:0Ir3gJLy.net
- オープンソースでWinnyのような匿名ファイル交換、という試みは
Winnyのオープンソース化を考えるスレ
http://pc.2ch.net/test/read.cgi/linux/1056020225/
の方で進んでいますよ。
そうではなくて、>>38さんや>>57さんのように匿名串をやりたい人がそこそこいるのであれば、
別の形で新しくプロジェクトを立ち上げても良いと思いますが。
- 62 ：login:Penguin：03/06/25 14:14 ID:lTf78IfS.net
- WASTEのほうに動きがあった模様です。
http://tmp.2ch.net/test/read.cgi/download/1054368897/
>>38 >>39 >>57
IIPについて調べてみました。
ttp://www.invisiblenet.net/iip/
ttp://peercast-jp.sourceforge.jp/cgi-bin/note.cgi?IIP
ttp://d.hatena.ne.jp/wireself/keyword/IIP?kid=3291
ttp://internet.watch.impress.co.jp/www/article/2003/0312/iip.htm
P2PのSOCKSプロクシって感じですかね？もしそうだったらemail,ICQ,HTTP,FTPと
使用範囲が幅広くなるので違うのかな？
間違っていたらごめんなさい。
Six/Fourを用いるのがいいのか、IIPを用いるのがいいのか、それとも
独自に作成するほうがいいのか考えてみます。
別にPure-P2Pでなくても構いませんよね？
Napsterのように中央サーバがあってもファイル交換するわけではないのだから
違法性無いはずだし。
>>59
どんなプロジェクトにします？
ファイル共有にしてもいいですし、P2P-Proxyでもいいですし。
>>59 さんのお考えを教えてください。
- 63 ：login:Penguin：03/06/25 18:00 ID:PAgtoa9N.net
- ファイル共有しないの？
- 64 ：login:Penguin：03/06/25 18:01 ID:+WOQp0Ch.net
- WASTE のスレ止まってるじゃん。
- 65 ：login:Penguin：03/06/25 18:45 ID:8zjhyX8G.net
- >>62
>P2PのSOCKSプロクシ
実現すれば素晴らしいね。
既存の技術を使うぶん、Six/Fourより使いやすいと思う。
作るのであれば、やはりピュアであるべきかと。
中央落とされたら使えなくなるのは避けたい。
- 66 ：login:Penguin：03/06/25 18:49 ID:faxk2d+u.net
- 寮ｽﾚ化ですか？
- 67 ：login:Penguin：03/06/25 19:24 ID:0Ir3gJLy.net
- (´-`).｡oO(socks使えるとsockscap使えるか……。)
- 68 ：login:Penguin：03/06/25 21:45 ID:CFztKyNM.net
- 以前にJXTAとかを使ったら?という話が出ていたので、(かなり前の話です)
かりにJXTAをミドルに使って作るとなると、
1.匿名性は確保できるか
2.Javaでの実装に問題があるか
などがありますがこれらはクリアできるのでしょうか？詳しいかたい
たら教えてください。
JXTAを利用すれば、プロトコルを一から作る必要がなく、ファイアウォール
越えも簡単。既存のJXTAネットワークがノードに利用できる可能性がある。
等の利点があると思うのですがどうなんでしょう。
- 69 ：login:Penguin：03/06/26 02:11 ID:aXR0H6Y1.net
- p2proxy=peer to proxy
- 70 ：login:Penguin：03/06/26 15:39 ID:6nY1ptMG.net
- Jxta は通信内容の暗号化機能は持っているけれど，ノードの隠蔽は意識していない．
ので，自分でそこのところは作り込む必要はあるけれど，基本的にはツールキットな
んで問題はないかと．Java での実装という面では，DoCoMo 504 あたり以上では動く
ようなので，いろいろ面白い遊び方ができると思ふ．
- 71 ：login:Penguin：03/06/26 22:06 ID:LoVoGAUZ.net
- >>70
通信内容の暗号化はSSLを利用するのですよね。ただそのときは一対一通信
になると認識しているのですが、間違いでしょうか。もしくはそれは問題に
ならないですか。
ノードの隠蔽は自分で作る際には、JXTAのプロトコル上の難しい気もするの
ですが思い違いでしょうか。また隠蔽するにはどのような方法が考えられま
すか。
- 72 ：login:Penguin：03/06/30 07:38 ID:0v7W8kLa.net
- (´-`)つttp://winny.info/2ch/misc/1053087824.html
- 73 ：535 ◆rllaU5stOw ：03/06/30 20:35 ID:WPplQGqN.net
- >>72
お疲れ様です。
- 74 ：login:Penguin：03/07/02 22:21 ID:OyDup/1H.net
- JXTAで開発できるﾔｼなんかいないだろ。
ここは一つ、Linux板らしくJXTA shell使って遊ぶか？（ｗ
- 75 ：login:Penguin：03/07/03 17:48 ID:1lzCTXeO.net
- http://www.hotwired.co.jp/news/news/technology/story/20030702301.html
ブラブスターは、コンテンツの検索や転送の処理において『UDP』というデータ転送プロトコルを
使用している。他のファイル交換ネットワークでデータ転送に使用されている『TCP』プロトコルと
異なり、UDPはいわゆる「コネクションレス型」であり、身元が特定されるような形で、各ノード間の
リンクを明らかにしたり、ファイルの転送を承認したりはしない。
UDPの転送ログでは、どのIPアドレスのどのユーザーが、いつ、どのコンテンツにアクセスしたか、
という詳細におよぶ情報はわからない。そのため、法的に情報の開示の必要がある際にも、TCPの
ログよりも安全であると考えられる。
- 76 ：login:Penguin：03/07/08 02:42 ID:L4K+tiMU.net
- 2ch乗っ取り危機が現実のものになってきています
2chだけでなく日本の為にも頑張ってください
- 77 ：login:Penguin：03/07/13 15:52 ID:HTvh61U8.net
- こんにちは
- 78 ：山崎 渉：03/07/15 11:24 ID:2JhhXBQM.net
-
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
- 79 ：login:Penguin：03/07/16 19:56 ID:rJtLfSeB.net
- Six/Four を用いたIMらしいよ。
http://ultramagnetic.sourceforge.net/
というわけで燃料投下！
- 80 ：login:Penguin：03/07/17 10:26 ID:U+HfWnIL.net
- dmachinemon って動かしてみた人いる？
http://www.netfort.gr.jp/~dancer/software/dmachinemon.html.ja
これから論文読んでみまふ．
- 81 ：login:Penguin：03/07/17 21:23 ID:l0ELA3tv.net
- >>80
紹介乙。
スレの流れからいわゆる『伝説のプロクシ』を作成しようという流れかな。
WinnyNET(って言ってもいいの？)を利用したい気持ちは山々なんだが
そういうわけにも行かないしねぇ。(速度がおぼつかないし、目的が違う)
SOCKは後回しにしても良いよね？
HTTPだけでも結構状況が違うし。
初期ノード情報を如何するべきかを考えればすぐに実装できるかしら？
暗号化はあとから皆で考えることにして。
どこかに改造しやすいプロクシが無いかな？
- 82 ：80：03/07/17 21:34 ID:QG1/s/xK.net
- ローカルネットワーク用ですた．> dmachinemon
>>81
単純な分散プロクシを P2P で，ってのは論文がありました．
「Peer-to-Peer Network を用いた Web Cache の提案と実装」
ttp://iplab.aist-nara.ac.jp/~eiji-ka/publications/cache/dps200210.pdf
多数のクライアントノードのローカルキャッシュを P2P で共有する，
ってだけですが，それなりに意味がありそうです．
実装したみたいですけど，コードは公開されてませんね．中で触れられている
squirrel とかもあたってみる価値があるかも
で，そこにどさくさ紛れに P2P コンテンツを流し込んでしまって，
独自 URL で流通させるっての面白くないですかね．
Winny と同様に中継なのか発信元なのかがわからないから，
誰が流し込んだかというのを発見するのは非常に困難かと．
- 83 ：81：03/07/18 12:32 ID:oZIteLv2.net
- >>82
有難うございます。2人しかいないのかしら？
論文拝見しました。結構楽しく読めましたけど、同時にP2PでProxyとなると
こういう利用法が限度かな、と。
実装した後のことを考えると、閲覧ならともかく書き込みもサポートしてしまった場合、
違法なものを本人の意思とは関係なくプロクシ経由で書き込まれてしまうわけですよね。
表面上書き込み責任が書き込んだ人ではなく、最終的に経由した人になるわけなのですが、
『私はP2P-Proxyを用いているので、その書き込みは私の物かどうかわかりません』
なんて言い訳が通用するかどうかを考えると、恐らくは無理でしょう。
(P2Pが閉じているならともかく最終的には開いてしまうので、証明をどの様に行なうのか
というのが困難かと。『悪魔の証明』というんでしたっけ？)
##Six/Fourの様に政治的メッセージに賛同する人が参加するならともかく
##普通の方は上のような状況を嫌がりますよね。参加意欲低下にも繋がるなぁ...
書き込み責任に関して、その辺りはどうなるとお考えですか > 皆様
- 84 ：81：03/07/18 12:39 ID:oZIteLv2.net
- 連書きしてしまい、すみません。
書き込み制限に引っかかってしまいました。
>>82
> で，そこにどさくさ紛れに P2P コンテンツを流し込んでしまって，
> 独自 URL で流通させるっての面白くないですかね．
Freenetでも出来ますけど、Winnyの様にもう少し改良する、ということでしょうか？
それともPeerCastやIIPのような形(コンテンツを限る)をお考えなのですか？
恐らくWinny作者は最終的にはこの路線を行くのでしょう。現状でも作者に2，3の改変を
(ご協力いただけるかどうかは別として)していただくことで可能ですし。
(Nychと同じことを掲示板ログ以外にもしていただければ)
面白いのは同感ですが、もう少し違った方向へ向かうのも一つの手かと。
##上のIMもそうですけど、NNTPとか、QuickML、WikiをP2P化してみるとか...
##「そんな馬鹿な」というのが以外に面白かったりするかも？
纏まりの無い文章で長レスまでしてしまい、すみません。
自分も考えてみます。
情報まで提供していただいたのに、否定する形になってしまい、御免なさい > >>80 さん
- 85 ：ぼるじょあ ◆yBEncckFOU ：03/08/02 05:41 ID:GfRe8vK7.net
- ∧＿∧ ∧＿∧
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
- 86 ：login:Penguin：03/08/04 01:04 ID:qQcuyAAm.net
- あんまり関係ない話ですが、zigumoプロジェクトが終わったようです。
P2P匿名掲示板zigumoスレッド
http://pc2.2ch.net/test/read.cgi/tech/1014643673/622
> 622 名前：デフォルトの名無しさん [] 投稿日：03/08/03 21:49
> http://www.zigumo.org/
> ｸﾋﾞﾂﾘｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!
とりあえずソースは公開されたようですが…
- 87 ：login:Penguin：03/08/12 02:12 ID:Z7Ey4Vhi.net
- 結局Winnyスレは何の収穫もないままに終わってしまったな。
- 88 ：login:Penguin：03/08/12 05:05 ID:YRdvP49G.net
- まぁ、「何故か」必要以上に荒れるからね。不思議なもんです。
- 89 ：login:Penguin：03/08/12 08:22 ID:sbvykeUI.net
- ﾀﾞｳｿ板は馬鹿が多いけど
Linux板は基地外が多い気がするな
- 90 ：login:Penguin：03/08/12 10:53 ID:tWeSi3b+.net
- 「ぬるぽ」 Winnyで広がるワームが出現
http://headlines.yahoo.co.jp/hl?a=20030811-00000003-zdn-sci
- 91 ：login:Penguin：03/08/12 14:36 ID:5Dn6RWGH.net
- >>89
ダウソ板に厨房とキティが混在していて、
そのキティがわざわざ犬板まで煽りに来ていたような気がする
- 92 ：login:Penguin：03/08/13 00:33 ID:KoPOgLDq.net
- 最大の問題はLinnyスレから派生したことだったなぁ
いつまで経っても開発スレと勘違いした連中の煽りが絶えなかった
- 93 ：login:Penguin：03/08/14 14:27 ID:Idwj8FIV.net
- >>82
論文を読みました。
主要な機能二つについては、
「サーバサイドのトラフィック削減」はクライアントにとってのメリットではない。
「Webキャッシュ」にしても、
WANで行った場合サーバから直接とってくるより、遅くなるのは明らか。
LANで行っても、p2pプロクシによるトラフィックの増大のデメリットの方が上回る。
さらに、ローカルキャッシュを検索させるという方針だと、キャッシュにヒット
する確率はかなり低い。
無理やりウェブキャッシュにp2pを適用しようとしたという印象。
- 94 ：login:Penguin：03/08/14 15:01 ID:2OiZiQMJ.net
- >>93
WAN回線が高価で、LAN回線が安価な場合にはメリットが上回る場合もある、
って程度じゃないかと。
あるいは、現在のいわゆるぶろーどばんど環境のように、アクセスにぶらさがっ
てる人同士の回線は速いけれど、ISP から上流に出ていく回線や、地域IP網と
ISP間がボトルネックになってる現状だと意味がある場合もあるのでは？
- 95 ：93：03/08/14 15:08 ID:Idwj8FIV.net
- >>94
＞WAN回線が高価で、LAN回線が安価な場合にはメリットが上回る場合もある、
＞って程度じゃないかと。
そうですね。
Gnutella を利用している以上、ISP内での利用といった規模の限定は考慮されて
いないでしょう。
- 96 ：login:Penguin：03/08/14 23:42 ID:Idwj8FIV.net
- p2p プロキシの場合，キャッシュは使わずに中継のみを行う方がよいと思います．
キャッシュのヒット率は低くなりそうですし，邪魔ですから．
# NNTP を P2P にすることによる利点はありませんね
- 97 ：login:Penguin：03/08/14 23:48 ID:N4JwhWKH.net
- 噂の雑談スレはここですか?
- 98 ：login:Penguin：03/08/15 00:06 ID:omFMb9vq.net
- nyが大変なことに
- 99 ：login:Penguin：03/08/15 00:21 ID:+0FqLQo4.net
- (´-`).｡oO(段々と別館出張所みたいになってるね(w)
- 100 ：login:Penguin：03/08/15 03:39 ID:iCqar7LK.net
- (´-`).｡oO(オープンソース化は興味があったんだけどネタが続かなかったな･･･)
(´-`).｡oO(クラック版程度ではびくともしないネットワークは難しいか･･･)
- 101 ：login:Penguin：03/08/15 07:54 ID:SaDnRADn.net
- 次スレが立たなかったのはオープン化スレで考えるべき、
と思ってることがみんなバラバラだったからだな。
最初は匿名性かDOM対策かなんて議題の根幹で揺れてたし、
47氏のお墨付きが出たと思ったら次は…
誰かがドップダウンでやらないと無理かね。
- 102 ：login:Penguin：03/08/15 08:28 ID:JREZ/n9e.net
- >>99
別館ってどこ？こんな議論(ってほどじゃないか)やってるとこ他にあんの？
>>101
ある程度一人でじっくり練ってから出さないと駄目だね。揚げ足はいくらでも取れるだろうから。
ウェブかどっかに私案を公開して、2ch や Wiki で叩いてもらうのがいいのかも。
- 103 ：login:Penguin：03/08/15 11:24 ID:vaGIFBTi.net
- ついにメタ議論に突入かよ。
次スレではメタメタ議論でもするつもりか。
- 104 ：login:Penguin：03/08/15 21:31 ID:wINQDnFx.net
- >>103は典型的なメタメタ議論レス
- 105 ：login:Penguin：03/08/15 21:53 ID:dyQryDMX.net
- (´-`).｡oO(……しっ！)
- 106 ：山崎 渉：03/08/15 22:42 ID:dil3w4kp.net
- (⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
- 107 ：login:Penguin：03/08/15 22:48 ID:shfoRmC4.net
- 久しぶりに来ると雰囲気変わってる罠
- 108 ：login:Penguin：03/08/16 06:54 ID:+sxxS92b.net
- ダメダメ議論スレ
- 109 ：login:Penguin：03/08/16 07:24 ID:RhQdldw0.net
- メタ議論＝悪という単純思考の>>103がいるスレはここですか？
- 110 ：login:Penguin：03/08/16 10:43 ID:sMfcUPLm.net
- 悪じゃないならさっさと話を進めろよﾄﾞｱﾌｫ
- 111 ：login:Penguin：03/08/16 20:12 ID:YBRMqwly.net
- 通信にIPv4をつかうと便利かもね
- 112 ：login:Penguin：03/08/17 16:50 ID:vKG4P+D3.net
- >>102
>ある程度一人でじっくり練ってから出さないと駄目だね。
発端は47氏でさえ思いつかなかった設計を考えようだから、
アイディア勝負みたいなとこもあるし、それもまた難しいんだよねぇ。
- 113 ：login:Penguin：03/08/20 22:18 ID:7Nmgbq9L.net
- 全然進まないね･･･
- 114 ：login:Penguin：03/08/20 22:23 ID:x7HiAcuc.net
- おい、もう終わったことを蒸し返すなって
- 115 ：login:Penguin：03/08/20 22:48 ID:yNsGaCu0.net
- もう進めるべきものは何もないからな。
この板にあるからスレがなかなか落ちないだけで。
- 116 ：login:Penguin：03/08/21 08:21 ID:IUy39Jr1.net
- きちっと敗北宣言してから終わりゃいいのに
- 117 ：login:Penguin：03/08/21 18:32 ID:8YwiO6rA.net
- なんだかんだ言いつつまだこのｽﾚに書き込もうとするみんなが好きだ。
- 118 ：login:Penguin：03/08/25 10:24 ID:1tasKpzX.net
- ﾎｯｼｭﾎｯｼｭ
- 119 ：login:Penguin：03/08/25 13:54 ID:Nodql6qE.net
- >>118
ﾎｼｭる価値はないと思うんだが…。
- 120 ：login:Penguin：03/08/28 00:40 ID:jmBnlOwQ.net
- なんだか俺はこのｽﾚのなごやかさが好き。
- 121 ：login:Penguin：03/09/03 01:03 ID:QCf+aeyX.net
- 結局47氏の判断は正しかったということだな
- 122 ：login:Penguin：03/09/03 04:09 ID:F3eMSn8K.net
- 47氏が現実解だったということなのかな。
まぁ、今後PCやネットワークの性能向上でFreenetでも何も困らない時代が来るのかもしれませんが。
ていうか、Freenetはアーキテクチャとして重すぎるのよね、「たいていの人の需要」より。
- 123 ：login:Penguin：03/09/03 13:47 ID:d/IVIvL7.net
- オープンソース化もいつのまにか無くなってるし・・・
やはりオープンソースで効率がいいというのは夢物語なのか
- 124 ：login:Penguin：03/09/04 02:17 ID:TgXSCPfx.net
- >>123
現時点ではそのようで。
- 125 ：login:Penguin：03/09/05 22:40 ID:TbF/xhP+.net
- >>123
場合によるでしょ。
ﾀﾞｳｿ厨にグダグダ言われながら開発を続けられる47氏の様な人がそう沢山いるとは思えないなぁ。
- 126 ：login:Penguin：03/09/06 20:02 ID:XphnzB0Y.net
- >>125
論点がずれてる
オープンソース化は47氏のいいだしたことだし・・・
- 127 ：login:Penguin：03/09/06 22:35 ID:dOqWcCK2.net
- というかwinny自体特に目新しいところ(クラスタワードくらいかな)のない
要は「使える」P2Pソフト、というgnutellaに毛が生えたくらいの存在なのに、
そんなのに追随しようとした時点で終わってることに先に気付けよ
- 128 ：login:Penguin：03/09/06 22:53 ID:rzYY9gbu.net
- >>127
「ただの使えるP2Pソフト」であるのには同意。
でも「gnutellaに毛が生えたくらい」は言い過ぎ。
それは利用者の視点では正しくても、アーキテクチャを話すスレでの発言じゃない。
Winnyの特徴は中継やキャッシュ、そして何より検索ネットワークの最適化であって、
初期の検索ベースのWinnyならともかく、今は検索の考え方自体が異なってる。
もはやGnutellaと似たような点は、検索クエリの飛ばし方くらいでしょう。
まぁなんだ。
煽りに釣られる漏れ必死すぎｗｗｗｗｗｗｗｗｗ
- 129 ：login:Penguin：03/09/07 12:46 ID:eDp90Zhw.net
- >Winnyの特徴は中継やキャッシュ、そして何より検索ネットワークの最適化であって、
>初期の検索ベースのWinnyならともかく、今は検索の考え方自体が異なってる。
具体的な説明を頼む。
というかそんだけなら今のgnutellaのバリエーションなら普通にやってる
のだが。「中継やキャッシュ」にしても単に個々のノードが一旦ダウンロード
したファイルを消さないで持ってることを言い換えたに過ぎないし。
- 130 ：login:Penguin：03/09/07 20:42 ID:p8fFibd0.net
- >>129
P2Pレイヤでの「手」をファジーに結ぶというやりかたが独自な点だと思う。
で、それから派生するクラスタ化なんかがユニークかなと。
キャッシュと中継自体は FreeNet 由来なので独自性はないよね。ホップ数を2程度
に押さえることによって匿名性を犠牲にするかわりに、速度を上げたというのはそ
れなりに重要な判断だったとは思うけど。
- 131 ：login:Penguin：03/09/07 23:26 ID:KFsKt4VZ.net
- >>129
既存の技術を組み合わせたことがすごいんだろ？
- 132 ：login:Penguin：03/09/08 08:19 ID:N9TyP+D7.net
- >>130
>P2Pレイヤでの「手」をファジーに結ぶというやりかたが独自な点だと思う
ごめん、ﾜﾛてしまいました
- 133 ：biosmania ◆ZqBiosoUXU ：03/09/12 22:47 ID:ZCNo5NQh.net
- renice
- 134 ：login:Penguin：03/09/16 19:24 ID:CeVw9vHS.net
- Good-bye妄想
- 135 ：login:Penguin：03/09/16 21:34 ID:eTbsLuFk.net
- もうだめぽ
- 136 ：login:Penguin：03/09/21 04:19 ID:VWdJX2vn.net
- 今さら遅いが、とりあえずLinuxでnyのキャッシュをファイルに変換する機能と
キャッシュをP2Pで共有する機能がありさえすれば・・・
- 137 ：login:Penguin：03/09/23 07:14 ID:Lj9E923E.net
- ありさえすれば何なのかイマイチわかりませんです
- 138 ：login:Penguin：03/09/23 17:02 ID:PLD7+XN+.net
- 面白そうなんで開発に参加しようと思ったけど、下記のスレはdat落ちだしsourceforge.jpは
メンテでずっと落ちているし。
一番ホットな場所（スレ、サイト）はどこですか？
Winnyのオープンソース化を考えるスレ
http://pc.2ch.net/test/read.cgi/linux/1056020225/
- 139 ：login:Penguin：03/09/23 19:12 ID:PLD7+XN+.net
- とりあえず漏れの構想を。
winnyみたいなP2Pの敵はISPによる帯域制限。
これを避けるには何かのプロトコルに似せて、制限をかけれないようにしなければ
ならない。
大容量のファイルをやり取りするものとしてストリーミングやFTPがあるが
これからはSIPがいいと思う。SIPはVoIPで使われているプロトコルの一つで、
長時間に渡って通信しても長電話をしていると思われるだけで、これに規制
をかけるのはQoSにシビアなVoIPができなくなるので規制しづらい。
SIPのライブラリとしてGPLのものがあるし、開発もやりやすいと思う。
SIP版Linnyはどうだろうか？
- 140 ：login:Penguin：03/09/23 20:00 ID:ADRDSTJr.net
- 他プロトコルに擬装するならKeep-AliveなHTTP上に載せるのが良いでしょ。
木を隠すなら森の中。
もちろん、自宅鯖上げるの禁止なISPだとだめだけど。
- 141 ：login:Penguin：03/09/23 20:51 ID:ZputeOjA.net
- >>140
CATVは鯖禁止してるところ多いぞ
- 142 ：136：03/09/23 21:51 ID:ey6PpkfZ.net
- >>137
ありさえすれば、WindowsとLinuxデュアルブートしてる人を拠点にして、
Winnyネットワークと一部互換性のあるLinnyができるかなー、とか
思ったんだけど、やっぱ駄目か・・・。無駄が多いだけかもな。
- 143 ：login:Penguin：03/09/23 21:58 ID:PLD7+XN+.net
- >>136
検索機能とBBSはいらないってこと？
言葉でいうのは簡単だが、共有する機能っていうのが大規模で、
結局のところ全て実装するということと違いはなくなる。
キャッシュを変換って無理じゃなかった？それができたら変換済みのキャッシュを
消されて、共有ファイルが減っちゃうから。
- 144 ：login:Penguin：03/09/23 22:02 ID:PLD7+XN+.net
- >>140
HTTPでできるならそれがベストだろうね。LinnyはHTTPで作るみたいだし。
疑問だけど、winmxは6699やプロトコルをプローブしてISPで規制できるけど、
winnyはどうやって規制しているの？
>>141
うちのCATVも鯖立て禁止してるなぁ。全体からみたら少数派なんだろうが。
- 145 ：login:Penguin：03/09/24 02:11 ID:N93nfcMK.net
- httpだと転送効率悪そうだな。
- 146 ：login:Penguin：03/09/24 19:22 ID:yM3snryR.net
- httpらしく（？）多重ダウンロードで補う・・・？
いっそのことftpと平行ダウンロードとか（どうやるんかわからんけど）。
- 147 ：login:Penguin：03/09/25 13:43 ID:pTJ8pjGy.net
- >>139
SIP はセッション初期化に使うシグナリングプロトコルだから…
現在出てる帯域制御ソリューションはペイロードのデコードと、SYN/ACK や
フラグのパターンの組合せをパターンマッチグかけてる。ある意味ウィルスの
パターンファイルみたいな感じで刻一刻アップデートされているそうな。
多少冗長になるのをあきらめて、通常の HTTP に見える、あるいは通常のHTTP
を誤認識しかねないようなパターンを使うか、いっそのこと擬似 HTTPS にして
しまうあたりが簡単かな。
もうちょい徹底するなら UDP とかで状態を持たない通信をするとだいぶひっ
かけにくくなると思われ。
- 148 ：login:Penguin：03/09/25 14:10 ID:JHbxphhc.net
- udp だと、壁の後ろの通信はどうなるんかいな？
- 149 ：PLD7+XN+：03/09/25 21:28 ID:LAH93U+r.net
- >>145-146
別に転送効率が悪いとは思わないが。Apacheがforkした各プロセスについて
リソースを食い尽くさないようにしているだけで、任意のhttpdなら転送効率は
tcpを使う他のプロトコルと違いがないはずだが？
>>147
その通り、SIPは呼の制御をするだけで、メディアはRTP/UDPで送られる。
FTP、RTSPと並べてSIPを説明しただけで、SIPが不利だとは思わないが。
でも偽装するならHTTPSがよさげですなぁ。
SIPプロファイルは多種多様だから、ISPが自分のSIPプロファイル以外を
規制するといったことが容易にできちゃうから。もっとIP電話が普及して
相互接続を海外ともやるようになったら考え物かも。
帯域制御ソリューションってなかなか表には出てこないだろうけど、どこかに
製品説明のページとかないかなぁ？まずは敵を知らねば。
- 150 ：147：03/09/25 22:11 ID:pTJ8pjGy.net
- >>149
いくつか製品説明聞いた限りでは、>>147 に書いた通り。導入は基本的に守秘契約
結んだ上でやってるそうな。あんまり派手に宣伝したくないし、対策打たれるのが
いやだから技術詳細も出さないとか。
バージョンアップから1週間程度で対応、ってほんとにワクチンソフトみたいな
感じでやってるところもあるみたい。どうせ海外製だから ny は大丈夫だろう、
と思ってたら最近対応してきた模様。がんばれ 47 氏。
- 151 ：login:Penguin：03/09/26 03:05 ID:cxPUpKJu.net
- UDPでstatelessでがんばるというのは、確かGNUNetあたりがやっていた気がする。
違うやつだったらごめん。
Winnyも、相手を認証(Winnyかどうか、速度、キーワード)するためにstateがあるけど、
データやクエリの転送のプロトコルそのものはstatelessに近いつくりになってるよね。
とはいえ、とりあえずSSLでひねってタイミングばらしとけ、というのが
暗号学的には正しいかもしれない(w
- 152 ：147：03/09/26 13:16 ID:I9OSqmmB.net
- >>151
某帯域制御装置は TCP の state そのもの (SYN/ACK RST/ACK とか) をパターンマッチ
に使っているようなので、そこで言ってるプロトコルの stateless とは意味合いがちと
違う。
GNUNet は面白そうだね。ちょっと見てみよう。blobster(だっけ？)も udp の筈だけど、
どういう意味で udp なのかはよくわかんね。
- 153 ：login:Penguin：03/09/26 13:31 ID:Uj+p3opQ.net
- `なんかなし崩し的に再開してるみたいだけど
ここでやっている限りどんな成果も上がらないことを予言しておこう。
ま、みんなわかってて雑談してるんだろうけど。
- 154 ：login:Penguin：03/09/26 15:02 ID:31wZ9hRG.net
- nyができるならLinux使ってやってもいいぞ
んじゃ。
- 155 ：login:Penguin：03/09/26 15:05 ID:JLDQTVR/.net
- >>154
お前は一生使わなくていい。
- 156 ：login:Penguin：03/09/27 21:55 ID:uJAFC40f.net
- まじめにやるなら基本的にトップダウンで議論しつつ
価値観や方針が分かれたら枝分かれするようにしないと進まない予感。
Wiki再開したら？
- 157 ：login:Penguin：03/09/27 21:58 ID:Ynf20TqY.net
- 欲しい物は喪前が用意すれば？
- 158 ：login:Penguin：03/09/27 22:20 ID:uJAFC40f.net
- 俺が欲しいわけじゃないよ。
ただ前スレの議論の仕方があまりにお粗末だから提案してみただけ。
- 159 ：login:Penguin：03/09/27 22:24 ID:Ynf20TqY.net
- もともとネタスレなんだが。
- 160 ：login:Penguin：03/09/27 22:27 ID:/Lj5F/Eu.net
- もともともうだめぽ
- 161 ：login:Penguin：03/09/29 20:02 ID:EMvTEBRb.net
- 素直にWineでny動かした方が手っ取り早いかと思われ。
【Linux】 - 今夜も Wine で乾杯! - 3本目
http://pc.2ch.net/test/read.cgi/linux/1056624244/
- 162 ：login:Penguin：03/09/29 21:42 ID:VIyCPPDw.net
- 最新の ny だと動かないんだよね > ny on wine
- 163 ：login:Penguin：03/09/29 21:48 ID:naZPU/i3.net
- あれって、何で動かないの?
- 164 ：login:Penguin：03/09/30 04:56 ID:pBkPZmbi.net
- >>163
展開ルーチンでマニアックなことしてるからじゃないかな
デバッガで追ったらOSの例外処理を利用して展開してる感じだったし
- 165 ：163：03/09/30 05:08 ID:G3Xc39i7.net
- >>164
さんくす。エミュレーションがまだまだってことなのかぁ。
どこかのフォーラムに、telock はハードウェアブレークポイントまでセットして
デバッガを検出してるとか書いてたのを見ますた。
でさ、本来の .exe をメモリ内に展開するところまで到達したんだけど、
メモリダンプから正常に動く .exe が作れなくて (´･ω･`)ｼｮﾎﾞｰﾝ
- 166 ：login:Penguin：03/10/01 02:57 ID:LIy9JvSm.net
- >>165
実際に見てみたわけでないけど、本体チェックしてるみたい。
展開後のイメージをメモリに置くだけでは動かないみたい。VC版のときからだけど。
激しくすれ違いの悪寒
- 167 ：login:Penguin：03/10/01 09:46 ID:aC6EfEPe.net
- いっそのことLinny開発プロジェクトから
WINEでWinny起動プロジェクトに転換したほうがｲｲ鴨。
- 168 ：login:Penguin：03/10/01 11:53 ID:yMxaMoTD.net
- >>167
そうだな。
願わくば、それによってWINEが真のwindows emulatorになってくれれば、
LINUXの出来る世界が大幅にひろがるだろうし。
ny使ってないし、WINEにソース寄稿できるぐらいのる能力もないけど、、、、、、、。
- 169 ：login:Penguin：03/10/07 10:55 ID:vOF4BlxJ.net
- 終了。
- 170 ：login:Penguin：03/10/08 03:01 ID:Xl8i3l2+.net
- 再開
- 171 ：login:Penguin：03/10/08 13:37 ID:YXTZLHZ5.net
- Winny開発者の47氏がここ最近姿を見せていないらしいね。
漏れは47氏が著作権など既得権益の死守をはかる組織によって殺害されたと考えている。
もし犯人が捕まってもどうせ金で雇われた中国人だろうし、その先を調べても黒幕に
行き着くことは不可能だろうが。
単なる妄想と一笑して済ませられればいいのだが、Winnyがコンテンツビジネスを破壊
するだけの力を持っているのは明らかで、このまま野放しにしておけば破滅は避けら
れなかった。
47氏が匿名でクローズドな開発をしていたのは自分の身を守るためだったわけだが、
少なくとも今回はそれが裏目に出た、と言えよう。
死人に口なし、とはよく言ったものだ。
真相は永遠に闇の中・・・
- 172 ：login:Penguin：03/10/08 16:33 ID:BEJclBvC.net
- というか単に忙しいだけでしょ
まだ一ヶ月もたってないのに死人扱いされるなんてかわいそうだねぇ・・・
- 173 ： ◆1haVRB54HY ：03/10/08 16:43 ID:R7Iwp/qj.net
- それをいうならNoName開発者(顔文字いれるのﾏﾝﾄﾞｸｻ
なんて。。。。
age
- 174 ：login:Penguin：03/10/08 19:23 ID:qUQRrO57.net
- そういえば誰かfreenetの新しいフロントエンド作ってる人がいなかったっけ？
あれってどうなったんだろう。
freenetはフロントエンドさえしっかりしてればそれほど効率が悪くないと言う人がいるので興味はあるんだけど。
- 175 ：login:Penguin：03/10/09 06:26 ID:7IcEZTef.net
- こっちへどぞ。
ttp://jbbs.shitaraba.com/computer/5098/
- 176 ：login:Penguin：03/10/09 23:58 ID:9Vc8GI09.net
- >>175
どうもありがとう。
- 177 ：login:Penguin：03/10/11 13:59 ID:c7ghlcpD.net
- このスレは今からUnny開発プロジェクトに変わりますた。
- 178 ：login:Penguin：03/10/13 20:06 ID:9a90mJZ3.net
- なんかさ・・・ 47氏の中の人がマジ大変なことになってるようで・・・
Linuxどころじゃねーんだろな。
こりゃますます47氏に依存しないLinnyの確立が期待されるところだが・・・
- 179 ：login:Penguin：03/10/13 21:51 ID:rVbJnK2o.net
- 名前はLinnyでも何でもいいから新しいfreenetフロントエンド作ってよ。
- 180 ：login:Penguin：03/10/13 21:54 ID:xbG29dg3.net
- >>178
どこかのスレに載っているの？
生存してるよね？
- 181 ：login:Penguin：03/10/13 21:56 ID:xbG29dg3.net
- あったあった。
ttp://www.geocities.co.jp/SiliconValley/2949/ny.html
- 182 ：login:Penguin：03/10/13 22:20 ID:xbG29dg3.net
- デジタル証券によるコンテンツ流通システム
ttp://www.geocities.co.jp/SiliconValley/2949/Digikabu.html
これについて討論できる場所ってどこ？
漏れの感想は、コンテンツを配信する権利、コンテンツ製作元にものを言う権利
を得るためにデジタル証券を購入するとは思えないから、うまく動かないと思う。
- 183 ：login:Penguin：03/10/13 23:17 ID:j0aKmbqi.net
- Winny作者が語る将来展望とデジタル証券システム
http://slashdot.jp/article.pl?sid=03/10/13/074209&topic=104
- 184 ：login:Penguin：03/10/14 00:01 ID:lHY+UrIP.net
- >>183
サンクス！
- 185 ：login:Penguin：03/10/14 00:02 ID:lHY+UrIP.net
- コピーフリーでも成り立つ集金モデル２
http://money.2ch.net/test/read.cgi/eco/1065980359/l50 [2ch.net]
【通信】Winnyの将来展望について ★2 （2003/10/10）
http://book.2ch.net/test/read.cgi/bizplus/1065873890/l50 [2ch.net]
コピーフリーでも成り立つコンテンツ製作者側の（略
http://money.2ch.net/test/read.cgi/stock/1065889373/l50 [2ch.net]
- 186 ：login:Penguin：03/10/14 16:51 ID:kBAx32UI.net
- 無理だな
- 187 ：login:Penguin：03/10/21 02:28 ID:sIXV7OYa.net
- P2P型ネットワーク対戦ゲームってある？
FinalFantasy XIみたいなネットワークゲームを、中央サーバなしで
OpenSource Communityでやるのは面白そうじゃない？
商用顔負けのゲームつくれないかな。
- 188 ：login:Penguin：03/10/21 02:51 ID:owDTMc8X.net
- 検索してみろ。
あと野良サーバーで商用ゲームやっている奴もちらほら
- 189 ：login:Penguin：03/10/21 08:21 ID:ePZNdgoq.net
- >>187
とりあえず、普通のゲームでも商用顔負けってのは少ないんだから
ネットワークゲームを、それも中央鯖無しで面白くってのはかなり難しいかと
でも通信の部分だけでもできたらすごいよね
- 190 ：login:Penguin：03/10/21 13:46 ID:DHWtZaYW.net
- >>189
1年後にPenguin版もできるらしいよ
http://gamdev.org/w/?[[PxP]]
- 191 ：login:Penguin：03/10/24 03:10 ID:MeLvsMjG.net
- 本家が開発終了な感じだが、こちらも(ry
- 192 ：login:Penguin：03/10/24 08:39 ID:IBNvuHP/.net
- こちらは開発にすらたどり着けなかったんだがな
- 193 ：login:Penguin：03/10/24 08:54 ID:8ugQWh1J.net
- つーことで、Winny の逆汗して互換品を作るスレにしようぜ。
- 194 ：login:Penguin：03/10/24 12:41 ID:dLXppHIo.net
- >193
そんなことできるのか！？
- 195 ：login:Dayomon：03/10/24 15:52 ID:8QNGqh+r.net
- お前らGNUnetがいけてるんですが一緒に遊びませんか？
- 196 ：login:Penguin：03/10/25 02:56 ID:fT86YYhN.net
- >>193
通信部の解析はめんどいからやる気にもならん。
そんなことするくらいなら新しくつくったほうが速い
- 197 ：login:Penguin：03/10/25 22:56 ID:mByoNVQw.net
- Linux使いには、47氏並みの能力を持つプログラマーはいないのか！？
- 198 ：login:Penguin：03/10/25 23:02 ID:rBEfoTH3.net
- >>197
見当違いの証券システムとかを発案する能力のこと？
- 199 ：login:Penguin：03/10/25 23:20 ID:mByoNVQw.net
- いや、この場合、プログラミング能力+厨のバージョン催促に耐える能力のこと。
- 200 ：login:Penguin：03/10/25 23:30 ID:rBEfoTH3.net
- マジレスさんくす。
crack 耐性が高い通信方法を生み出す能力も欲しいよね。
- 201 ：login:Penguin：03/10/28 14:36 ID:4Vx0oMC6.net
- >>197
結構いるよ。
あと、OS,プログラム板にはそれ以上の御方も。
- 202 ：login:Penguin：03/10/28 23:33 ID:7BAsFMT8.net
- >201
それらの神々は、世俗なことには干渉しないのでつか？
- 203 ：login:Penguin：03/10/29 00:42 ID:3W9h7fEu.net
- ライセンスを重んじていたりするからじゃないの？
匿名通信ができるアプリは、結局割れ物の取り引きにしか使われないんだし。
- 204 ：login:Penguin：03/10/29 00:57 ID:BnJyeKO1.net
- リスクもあるしね。
もし自分が作っているとバレたら…？とか。
- 205 ：login:Penguin：03/10/29 00:58 ID:3W9h7fEu.net
- Freenet 内なり Winny 内なりで公開すれば、かなりリスクが低くなる？
- 206 ：login:Penguin：03/10/29 00:58 ID:LVWXyaex.net
- 作ってみたいけどなぁ
Windowsでの開発知識しか無い
- 207 ：login:Penguin：03/10/29 01:13 ID:3W9h7fEu.net
- と、そんな嘘でごまかせると思っている人がいるので、注意が必要ですね。
- 208 ：login:Dayomon：03/10/29 03:14 ID:sFHSNqVn.net
- ナイス連携。
- 209 ：login:Penguin：03/11/05 01:17 ID:Vb1P/sn/.net
- ぺったんぺったん
- 210 ：login:Penguin：03/11/09 19:49 ID:GbnINMgp.net
- びっくりするほどＰ２Ｐ！
- 211 ：login:Penguin：03/11/10 12:58 ID:vLbAgvq1.net
- >>195
最近更新されてないみたいだけど、
いけてるんですか?
- 212 ：login:Penguin：03/11/18 21:11 ID:bEG7ksJ8.net
- 漏れら極悪非道のageブラザーズ！
今日もネタもないのにageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ∧＿∧ age
（ 'A`∩） （∩´∀｀） age
（つ 丿 （ ⊂） age
（ ヽノ ヽ/ ） age
し（＿） （＿）Ｊ
- 213 ：login:Dayomon：03/11/19 01:21 ID:NUnV2Rmg.net
- ﾉｼ
- 214 ：login:Dayomon：03/11/23 01:44 ID:w0hNbOKT.net
- ヽ(ﾟ∀ﾟ)ﾉ ｱｯﾋｬｯﾋｬ
- 215 ：login:Penguin：03/11/28 00:07 ID:DF914n14.net
- nyが無くなる今、このスレをageなくてどうする？
- 216 ：login:Penguin：03/11/28 00:29 ID:ttKXuPtv.net
- まだあったんだ、このスレ。
家宅捜査か、、何で匿名が破られたんだ？
- 217 ：login:Penguin：03/11/28 01:21 ID:WQa0DvCQ.net
- geocitiesへのftpアクセスログじゃないの?
そのために色々と法案通していたし。
- 218 ：login:Penguin：03/11/28 03:31 ID:SiJSR2Jo.net
- 完全に匿名なわけじゃないからねぇ。
今回は47も家宅捜索されたみたいだから、
47が暗号化解除とかで協力したんじゃないの。
- 219 ：login:Penguin：03/11/28 03:33 ID:4aVtXQnt.net
- 家宅捜索でＫはnyのソースを得た事になるな
- 220 ：login:Penguin：03/11/28 05:04 ID:icFsr3aB.net
- >>217
やっぱその線かのぅ ４７も迂闊だったな
あと2chのログか
- 221 ：login:Penguin：03/11/28 16:31 ID:DF914n14.net
- さぁプロジェクト再始動だ
- 222 ：login:Penguin：03/11/28 17:08 ID:qG5hbGfy.net
- 金にならないP2Pなだけに、職業プログラマは無視を
決め込んでるみたいだけど、プログラミングテーマとしては
P2P特に匿名ファイルシェアリングソフトは熱いな〜
- 223 ：login:Penguin：03/11/28 17:58 ID:f/j5dBc6.net
- さて、今回の問題でWinnyのどこに問題があったかが示されたわけだが。
現状、Winnyシステムの根本がこけたわけではないと思うが、1人に頼りすぎたのが
敗因だと思う。
次はどうするよ。Winny式でオープンソースでFA？
- 224 ：login:Penguin：03/11/28 18:58 ID:QvTe2a/1.net
- 次世代は、公開しても安全で不正の極めてやりにくい「プロトコル」を
実体とするべきだとおもう。
極論、実装は誰がやってもいい。
- 225 ：login:Penguin：03/11/28 20:02 ID:GoFNDi8X.net
- 実際、仲間ウチで小さく
P2P転がすような事をやらないと今回みたいな事になる。
プロトコルや実装の問題より運用の問題が大きい。
- 226 ：login:Penguin：03/11/28 20:25 ID:96YzfNpY.net
- 馬鹿はいつでもどこにでもいるからな
- 227 ：login:Penguin：03/11/28 20:25 ID:n2B30HKa.net
- >>225
んで実際問題ソフトは出来たの？
- 228 ：login:Penguin：03/11/29 00:29 ID:Xr1K3nva.net
- ｵｰﾌﾟﾝｿｰｽ(･A･)ｲｸﾅｲ！
- 229 ：login:Penguin：03/11/29 00:56 ID:oiytMlVm.net
- 理論的に匿名性が保証できるプロトコルにして、さらに回線帯域をガンガン使
うような仕様にしてユーザを光に限定してしまえば、Winny がオープンソース
にできなかった最大の原因であるところの FreeRider 問題はある程度解決でき
るような気がするのだけれど、甘いかな？
- 230 ：login:Penguin：03/11/29 03:29 ID:IymQcMSr.net
- 【神】UNIXにWinnyを移植【降臨】
http://pc.2ch.net/test/read.cgi/unix/1065863581/l50
次期P2Pの仕様 part2
http://tmp2.2ch.net/test/read.cgi/download/1070027719/l50
- 231 ：某所管：03/11/29 03:45 ID:x77e14sf.net
- 一応、記録的価値としてLinnyWiki復活させておいたので張っておきまつ。
ttp://linny.winny.info
- 232 ：login:Penguin：03/11/29 08:38 ID:jErzhRBe.net
- >>221-
この緊急時に相変わらずｸﾞﾀﾞｸﾞﾀﾞなループ繰り返してるのにはﾜﾛﾀ
- 233 ：login:Penguin：03/11/29 14:24 ID:uU3sSM8j.net
- このスレまだあったのか。ny逮捕でﾀﾞｳｿのﾔｼらが
ム板とか犬板をあさっているのかな。
- 234 ：login:Penguin：03/11/29 17:41 ID:UGXkZjJ0.net
- 初期のLinnyのことも考えてまともな頼れるリーダを2人くらい作ったほうがいい気がする。
- 235 ：login:Penguin：03/11/29 17:44 ID:iLpA4HcV.net
- P2P Projects supporting Anonymity
http://knet.sourceforge.net/p2p.html
- 236 ：login:Penguin：03/11/29 19:17 ID:3iYswX3r.net
- >>234
／￣￣￣￣￣￣＼
／ ＼
/ ヽ
l:::::::::. |
|:::::::::: （●） （●） | 呼んだ？
|::::::::::::::::: ＼＿＿_／ |
ヽ:::::::::::::::::::. ＼／ ノ
- 237 ：231：03/11/30 12:31 ID:w2iVfBfH.net
- >>234
／￣￣￣￣￣￣＼
／ ＼
/ ヽ
l:::::::::. |
|:::::::::: （●） （●） | 呼んだ？
|::::::::::::::::: ＼＿＿_／ |
ヽ:::::::::::::::::::. ＼／ ノ
- 238 ：login:Penguin：03/11/30 17:17 ID:u/aqrZK8.net
- 次期P2Pの仕様 part5
http://tmp2.2ch.net/test/read.cgi/download/1070113264/
P2Pもいろいろとソフト変更があるみたい。ここを除くことお勧め
- 239 ：login:Penguin：03/12/01 01:37 ID:HcdZ6tlc.net
- P2Pなんか危いよ
もうnntpしかないよ
- 240 ：login:Penguin：03/12/01 22:27 ID:8ZXVF3BM.net
- 結局このスレは頓挫してたのか・・・
やっぱ烏合の衆だけじゃだめだな。
一人の実行力をもってる人がいなきゃだめだ
- 241 ：login:Penguin：03/12/01 22:41 ID:WiuZNPkX.net
- >>240
／￣￣￣￣￣￣＼
／ ＼
/ ヽ
l:::::::::. |
|:::::::::: （●） （●） | 呼んだ？
|::::::::::::::::: ＼＿＿_／ |
ヽ:::::::::::::::::::. ＼／ ノ
- 242 ：make world：03/12/02 19:31 ID:aKXy48Gr.net
- openで開発したら収拾つかないだろうな
- 243 ：login:Penguin：03/12/03 02:38 ID:rPc4FgbH.net
- >>242
収拾する必要は無い
- 244 ：login:Penguin：03/12/04 02:10 ID:0dWBPS/h.net
- ソフト開発出来る人、参加して下さい。オープンソースでの開発を目標にしています。
次期P2Pの仕様 part5
http://tmp2.2ch.net/test/read.cgi/download/1070113264/
- 245 ：login:Penguin：03/12/04 02:10 ID:0dWBPS/h.net
- age忘れました。
- 246 ：login:Penguin：03/12/04 05:04 ID:AK3fWQow.net
- >>244
コードは書けんが、テストなら協力できますよ
- 247 ：login:Penguin：03/12/04 08:15 ID:LZsdqusC.net
- >>244
アップはできんが、ダウンなら協力できますよ
- 248 ：login:Penguin：03/12/06 16:41 ID:ASv9zxaf.net
- 典型的なプロジェクト失敗例を見せてくれたスレ
- 249 ：login:Penguin：03/12/07 00:28 ID:1ZK45BnP.net
- プロジェクトにすらなってないけどな
- 250 ：login:Penguin：03/12/20 19:45 ID:uF39G1i3.net
- http://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：03/12/20 20:17 ID:orBV6cTG.net
- http://pc.2ch.net/test/read.cgi/prog/1071794941/l50
- 252 ：login:Penguin：03/12/21 00:53 ID:Tnk+ergb.net
- >>250
これ、期待できそうです。
- 253 ：login:Penguin：03/12/21 01:21 ID:7KaUReeK.net
- で、251のスレでWinny2のソースらしきものが張られているわけだが・・・。
- 254 ：login:Penguin：03/12/21 01:42 ID:UW66JoV+.net
- >>253
ところで、パスワードは割りましたか？
- 255 ：login:Penguin：03/12/22 05:22 ID:Fx01jsVP.net
- >>254
ﾀﾞｳｿすらできてないわけだが・・・。
どのプロキシ使えば落とせるのやら。
- 256 ：login:Penguin：03/12/22 17:21 ID:C9mRSYV4.net
- >>250 /.本家より
MUTE: Simple, Private File Sharing
http://slashdot.org/article.pl?sid=03/12/19/1750250
だそうだ
- 257 ：login:Penguin：03/12/23 20:17 ID:UofXNrH/.net
- 蟻が食べ物を見付ける方法からインスピレーションを得たってなんか凄いな・・・
- 258 ：login:Penguin：03/12/24 09:19 ID:p5RJmfHH.net
- >>256
で、どうよ。使えそうか？
俺の環境(RedHat9)では固まりまくるが。
- 259 ：login:Penguin：04/01/08 12:45 ID:91Mu2rfW.net
- Mute Ver.0.2
http://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.net
- age
がんばれ
- 261 ：login:Penguin：04/01/14 00:07 ID:Qid/c1ot.net
- 俺もRedHat9ですが接続先を追加できないっぽいです
- 262 ：login:Penguin：04/01/29 21:39 ID:gWkVseHH.net
- ほしゅ
- 263 ：login:Penguin：04/01/31 00:08 ID:PjoeMZsH.net
- んでいつできるんだ？
- 264 ：login:Penguin：04/02/04 10:13 ID:3zoKxviV.net
- MUTEを日本語使えるようにすりゃいいじゃん。
- 265 ：login:Penguin：04/02/11 23:48 ID:2/PKzn50.net
- 俺、linuxというかUnix版のWinny作ってるんだけど、
やっぱ公開すると、家宅捜索とかされちゃうのかな？
- 266 ：login:Penguin：04/02/12 02:55 ID:gusrgYRS.net
- そもそも君の場合は、コードが手元にない狂言なので、大丈夫かと。
- 267 ：Seisei_Yamaguchi：04/02/15 02:29 ID:NKg64qLe.net
- 警察の中の人はソースが欲しかったから
ジオシティー日本から辿ったんとちゃう ?
- 268 ：login:Penguin：04/02/17 20:23 ID:l3npdv3O.net
- Winnyパケットをブロックするソフトが出たみたいだね。
age
- 269 ：login:Penguin：04/02/18 11:15 ID:9aTdwy7Y.net
- >>268
これのことだろ。
http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20040217/139906/
モニタしてるキャプ画像があるんだが、暗号は完全に解読された模様。
もうwineでwinny動かしてる場合じゃないぞ、おまいら。
- 270 ：login:Penguin：04/02/18 12:14 ID:gem58jl9.net
- これって暗号が解読されてるのかな…
あれだけだと、 winny network に偽の node として参加してるようにも見えるけど。
参加できれば、検索とかの query 読んで、その関連する packet 落とす…とかもできるだろうし。
- 271 ：login:Penguin：04/02/18 13:47 ID:INzA8wD0.net
- ふつーに、どこかの板に、不完全なソースコードが転がってます。
ソースコードの中には埋め込まれた暗号鍵も付いてます。
- 272 ：login:Penguin：04/02/18 18:34 ID:ysm3TANi.net
- Winny は相互接続する時に相手で本当に Winny が動作しているかどうかの確認
と、回線速度情報、クラスタワード を交換します。どうもその時の情報をデコー
ドするのに成功したようですね。通信内容は無理っぽい。
Netagent で公開されてる資料の13ページ見ると手がかりがありますな。
- 273 ：login:Penguin：04/02/19 21:44 ID:YUXcILLr.net
- どっちにしてもKとACCSは完全なソースを持っている。
- 274 ：login:Penguin：04/02/27 19:11 ID:OzDpoA/F.net
- もまいら、winnyはいよいよ駄目だぞ。
http://www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html
暗号さえもっと強固なものだったら良かったのかね?
- 275 ：login:Penguin：04/02/27 21:00 ID:WZTEm3ZQ.net
- だから暗号と匿名性は無関係だとなんど言えば。
- 276 ：login:Penguin：04/02/28 22:34 ID:S72mqHhA.net
- >>275
>杉浦氏は、1個のパケットを見て、どこから来たものか解析することはある程度可能だと話す。
>「たどっていけば、1次配布先も分かるだろう」（杉浦氏）。
と言ってるからだと思われ。
ただ、
>「ソースコードを見たり、パケットを解析したりしながら、試行錯誤してデータを逆アセンブルしていった」（同氏）
最初は、ソースは入手していないメモリ解析と書かれていたと思うのだが
この辺の供述が曖昧な辺りが、この記事で発言している人物の信憑性に疑問を持たせる。
- 277 ：login:Penguin：04/02/28 23:51 ID:WXc+IhON.net
- >>276
まぁ、本人はその筋では結構有名な人だから、技術者としてはどっかの
ネットアークと較べればかなりまともな筈。
逆アセしたソースを見たと言ってたんじゃないかなぁ。データを逆アセ
するってのもなんか表現が変。この記者の信頼性もいまいちなので...
ttp://aki.nekoruri.jp/diary/200401c#D30_5
- 278 ： ◆HO0OFh2RXI ：04/02/29 06:48 ID:lTwPvcXw.net
- 原案
Winnyのオープンソース化を考えるスレ
http://winny.info/2ch/misc/1056020225.html
http://pc.2ch.net/test/read.cgi/linux/1056020225/354-
354案にいろいろと混ぜてみたものです。
細かいチャンクにする、通信にはコストがかかるとする、というのが基本です。
自分のUp/Downしたいものは隣のノードが欲しがっている/持っているとみなして行動。
Winnyの転送の多い時期で転送リンクブチブチ状態のイメージ。
やればやるほどFreenet…効率がとても悪そうです。
とりあえず置いておくんで好きにしてください。
- 279 ：login:Penguin：04/02/29 06:49 ID:lTwPvcXw.net
- ☆ネットワークを流れる情報は、すべてにIDが振られた小さなチャンクに分割される。
このIDは、内容により決められネットワーク上一意とする。
☆チャンクは2種類あり、書き換え可能なチャンクと内容が保護されたチャンクである。
書き換え可能なチャンクを回覧板、内容が保護されたチャンクを小包と呼称する。
★回覧板チャンクのIDは、内容のテーマにより決められ、内容に関知しない。
★小包チャンクの内容は公開鍵暗号を使用し、暗号化する。
そのIDは、暗号化済みの内容(鍵を含む)ともともとの内容の両方のハッシュに依存し、
それぞれ確かめ得るようにする。
☆すべてのチャンクのやり取りにコストを設定する。
正のコストのチャンクを受信すると、送信ノードに対し、送信債務が発生する。
要するにUpしてもらえる権ということです。
コストは、取引開始側が設定し、取引了承側が認証する。負のコストも許される。
言い値で決まるが、不満であれば取引が成立しない。
虚偽の取引を行った場合は直ちにリンクを切断し、以降の取引は行われない。
すべてのノードは、送信債務という借金状態を解消しようとすることが要請される。
つまり基本的にはDownすればUpすることが要請されます。
あるノードが借り逃げを行った場合、または著しい債務超過に陥った場合、
悪質ノードとして切断し、以降の接続を一定期間禁止する。
大きい値のコストの取引は、取引実績ができるまで行われない。
☆ファイルを流す際は、適当なサイズに分割しそれぞれを小包チャンクとする。
それぞれの小包のIDとその鍵のリスト、及び元のファイルの識別情報（ファイル名、元ハッシュなど）を
まとめて小包チャンクとし、フックチャンクとする。
このフックチャンクはWinnyでいうところの仮想キーに相当するヘッダ部分である。
★フックチャンクは、自ノードでは特別に処理が行われ、元ファイルの識別情報と対応がつけられている。
外部に対しては、直接指定された場合は単なる小包チャンクとして振る舞う
- 280 ：login:Penguin：04/02/29 06:49 ID:lTwPvcXw.net
- ☆チャンク情報の拡散
検索ワードを指定した回覧板チャンクをつくり、これを検索チャンクとする。
検索チャンクには、指定ワードと関連するファイルの、元ファイル識別識別情報とフックチャンクIDのセットが
リストになって入れてある。
受け取ったノードは、リストをフックチャンクプールに格納し、自分の情報を混ぜた上で再び検索チャンクを形成し
隣接ノードに転送する
☆チャンクの予約
タグワードを指定した回覧板チャンクをつくり、これをオークションチャンクとする。
オークションチャンクには、要求チャンクIDと取引成立時の予定コストとUp/Downのリストが入れてある。
受け取ったノードは、リストを来たノードをマークした上でオークションチャンクプールに格納する。
自らのダウン予約の都合を考えて、オークションチャンクを入れ替え、隣接ノードに転送する。
☆チャンクの取引
オークションチャンクの情報を元に、Up/Downの要求が一致すれば、送ってきた隣接ノードに取引要求する。
要求内容は、対象チャンクID･Up/Downの別･成立時の支払いコストとする。
要求を受け取ったノードは、以下の3つから行動を選ぶ
★要求を受諾し、チャンクを移動し、完了後コストが移動される。
★要求を拒絶する。
★要求は拒否するが、他のノードを紹介する。
検索チャンク、オークションチャンクも同様に扱う。
- 281 ：login:Penguin：04/02/29 06:50 ID:lTwPvcXw.net
- ＜データ入手までの流れ＞
ファイル名 →フックチャンクプールから検索(なければ検索チャンクで底引き)
→フックチャンクをオークションチャンクで予約→取引成立すればDown→展開
→内容チャンクを順次オークションチャンクで予約→取引成立チャンクからDown
→すべて揃い次第元に戻す
＜オークションチャンクと取引コスト＞
☆あるチャンクが欲しい時、大きいコストを設定してDown予約をかけると、
成立の可能性が高くなる。
所持ノードがUpしたときの利益が大きいので応じることが予想されるからである。
しかし、あまり大きいと新参者小取引の原則により無視される。
また、中間ノードが中継して(もっと小さいコストで元ノードから入手し)利益を得ようと
するので効率が悪くなる。
☆あるチャンクのDown予約が隣から流れてきた時、そのノードに対して債務がある場合、
自ら率先してそのチャンクを入手することが望まれる。
先に手に入れることができれば、そのノードに対しUpを行い借りを返すことができるからである。
☆オークションチャンクの転送時に予定コストを書き換えることで、転送利益を得ることができる。
☆あるチャンクが欲しい場合、Downで正のコストを設定する。
誰かが欲しがっているチャンクをUpする場合、Upで正のコストを設定する。
オークションチャンク、検索チャンクなどのどうしても受け取って欲しいチャンクを
Upする場合、Upで負のコストを設定する。
☆負のコストのUpを利用して、仮想アドレスタグをつけた小包チャンクを投げることで
IMのようなノード間通信が可能かも。
このとき、間のノードはコストの絶対値を少しずつ減じていくことで、利益を得ることが
できるのでコストに対し十分近ければ届く。
★所持チャンクのコスト評価値
Upする時のコスト目標値。有用だと自らが判断するチャンクに対しては高くつけておく。
需要が多ければ上げ、なければ下げる(でないとDownする人がいない)。
- 282 ：login:Penguin：04/02/29 06:51 ID:lTwPvcXw.net
- ＜検索およびオークションチャンクの転送経路＞
☆タグまたは検索ワードと、クラスタ化キーワードとの優先度比較で大きいノードに転送されやすくする。
☆送ってきたノードに直接返してはいけない。(取引の不正を防ぐため)
☆チャンク転送利益を得られないほどコストの絶対値の下がった、自分に不要なチャンクは破棄してよい。
＜ノードの接続条件、切断条件＞
(考え中)
☆クラスタワード制により、意図的に移動できるようなネットワーク距離を導入し、
近いノードに優先接続する
☆取引実績のあるノードは優先する
☆取引に嘘ついたノードは即切断、(覚えていられる限り)二度と許さない。(周りに伝達するかも)
☆取引がこちらの赤字の場合できるだけ切断しない
☆(主観基準の)大規模な借り逃げは、以降の接続を蹴る。(周りに伝達するかも)
☆ある程度の借りっぱは、次に接続した時に払ってもらう。動的IPの誤爆は気にしない。
☆小規模な貸し借りは、水に流す。
☆貸している側はいつでも切断できる。
- 283 ：login:Penguin：04/02/29 06:51 ID:lTwPvcXw.net
- ＜利点＞
☆2者間の通信のみで、不正ノードを判定できる。
☆部分キャッシュであるチャンクに価値をもたせられる。
☆チャンクそれ自体は、単独で意味を持たない。
☆チャンクの取引コストを、信頼度、優先度として準用できる。
☆チャンクを所持していることは、内容を知って公開していることを意味しない。
(中の人の判断基準は取引に有用であるかどうかのみ)
＜問題点＞
★大きいファイルの時チャンクが揃わない可能性。
★ネットワーク上の自分とその周りのノードが興味を持つチャンクすべてを把握する必要がある。
★膨大な数のチャンクの取引の必要があり、ネットワークが飽和する危険がある。
★検索がかけにくい。
★同一ファイル複数キャッシュ問題。暗号化キーが異なるチャンクは互換でない。
- 284 ：補足考察：04/02/29 06:52 ID:lTwPvcXw.net
- ★ネットワーク的に価値をもたないチャンクの排除
フックチャンクの場合(ファイル名詐称など)は、無視リストを使用して所持しない、転送しない。
優良フックチャンクを高く評価し(取引コストを上げる)、相対的に排除。
平チャンクの場合、内容の評価は不可能。高値で取引できるのなら、中身については関知しない。
ゴミチャンクは意図的にDownをかける香具師がいない限り、コスト値が高いまま取引されることはない。
ローカルでチャンクの保持基準をコスト評価値と最終アクセス時を元に決めればそのうち消える。
★高い評価のゴミチャンクの可能性
自作自演によって可能。たとえ自分が騙されても、他に騙されるやつがいる限り
被害はない。平チャンクがどこのファイルの所属なのかをたどる方法は存在しないので、
アクセスがある限り消えることがない。
消える可能性は、Winnyでいうところの完全キャッシュのみにする操作をノードが
行うであろうこと。
HDDに余裕があるのならどうぞ飼ってやってください。
★優先度の詐称
高値のチャンクをUpすることが一番効率のよい方法。
★接続ノード限界
Upするノードの不足がもたらす。落としたいファイルを持つノードの優先接続条件に
適合するようにすれば回避できる。つまり熱心に奉仕汁
- 285 ：login:Penguin：04/02/29 06:53 ID:lTwPvcXw.net
- ★初期開放ノードの隠蔽、その必要性
フックチャンクが出回らない限り、平チャンクのアクセスは困難。
そのため、どうしても身元を隠蔽したいデータをUpする際は、自作自演をかけ
周りにチャンク単独での価値を知らしめ、拡散した後、フックチャンクを公開する。
自作自演にはコストがかかるので、どうしてもの時だけに。
Down要求を蹴って他のノードに回して、かつ、その他ノードに対しUp要求をかけると
隠蔽できるかも。
★Port0(外部からの接続不可)の取り扱い
未定
★大量のファイルの保持者の負荷
チャンクの要求があったとき、所持チャンクから検索しなければならない。
ファイルをネットワークに投入する際、ハッシュ計算で時間がかかる。
★IPをさらした上での匿名性
隣接ノードがUp要求をかけた際に、所持チャンクが確定できる。
ただし、これはファイルの所持に直結しない。
- 286 ：login:Penguin：04/02/29 06:53 ID:lTwPvcXw.net
- ★IPの変わる常時Up優良ノードの取り扱い
あまり長時間同一ノードと取引することは推奨されない、ノードの評価の保持は
一定期間であるということから、固定IPと比べ不利益はない
★繋ぎなおしでマイナス評価が消える
ネットワークへの接続はかなり厳しいものとなっているので、取引に必要な
評価を得ることへの手間がペナルティとなる
★途中の中継ノードによる、検索キーの捏造/改竄
IDは内容のハッシュを元にするので、破損として処理する。
破損チャンクは取引成立ではないのでリトライが強制される。
★ファイル名の詐称
フックチャンクの評価値により排除をする
★クラスタ位置を変えることによる評価の消滅
クラスタにとって有用でないノードはいらないと考える。
たとえ別クラスタで有用であったとしても、それはそれこれはこれ。
★流通するキーの一覧を作成することによる危険
目安になることは確かであるが、実際に完成するまで本当に存在するかは確定できない。
- 287 ：login:Penguin：04/02/29 07:46 ID:KT/zUJUZ.net
- おお！？ Linnyプロジェクト再起動か！？
- 288 ：login:Penguin：04/03/01 21:27 ID:rhb6VIeO.net
- すでにバッテリーもへたってるから、腐った燃料では動きもしない･･･と。
- 289 ：login:Penguin：04/03/02 00:45 ID:9lmYd62z.net
- >>278-286 まで読んで見たものの、言葉だけではボンヤリとコンセプトだけで
具体的な手続きの順序とか、階層とかそういったものが共有できない…
それぞれ得意な分野を分担して実装すれば、ソース公開の意味があって
いいと思うんだけど、誰が何から実装するのかという、
最初の取っ掛かりがあればねえ。
俺も含めて他力本願なんだろうけど。
- 290 ：login:Penguin：04/03/02 02:33 ID:9lmYd62z.net
- 次期P2Pの仕様 part9
http://tmp2.2ch.net/test/read.cgi/download/1075400646/
需要として参考になるのかな。
- 291 ：login:Penguin：04/03/02 23:46 ID:j+7Rtc66.net
- freenetのNGRが良い感じ。
- 292 ：login:Penguin：04/03/09 02:54 ID:lz/xxrRp.net
- >>290
ちょうど今、これ>>278-286と似たようなことが話題になってるな。
サーバを置くのが効率的には絶対にいいと思うんだけど、いろいろと問題ありそう。
eDonkeyが価値評価を導入してるらしい。参考になるかな
- 293 ：login:Penguin：04/03/13 02:35 ID:it57ICZi.net
- せっかく>>290のスレで課金可能性について論じられていたので278案での実現可能性について書いておきます。
ネットワーク内で使用している取引コストとして、現実世界のお金を使用することで課金できると思います。
ただしこの場合、信頼できる通貨サーバが必要ですが。
内容は暗号化し、ネットワークに流しておきます。
フックチャンクを2種類用意し、1つは集めることはできるが復号はできないもの(不完全フックチャンク)、
もう1つは復号できるもの(完全フックチャンク)とします。
不完全フックチャンクは通常と同じに流通させますが、完全フックチャンクは特殊な取引によってのみ流通させます。
内容が欲しいノードは、通常の手順で不完全フックチャンクを元に、パーツをそろえます。
次に、完全フックチャンクを持っているノードと、通貨サーバと通信できる状態にします。
チャンクの取引には、通常だと取引コストとしてDown権を渡すわけですが、完全フックチャンクの取引には
通貨サーバによる支払い証明を取引コストとして渡すことになります。
この取引において、完全フックチャンクを所持しているノードが正規の手続きなしに流してしまうと
そのファイルに対する課金が崩壊してしまいます。
転送報奨としていくらか分け前を与えるとか、完全フックチャンクに所持ノードIDを書いておくとかしか
思いつかないんで、他にもっといい方法があるかも。
- 294 ：login:Penguin：04/03/31 06:32 ID:HoAkMBXl.net
- winny3を作ろうよ
http://tmp2.2ch.net/test/read.cgi/download/1080239741/
- 295 ：login:Penguin：04/04/02 00:21 ID:WpkuJ3NS.net
- とりあえず厨が入ってこれないようにしたい。
- 296 ：login:Penguin：04/04/02 09:14 ID:WTKLrf8O.net
- winnyの英語版が欲しいです。
私はあなたの支援を必要とします。
- 297 ：login:Penguin：04/04/02 09:41 ID:j4zdC+mr.net
- >>296
板違い
- 298 ：login:Penguin：04/04/17 01:58 ID:JW5Fbu01.net
- sage
- 299 ：login:Penguin：04/04/30 03:21 ID:1Mr+A9gw.net
- age of Linny
- 300 ：login:Penguin：04/04/30 07:37 ID:F2pqcMu3.net
- >>297
韓国人にそれは通じないだろう
- 301 ：login:Penguin：04/04/30 07:42 ID:MoJY09XL.net
- >>300
韓国ってのもいいかげん飽きたなぁ。
- 302 ：login:Penguin：04/05/01 00:01 ID:rQWDA2uP.net
- >>301 三国人で無問題
- 303 ：login:Penguin：04/05/10 14:12 ID:gOkOLaIk.net
- ４７氏の釈放を訴えるＯＦＦ
http://off2.2ch.net/test/read.cgi/offmatrix/1084137851/
４７氏の釈放を訴えるＯＦＦ
http://off2.2ch.net/test/read.cgi/offmatrix/1084137851/
- 304 ：login:Penguin：04/05/10 18:11 ID:zyDxrivK.net
- 結局、535氏の途中断念が正しかったのか？
作ったらﾀｲｰﾎだろ？
- 305 ：login:Penguin：04/05/10 19:28 ID:1n9r+xb3.net
- 違法逮捕だとは思うが、nyには興味ないので無視。
- 306 ：login:Penguin：04/05/10 19:31 ID:1n9r+xb3.net
- EFFに通報すれば取り上げてくれるだろうけど、誰も英文メールが書けない。
- 307 ：login:Penguin：04/05/10 19:33 ID:1n9r+xb3.net
- 海外に情報が漏れないように英語の記事を載せないようメディア統制済。
- 308 ：login:Penguin：04/05/10 19:34 ID:1n9r+xb3.net
- でも本家/.にタレコまれててアウト。
- 309 ：login:Penguin：04/05/11 02:44 ID:B6Rf6hGv.net
- >>305-308
これ作ってる人が本家/.タレコミ者だな
http://exe.adam.ne.jp/dice/index_j.html
http://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.net
- これが本当のオープンにしなかった理由だしょ。
http://headlines.yahoo.co.jp/hl?a=20040511-00000018-kyodo-soci
- 311 ：login:Penguin：04/05/11 15:01 ID:Hq1OSHfm.net
- というか、Winny-DOMを使っていないと考えるほうが不自然
- 312 ：login:Penguin：04/05/12 03:19 ID:q0cG20qw.net
- 別に数千から数万のノードがいる中で、百以下のノードが不正しても問題はない設計だろう。
不正ノードがいることではなく、多数を占めることを恐れてオープンにできなかった。
- 313 ：login:Penguin：04/05/12 21:24 ID:dBKDTYWN.net
- とりあえずさ、リリーススタイルを考えた方がいいと思う。
俺としては、tar.bz2にソースをまとめて海外の匿名串経由でuuencodeしたものを
2chに書き込む。これで完璧。
- 314 ：login:Penguin：04/05/14 03:25 ID:b19TtUOi.net
- 最初からFreenet上で開発宣言してリリースも全部そっちでやった方が良いよ。
- 315 ：login:Penguin：04/05/14 17:50 ID:7U9iS7RX.net
- 開発元を秘匿するのは、最初からやましいことやってるという表明にしかならん
と思うのだが。
- 316 ：login:Penguin：04/05/14 18:17 ID:uTjxhWEO.net
- >>315
今回のような、万が一の為の回避策ですよ
- 317 ：login:Penguin：04/05/14 19:09 ID:J6S3sDkg.net
- 今回の件って、しかるべき結果なのでは？
ﾀﾞｳｿ板というグレーなものを扱う場所で動作確認をしているわけで。
- 318 ：login:Penguin：04/05/14 19:55 ID:H+W+NZc7.net
- 仕様用途を「LinuxのISO共有」にしとけばとりあえずOK
- 319 ：login:Penguin：04/05/14 21:28 ID:uTjxhWEO.net
- >>318
ISOファイルの共有は是非やりたいよね。
- 320 ：318：04/05/14 23:42 ID:ncaoYmUz.net
- そういいつつFTPインストールをしていたりするｗ
FedoraもFTP+GUIでインストールできるようになってたし。
- 321 ：login:Penguin：04/05/15 11:22 ID:RVJL99XP.net
- >>318
なら匿名性は必要ないから BitTorrent で十分。
- 322 ：login:Penguin：04/05/17 20:36 ID:HO4EIYRj.net
- ついにWinnyのソース公開！＠プログラマー
http://pc5.2ch.net/test/read.cgi/prog/1071794941/l50
- 323 ：login:Penguin：04/05/17 21:12 ID:+ZgvpoAo.net
- >>321
その通りだが、
日本発のものが欲しい。
Winnyの使いごごちが捨てがたい。
署名性はおれも要らないと思う。
発信元がみえれば違法ファイルは流せなくなるからな。
- 324 ：login:Penguin：04/05/17 21:12 ID:KQNT3jUC.net
- 署名性?
- 325 ：login:Penguin：04/05/17 21:20 ID:+ZgvpoAo.net
- ゴメソ
->匿名性
- 326 ：login:Penguin：04/05/18 14:19 ID:lZIh8sQE.net
- 今さらだが作者がneko氏だった事にびっくり。
- 327 ：login:Penguin：04/05/18 19:32 ID:5c9Ys/Tj.net
- Linnyも535氏が本気だったなら結構楽しめるものに仕上がっていたと思うが。
- 328 ：login:Penguin：04/05/22 17:22 ID:nqTAVPpu.net
- http://linny.winny.info/
- 329 ：へりくつ星人：04/06/27 16:41 ID:o/ZzpKCM.net
- 表現の自由を守るため、
匿名性はぜひ必要です。
- 330 ：login:Penguin：04/06/27 19:56 ID:TW8O336t.net
- 匿名にすると荒れるからね…
- 331 ：login:Penguin：04/07/01 17:19 ID:hhBC6xMz.net
- 言論の自由が保障されている国に住みながら、表現の自由のためとは何事？
違法行為をしたいだけじゃないのか。
- 332 ：login:Penguin：04/07/01 19:30 ID:nV7KzNbc.net
- >>331
個人情報保護法案を濫用されるようじゃだめぽ
- 333 ：login:Penguin：04/07/02 00:22 ID:23tKNoDx.net
- 破壊活動防止の名のもとに、いわゆる盗聴法案で通信の傍受が行われ、
米国のテロ対策のためにエシュロンによる一方的な傍受が行われています。
別に、身元の安全を保証されて訴えたい事は今の所無いわけですが、
だからといって因果関係の説明がハッキリしない幇助罪の濫用を認めると、
他の法案との兼ね合いから恐ろしいことになります。
通信の機密を高める研究がおざなりだった事が、太平洋戦争の作戦面での
敗因をいくつも作っているし、日米自動車会談での米側の通信傍受によって
経済的な敗北を招いた事もあり、国益の面から考えても重要な課題です。
逆に、犯罪者が使う事も考えられますが、まず個人をマークできていなければ
通信の内容をクリアにした所で防ぎきれないのは911が証明してしまいました。
殆どの犯罪捜査の面で、通信の強度が最大の問題になりえないでしょう。
計画的な犯行の内容を知りながら、止める事が出来ないのですから。
- 334 ：login:Penguin：04/07/12 13:39 ID:oP37bQUb.net
- この手のはどこいったんだ？
- 335 ：login:Penguin：04/07/13 01:13 ID:Wjb7ht7F.net
- ここで相談しているだけで幇jy(ry
- 336 ：login:Penguin：04/07/13 03:12 ID:UBZ1ootY.net
- 凶吐腐刑様が見てる
- 337 ：login:Penguin：04/07/20 09:21 ID:uwPwIKQc.net
- >>333
アホくさ！警視庁、警察庁公安部が所謂、盗聴法に基づいて、
主なプロダイバのサーバー横ににメール盗聴用のＢＯＸを設置してますが、なにか？
あのなぁエシュロンどうだとかより、足元の公安部のほうがタチ悪いんだけどねｗ
マルタイ対象者のメールは事実上、筒抜けというのがホントのとこ
そういうこと理解してないだろ！！ｗ
- 338 ：login:Penguin：04/07/20 12:06 ID:ZHO2cB4v.net
- 俺のメールも盗聴してもらえるようになりたいものだ。
- 339 ：login:Penguin：04/07/20 14:21 ID:NLHpUOa+.net
- GnuPGはどうやって解読しているのやら。
- 340 ：login:Penguin：04/07/20 16:40 ID:Ir/Sk1kn.net
- 実際のところ暗号化してメールしてる香具師なんてごく少数。
一番DQNだと思うのはSSLで住所とか入力させて、
確認用にふつーのメールで入力した住所とか送ってくるサイト
そういうサイトに限ってSSL対応だから絶対安心です、とか意味不明なことが書いてある。
- 341 ：login:Penguin：04/07/22 04:23 ID:CHk2gMcm.net
- i2pはどうよ？
- 342 ：login:Penguin：04/07/31 03:03 ID:74tIdb2R.net
- >>337
先頭の段落だけに反応してもしょうがないが、タチが悪い良いの話ではなく
ツツ抜けにしたところで分析を間違えれば防げないという話でせう。
「マルタイ対象者のメール」の絞込みから、内容の解読まで、エシュロンに
関わってる人間の多さ優秀さに比べればザルなんだろう…と、
長官狙撃事件の起訴見送りなんて大失態から伺えるなあってこったな。
ま、置いといて。
P2Pは悪くない，事業者が考えるべき策はまだある
ttp://itpro.nikkeibp.co.jp/free/NCC/INTERVIEW/20040728/147832/
興味深いのがYBBネットワークを設計した人ってところ。
- 343 ：login:Penguin：04/08/05 22:23 ID:XEhm8+iR.net
- P2Pとネットワーク技術の未来にあるもの
ttp://blog.japan.cnet.com/kenn/archives/001457.html
- 344 ：login:Penguin：04/08/06 09:58 ID:aRUsbpKu.net
- キンタマで例のファイル見た。京都府警って素敵。w
しかもファイルを回収しようとしてるらしいからもう最高。
- 345 ：login:Penguin：04/08/10 10:50 ID:thjax6dy.net
- Torで書き込みテスト
- 346 ：345：04/08/10 10:50 ID:thjax6dy.net
- んで、もう一回書き込んでみると…
- 347 ：345：04/08/10 10:51 ID:thjax6dy.net
- うまく使えてないっぽい…
- 348 ：login:Penguin：04/08/10 11:13 ID:thjax6dy.net
- テスツ
- 349 ：login:Penguin：04/08/10 12:17 ID:DncnYLgd.net
- >>345-348
しっかりやれ (^^;
ていうか、/.jp への書きこみによると 2ch は対策を進めてるってことだけど、
それは関係ない?
http://slashdot.jp/comments.pl?sid=201620&cid=602988
# オレは今のところ興味なくて、2ch の関連スレは読んでないけど。
- 350 ：login:Penguin：04/08/10 21:11 ID:KaowJ+lx.net
- ssh で使うときは socks 対応で(sshを)コンパイルし直さないと駄目なん？ > tor
- 351 ：login:Penguin：04/08/15 02:55 ID:xoy5jEX1.net
- 【信州大学】P2Pソフト MARIE【新進気鋭】
http://tmp4.2ch.net/test/read.cgi/download/1091445496/
- 352 ：login:Penguin：04/09/08 16:24 ID:q40OB9ny.net
- 保守
- 353 ：login:Penguin：04/09/19 16:25:54 ID:InKV6cb8.net
- そういえば、昔このスレに47氏がカキコしてくれたなぁ。
ってことは、テレビに出たあの人もLinnyという言葉を知っているのか。
なんかすごいな。
- 354 ：login:Penguin：04/10/19 13:05:06 ID:xgM0KVMN.net
- >>351
某エロゲーメーカーのスクリプトエンジンと同じ名前だね。
- 355 ：login:Penguin：04/10/19 19:15:22 ID:vSo4KyTx.net
- Linnyはデーモンになるんですか？
- 356 ：login:Penguin：04/12/17 15:48:25 ID:QCBUlcCx.net
- >>355
その前提で只今開発中です。
- 357 ：login:Penguin：04/12/17 20:19:22 ID:Caiw6Ncr.net
- >>356
通報しますた
- 358 ：login:Penguin：05/02/19 09:27:04 ID:BJUsIJg+.net
- よーし、パパsystem3.5って言うP2Pソフトつくっちゃうぞ〜
- 359 ：login:Penguin：05/02/19 18:04:42 ID:crB44SZQ.net
- 国産、linux ｐ２ｐ ソフト！！
期待します
- 360 ：login:Penguin：05/03/04 10:20:03 ID:UoO0prm/.net
- ファイル共有無くていいからLinnyBBS作って欲しいYO!!
- 361 ：login:Penguin：05/03/05 03:15:03 ID:Jm1oAewG.net
- 実質、ファイル共有部を利用してBBSのデータをやり取りしてるから
結局は両方実装しなければならない…
- 362 ：login:Penguin：05/03/09 13:40:49 ID:PMkWko3y.net
- あのー
ずーっと待ってるんですけど。
- 363 ：login:Penguin：05/03/09 16:37:12 ID:ufK0IMdA.net
- >>362
だから何だ？
- 364 ：login:Penguin：05/03/09 16:44:39 ID:PMkWko3y.net
- >>363
まだー？
ってこと。
まあ、おまえには関係ないと思うけど。
なんでしゃしゃり出てきたの？
- 365 ：login:Penguin：05/03/09 17:41:52 ID:JUJhub6J.net
- バカ
- 366 ：login:Penguin：05/03/09 22:26:36 ID:6CE5KbUl.net
- 待ってるだけじゃねぇ。
- 367 ：login:Penguin：05/03/10 03:47:15 ID:PPPryd0b.net
- なんか伸びてると思ったら…
BBS関連だけでも抜き出せないかとソースのようなものさんのを参考に見てみたけど
結局自分で書き直さないとぐちゃぐちゃだし、
共有関連も持ってこないとBBSデータのやり取りもできなさそうなので、めんどくなった。
これ解析するくらいなら、新しいの設計した方が速い気がしてやる気がでないし。
誰かやらないかな…
- 368 ：login:Penguin：05/03/12 15:33:17 ID:AtiTv2c3.net
- winnyのlinux版があれば全て解決。
- 369 ：login:Penguin：05/03/14 05:37:26 ID:0YyTOLGz.net
- >>368
47氏にでも依頼するのかい？
Linux版とかは作る気はない、とか言ってた気がするけど。
- 370 ：login:Penguin：05/03/15 15:43:32 ID:fvSF73Mo.net
- 厨房避けに最適なのに
- 371 ：login:Penguin：2005/03/22(火) 20:38:19 ID:yam08RNP.net
- wikiは見れなくなっているのだな
- 372 ：login:Penguin：2005/04/10(日) 14:23:26 ID:Qg6Yp9sw.net
- Winnyをソース化しよう
http://tmp4.2ch.net/test/read.cgi/download/1071258282/
ここか。
- 373 ：login:Penguin：2005/04/19(火) 20:18:53 ID:QwGOconk.net
- >>369
オープンソースで成り立てばLinux版も可能といっていた。
- 374 ：login:Penguin：2005/04/19(火) 20:28:15 ID:iza5jbtz.net
- 要は暗号化と匿名化するのにソース非公開の方法しか
思い浮かばなかったんでしょ？
暗号化はともかく、
匿名をオープンソースで実現することは可能なんだろうか。
- 375 ：login:Penguin：2005/04/20(水) 00:08:19 ID:1AqW0Nsw.net
- 暗号化も匿名化も出来る(っていうか暗号化は匿名化の手段でもある)が、
クラック避けが難しいって事じゃなかったかな>オープンソース化
- 376 ：login:Penguin：2005/04/20(水) 00:42:36 ID:8LKPMmt8.net
- ソース公開の匿名化はFreenetが(ry
- 377 ：login:Penguin：2005/04/20(水) 10:38:18 ID:kXbvBhdm.net
- ソース改変しても
相手の IP とか探ることはできないようになってるの？
- 378 ：login:Penguin：2005/04/20(水) 14:52:19 ID:eT3XmLKY.net
- >>377
おまいさん、通信相手のIPアドレスがわからずにどうやってTCP/IPの通信をするつもりだい
重要なことは、誰が何を公開しようとしたかがわからないことであって、
誰が何のデータを持っているかは(プロクシ動作のために)意味を持たないと思う。
- 379 ：login:Penguin：2005/04/23(土) 11:56:45 ID:wBX6QwFp.net
- >>377
nyの一番重要なところは、プロクシ動作であり、流れるデータが常にキャッシュされるところ、
そのためキャッシュだけを見た時に、データが単にプロクシ動作のためにキャッシュされたものなのか、
直接的にアップしたものなのかわからない。
だから、相手が何を流してきたか？、何て事は全く意味を持たなくなる。
そのデータは相手が直接流したものなのか？単なるプロクシ動作によるキャッシュなのか？
それがわからないからだ。
もし、キャッシュに違法なデータが含まれていたとしても、法的に立件することは難しい。
なぜならば、キャッシュ動作を否定することは、ネット自体を否定することになるから。
ネット自体、データを途中にあるルータや鯖にキャッシュしながら通信が成り立っている。
そのキャッシュの中には法に触れるデータも含まれるであろう。
つまり、nyの動作はインターネットそのものであり、nyの動作を否定することは、
ネットそのものを否定することになる。
だから自分のPCのキャッシュに違法なデータが含まれていたとしても、
それだけで捕まえることは無理なのだ。
47氏はただ単に通信の手段を与えたにすぎず、nyの開発をしただけでの逮捕は違法といえる。
しかしなぜ逮捕できたか？それは47氏が著作権を崩壊させるのが目的であると、
nyの開発動機を語っていたから。つまり苦し紛れの理由で無理矢理
ﾀｲ━━━━||Φ|(|ﾟ|∀|ﾟ|)|Φ||━━━━ﾎ!!
相手のIPや通信経路が分かったところで、それが無意味だって事が
わかったかい？>>377
- 380 ：login:Penguin：2005/04/23(土) 14:09:15 ID:szBMljw1.net
- >>379
あんた弁護士かい？
47はキャッシュ動作(Upload)の違法性を認識しており、自分用にはDownload Onlyの
クライアントを作成していたと言われているが、その件についてはどうかな？
- 381 ：login:Penguin：2005/04/23(土) 14:38:53 ID:mU74wke+.net
- 犯罪に使われる可能性のある道具というのはいっぱいあるよね。包丁とか銃とか。
さらにほとんど犯罪にしか使われない道具もある。ピッキングツールとか。
犯罪にしか使われないソフトウェアというとクラッキングツールが
そうだけど、そこら辺はどうなるんだろうね。
- 382 ：login:Penguin：2005/04/23(土) 15:14:04 ID:wBX6QwFp.net
- >>381
そう、結局はそこが曖昧なままなのが問題。
犯罪に使われる「可能性」のある道具を作るのが違法ならば
インターネット自体が違法になりうるし、携帯電話だってなんだって当てはまってしまう。
最後には何も作ることが出来なくなる。
道具は使いようだからね。
>>380
つまりはキャッシュ動作の違法性も曖昧なままだ。
DLオンリーのクライアントがあったとしても、
47氏がキャッシュ動作が違法であると認識して作成したとは言えない。
それに、DLオンリーのクライアントを作成する理由は、他にいくらでもある。
本当にそんなクライアントがあったのかは知らないが・・
そもそも47氏がそんなもの使って一生懸命DLしてたと思えない。
やりたいことありすぎて時間もないだろうしな。
どっちにしても本人に直接聞かないことには推測の域は出ないので不毛。
つうか、別に違法性がどうのこうの言うつもりはなかったんだが・・・
ただ単に377があまりnyについて理解がなさ過ぎなのでレスしてみただけ。
- 383 ：login:Penguin：2005/04/24(日) 03:33:43 ID:U52lbyvj.net
- >>380
意図的に1次Upノードになることは公衆送信可能化権の侵害になることは明らかだが、
意図しない中継動作による2次以上のUpノードは明確には違法とはいえないのでは。
ただし、1次Upノードを、多数の中継Upノードの中に隠してしまうと、警察の捜査が
困難になることは認識していたと思われ。その意思が違法かどうかは微妙だが。
DownOnlyのノードがあったとしても、改造によるネットワークへの影響を調べていた
という言い訳ができたりもする。
- 384 ：login:Penguin：2005/04/26(火) 22:27:04 ID:b+Bgg3SS.net
- っていうか中継動作が違法になるんなら、海外のエロページが見える国内のゲートウェイは全部違法だろ。
- 385 ：login:Penguin：2005/05/06(金) 00:25:53 ID:fBpY2R2q.net
- 中継動作をもって、それは合法ともいえないでしょ。しかも、中継動作なんて本質の部分ではないし。
「nyの否定」=[ネットの否定」ってのもぶっ飛びすぎでしょ。
47の目的は実験かもしれないけど、一般公開の実験にしては危険側によりすぎていると思うね。
- 386 ：login:Penguin：2005/05/06(金) 10:42:22 ID:yIkyZYFZ.net
- でも端から見てておもしろい実験だったよ。
- 387 ：login:Penguin：2005/05/06(金) 20:51:18 ID:NC7j+KH8.net
- >>385
つうかさ、それを言ったら、包丁作ったら逮捕。
みたいなのはどうなのよ。ぶっ飛んでませんか？
- 388 ：login:Penguin：2005/05/06(金) 22:15:02 ID:+qWs8XmI.net
- Winnyでネギは切れそうもないので包丁は関係無いと思う。
- 389 ：login:Penguin：2005/05/06(金) 23:09:51 ID:fBpY2R2q.net
- >>388
激しく同意。
- 390 ：login:Penguin：2005/05/07(土) 02:06:55 ID:VV46m7bs.net
- >>388-389
お前ら・・・・ほんとに頭悪いんだな・・
- 391 ：login:Penguin：2005/05/07(土) 09:12:45 ID:N9jtnJjA.net
- 包丁いっぱい作って無料で配りまくるのと似てるかも。
- 392 ：login:Penguin：2005/05/07(土) 09:14:17 ID:wZZgaFg6.net
- たとえ話は脱線しがちだからほどほどに。
- 393 ：login:Penguin：2005/05/07(土) 10:07:08 ID:i/BfrLdB.net
- サリンを誰にでも使えるようにして、俺は使ってないから無罪といいはるのと同様かと。
- 394 ：login:Penguin：2005/05/07(土) 11:03:45 ID:T+EVrL8z.net
- サリンって使い道あるの？
包丁はちゃんとした使い道あるけど。
つまりnyもちゃんと使い方があって、それをちゃんと証明できるなら…
- 395 ：login:Penguin：2005/05/07(土) 13:06:54 ID:tx50SVHK.net
- 自作ポエ（
- 396 ：login:Penguin：2005/05/07(土) 16:32:40 ID:XnmIFUld.net
- ブロードバンド時代に、プロバイダのバックボーンが耐えられるかの負荷テスト(ry
- 397 ：login:Penguin：2005/05/07(土) 16:38:29 ID:hgkPuTxN.net
- >>396
おまいは、厨房ともちゃでつか？
- 398 ：login:Penguin：2005/05/16(月) 22:51:09 ID:HnJ5Ynpd.net
- ダウソ板で開発宣言したのがまずかったのかな。
- 399 ：login:Penguin：2005/06/22(水) 20:48:18 ID:GGpxtaXf.net
- 保守
- 400 ：login:Penguin：2005/06/22(水) 22:57:54 ID:rSsOc9Il.net
- 包丁でサリンを切るスレはここですか
- 401 ：login:Penguin：2005/06/23(木) 14:56:46 ID:bF+VLH9U.net
- Linny マンセー
早く作れ！
- 402 ：login:Penguin：2005/06/23(木) 18:40:29 ID:eVPle0x9.net
- >>401
言いだしっぺ（ｒｙ
- 403 ：login:Penguin：2005/06/28(火) 00:02:34 ID:/QQcXqnr.net
- すごく出来が悪かろうと、公開さえしてくれれば
2ｃｈとしては反応がすごいのにな〜需要はあるだけに
どなたか挑戦してみない？
- 404 ：login:Penguin：2005/06/28(火) 00:37:58 ID:sxypLrzh.net
- >>403
開発したら何か得するの？
- 405 ：login:Penguin：2005/06/28(火) 01:12:49 ID:Woj5she8.net
- >>404
いや、別に・・
需要ってあるよね
- 406 ：login:Penguin：2005/06/28(火) 01:35:17 ID:sxypLrzh.net
- >>405
ちゃんと市場調査してくれよな。
- 407 ：login:Penguin：2005/06/28(火) 01:39:16 ID:eyx1+LDG.net
- やはりこういうソフトはプロジェクトじゃなくて、
社会的にアレなはみだしプログラマが、社会への恨みつらみを糧に
夜な夜なせっせと書き上げて、2chで無造作にバイナリのみ公開。
自分だけ吸い上げ専用バージョンを用意してｳﾏｰ、というのが収まりが良い。
- 408 ：login:Penguin：2005/06/28(火) 01:40:30 ID:sxypLrzh.net
- >>407
根拠きぼんぬ。
- 409 ：login:Penguin：2005/06/28(火) 01:41:30 ID:n+gd5yH6.net
- やっぱオープンソースだろ
- 410 ：login:Penguin：2005/06/28(火) 16:33:52 ID:9XnSpYyO.net
- >>407
アレな人は多いけど、技術と執念がないんだな
- 411 ：login:Penguin：2005/06/28(火) 17:47:11 ID:sxypLrzh.net
- >>410
ご自分のことでつか？
- 412 ：login:Penguin：2005/06/28(火) 20:43:23 ID:yfr2aRZu.net
- オープンソースでも完全に成り立つ仕組みを考えればそれだけでも
このスレの名は売れるだろう。
WinnyにしてもShareにしても暗号鍵をバイナリに埋め込むことで
保護している。ここの部分を何とかしないとオープンソースでは難しいだろう。
- 413 ：login:Penguin：2005/06/28(火) 20:46:35 ID:n+gd5yH6.net
- いっそ暗号化部分だけ切り離してしまって、バイナリだけの動的モジュールにしたら？
- 414 ：login:Penguin：2005/06/28(火) 20:51:09 ID:yfr2aRZu.net
- それじゃあつまらなくない？
クラスタワードを鍵にするのも考えてみたけど、あんまりよくないね。
- 415 ：login:Penguin：2005/06/28(火) 23:59:23 ID:n+gd5yH6.net
- ちとつまらないかもしれませんね。
とりあえず俺はアホだが色々書籍を読み漁る予定。
- 416 ：login:Penguin：2005/06/29(水) 03:11:34 ID:HU+dn+SH.net
- >>413
隠すことによるセキュリティーは長続きしない。
根本的に、オープンでやっても維持できるシステムを構築すべき。
今までに出ているのは、ノードごとの相互監視をプロテクトにする案。
ちゃんとデータのやり取りをしているノード以外をネットワークから弾いてしまう、と。
末端同士のデータのやり取りの内容を隠す暗号化は、気分的なものと
中間ルータでキャプチャを簡単にはできなくするためだけであって、システムに
本質的に必要なものとは思わない。
Winnyのミソは、自分の保持データは、望んだものか中継なのかがわからず
機械的なプロクシとしての免責を企んでいる点。
- 417 ：login:Penguin：2005/06/29(水) 03:22:47 ID:pkrk1XKs.net
- ちゅーかx86がターゲットの時点でディスアセンブラで解析されるんだから。
- 418 ：login:Penguin：2005/06/30(木) 21:18:29 ID:70M3Hd0P.net
- Linnyのノードは完全に平等な権利をもたない。
- 419 ：login:Penguin：2005/07/03(日) 15:06:07 ID:IZCijWVL.net
- プログラマーとしてはダメダメだが、思いついたことを書いてみる。
ttp://www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html
とかをまとめて見ると
要は、トラフィック解析した時に分かる「Winnyパケット」の「振る舞い」が、
問題になる。その「振る舞い」によって、らしきパケットは限定されてしまう
１．無効なSYNパケットが多い
２．特定サイズの暗号化通信が連続する
そして、限定されたパケットの中から詳細に分析しているのである。
1．の原因は恐らく、通信しようとした時にPCの電源が切られていることが多いから。
２．の原因は恐らく「TCPの仕様」が原因である。と言うのも、大きなデータを
転送する際は、ネットワークを効率的に利用するためにMSSの最大レートで、
送られるパケットが大量に出るため、『不明なポート』から『不明なポート』へ
「不明なデータ」が大量に、「あるホスト」から「あるホストに」流れている事は
すぐに分かる。現在の仕様では、どんなに頑張ってもトラフィックを観察されると
ある程度,ファイルの流れはバレてしまう。(freenetでも同様)
- 420 ：login:Penguin：2005/07/03(日) 15:07:28 ID:IZCijWVL.net
- １．の解決方法
TCP接続前にUDPを使って、応答を待つ方法
TCP接続前にPingを使って、応答を待つ方法も考えられるが、
受信者が、Pingを切っている可能性もある。
しかし、特定のUDPパケットにICMP到達不能メッセージが多いと
結局イタチごっこになる。
そのため、ポート番号をUDP接続が成功するたびに、次回の接続を
変えてやる必要がある。
２．の解決方法
UDPで新たな、ネットワーク層を偽装するトランスポート層を作成する。
つまり、「送信元IP」を偽装するのです。
できるようになれば、freenetより外部からの匿名性は高くなるが、
資源を思いっきり喰らう、ICMPメッセージは届かなくなる、
NAPTユーザは使えないなどの欠点がある。
考えられるアルゴリズムを、書いてみる。
- 421 ：login:Penguin：2005/07/03(日) 15:08:56 ID:IZCijWVL.net
- （１）各ホストには、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：2005/07/03(日) 15:20:01 ID:IZCijWVL.net
- （７）パケットのフォーマットは、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：2005/07/03(日) 15:46:30 ID:IZCijWVL.net
- 上記の理由より、外部からの匿名性は高くなるが、
内部の「悪意あるノード」に対しては、対処出来ない。
むしろ、内部からの攻撃には非常に脆いと考えられる。
「認証」を、どのようにするか？コレが問題
- 424 ：login:Penguin：2005/07/03(日) 18:51:41 ID:I4l1Sle2.net
- 結局、プロバイダに対して偽装をするとなると、インターネットoverインターネットを
構築することになって激しく面倒。
どっちみち、むこうさんから見れば激しいUpトラフィックを打ち落とせばいいだけだし。
確か、ノードにIDを振り、自分以外の誰にもIPアドレスとの対応を明かさないで、
バケツリレーでたまたま自分のところにきたものを黙って受け取る、とかいうルーティングしてた
P2Pソフトがあったと思われ。
muteだったはず。蟻がどうのこうののルーティング手法らしい。
- 425 ：login:Penguin：2005/07/05(火) 23:27:28 ID:3m7vbi8S.net
- 現在のWinnyを鍵と暗号化ファイルを別々に管理できる仕様、つまり、
暗号化ファイルだけダウンロード、鍵だけダウンロードできる仕様にする。
このとき、暗号化ファイルのファイル名などから、鍵を連想して、P2Pネット内から、検索、
鍵をダウンロード出来ないようにする。
『鍵』をハッシュにかけた値を暗号化ファイルのファイル名にするのが妥当だろうか?
つまり、意味のある「キーワード検索」で引っかかるのは、鍵だけにする。
そして、鍵を落としたら、鍵をハッシュにかけて、再び検索クエリを流す。
理論的に、暗号化ファイルから、鍵を連想して、P2Pネット内から鍵を
落とす事は不可能になる。
鍵のキャッシュ保管用ディレクトリを、ハードディスクに物理的に1MBのパーミッションを
設定する。
ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・
一瞬で終わるぞ・・・・(w
そして、暗号化ファイルは論理的に「闇」に葬られる。
その後、暗号化ファイルは、まったく意味を成さないかと言うとそうでもない。
自分自身が、再び落としてくるファイルの中にキャッシュに含まれるファイルを
落とす可能性が高いからである。
鍵を落とすだけであれば、殆ど時間は要らないだろう。
コレだけで、匿名性は十分だと思うのだが・・・どうなのだろう?
- 426 ：login:Penguin：2005/07/06(水) 01:23:30 ID:7XIcnn6N.net
- そうか、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：2005/07/06(水) 03:31:05 ID:Vmpb7hhF.net
- Winnyの例でいうと、(といってもその時代に参加してなかったが)
暗号化キーがかけられたファイルというのがあって、暗号化キーがわからない限り
キャッシュが復号できない機能が存在してた。が、後になくなった。
消えた理由は、使われなくて不評だったから。
キャッシュですら消されてしまうのに、得体の知れない復号できないキャッシュを
残しておいてくれるお人よしな人はいなかったらしい。
簡単に復号できないキャッシュは、そういう運用をされることを考えた方がいいと思う。
なんかメリットがないか、ペナルティがないと持っててくれないと思う。
- 428 ：login:Penguin：2005/07/06(水) 16:34:55 ID:pbi5Lyod.net
- >>427
Winnyの暗号は、知っているもの同士が、集まって決めて、知らないものは
利用できなかったから、結果的に廃止になったのだと思う。
>>425の例では、クラスタワードに引っかかるのが、復号のための鍵の情報しか持っていない
キーファイルだけにして、キーファイルからハッシュなどの方法で連想できる値を元に、
再び検索をかけているので、暗号化ファイルは誰からも閲覧可能である。
キーファイルから暗号化ファイルは連想できるが、暗号化ファイルからキーファイルが
連想できない原理は、「1632412」から「偶数」であることを「連想」できても、
「偶数」から、「1632412」が「連想」できないのと同じこと。
- 429 ：login:Penguin：2005/07/06(水) 17:06:53 ID:665Lc0RY.net
- >>426
ハッシュは、128bitあれば十分か？
共通鍵は乱数で決めるとしても、衝突の危険性がない訳ではない。
キーファイルには、暗号化していないファイルのハッシュと共通鍵を
書いておき。暗号化ファイルのファイル名には、元ハッシュ値と共通鍵を
文字連結させて、決められた回数分だけ再びハッシュをかけたものを使う。
衝突の危険性は、低くなるだろう
あと、1000秒ってのは長すぎるだろ？
どうにかして、10秒程度に抑える必要あり。
こうしては、どうだろうか？
例えば、アプリ起動時にパスワード(英数字4文字で十分)を要求するようにする。
そのパスワードが書かれたファイルは、キーが保管されるパーミッションに保管される。
別に暗号化する必要はなく、昔のUNIXのpasswdファイルのように平分のままでもいい。
起動のパスワードを忘れたら、そのファイルを見ればいい。
アプリの隅っこに、「闇」ボタンがあり「闇」ボタンを押すと、
起動時パスワードをメモリに保存。
キーが保管されるパーミッションをフォーマット。
暗号化ファイルのファイル名を起動時パスワードで暗号化。
すべての設定をデフォルトにする。
- 430 ：login:Penguin：2005/07/06(水) 17:10:19 ID:665Lc0RY.net
- このときの暗号化強度は強いものである必要はないが、暗号化したかどうか
分からないようにすることが必要。つまり、ファイル名が16文字だった場合、
16文字のままでないといけない。誰かが、暗号化ファイルからデータを複合
しようとしても、ファイル名が暗号化されているかどうかは、本人しか知らない。
暗号化されていると分かって、シラミツブシにファイル名を復号して、ファイルを復号しようとしても、
500万のキーファイル
キーファイルから暗号化ファイルの連想に10秒かかる。
起動時パスワードは、数字だけ使っても10000通り。
辞書攻撃を受けても、3000〜2000年以上かかる計算になる。
ほとぼりが冷めた所で、暗号化ファイルのファイル名を復号すればいい。
起動時に毎回要求されているパスワードなので忘れることもないだろう。
起動時に要求するパスワードは、パスワードを覚えさせることを目的としているため
変えないほうがよいと考えられる。
さらに、中継ノードは暗号化ファイルはキャッシュするが、キーファイルはキャッシュしないとなどの
仕様をつけ足せば、無闇にキャッシュを消す事もなくなるだろう。自分のクラスタが特化されている場合、
暗号化ファイルの中に自分が欲しているファイルがある可能性がある。キーファイルは、1KB以下のファイル
だが、暗号化ファイルは、それよりも遥かに大きい。よって、無闇にキャッシュを消すと、逆に欲しい
ファイルを手に入れるのに時間がかかってしまう。
- 431 ：login:Penguin：2005/07/07(木) 01:25:37 ID:Wgy7DjVN.net
- キーファイルがある->キャッシュを消せる。
キーファイルがない->クラスタ化できない。
- 432 ：login:Penguin：2005/07/07(木) 05:31:46 ID:4ekhGbja.net
- >>428
キャッシュから直接に鍵が検索できない、っていう仕様であってる？
中継ノードが復号できない仕様は、中継でたまったキャッシュを消される危険性が高いと思うんだが。
- 433 ：425：2005/07/07(木) 23:38:38 ID:SQnN0+8k.net
- たぶん、>>426 >>428と同一人物です。
Linuxは使ってますが、プログラマじゃないです(SEでもないです
だから、半ば「妄想」です。
ネットワークは、多少分かるので、オープンにしてもFreenet以上の匿名性が保て、
Winnyの70%ぐらいの使い心地のプロトコル「LINNY」を提案したいと思います。
間違えがあれば、どんどん指摘してください。
間違えがなくても、どんどん指摘してください。
錆び付いたこのスレを、皆で、暇つぶしに復活させましょう(w
- 434 ：425：2005/07/07(木) 23:39:34 ID:SQnN0+8k.net
- >>431
基本的に、キーファイルのクラスタは、「自然言語」によってクラスタが特化されて行き、
暗号化ファイルのクラスタは、キーファイルから連想できる値（これを「連想鍵」と呼ぶ
ことにする）によって、クラスタが特化されて行くので、まったく『独立』しています。
ですが、キーファイルを持っているノードは、高い確率で暗号化ファイルを持っているので
探索経路は、高い相関関係はあります。
つまり、キーファイルだけを見るとWinnyっぽいけど、暗号化ファイルの検索はFreenet的になる。
>>429-430
言ってることは、全体的に面白いし参考になります。
やはり、10秒ぐらいが妥当ですね。（「闇」ボタンは実装必須?
しかし、キーファイルをキャッシュさせないってのは、意味が分かりません。
キーファイルを途中経路、暗号化するなりしてキャッシュさせない場合、
匿名性は向上するが、使い勝手は非情に悪い。
キーファイルの探索経路上に自分のノードがある場合、高い確率で暗号化ファイルの
探索経路上にもあるので、キーファイルをキャッシュさせた方が、無闇にキャッシュを
消される事もないと思います。
>>432
>中継でたまったキャッシュを消される危険性が高いと思うんだが。
その通りです。こればっかりは仕方がありません。70%ですから・・・
しかし、キャッシュされたキーファイルに対応する暗号化ファイルは、
高い確率で、キャッシュされているはずです。
- 435 ：425：2005/07/07(木) 23:41:59 ID:SQnN0+8k.net
- 今後の課題
いちいち、キーファイル用のパーティションなんか用意しないで、FDとかの
別の外部記憶に保存した方が良さそうですね。
さらに言えば、暗号化ファイル以外、メモリースティックにアプリ自体を含め全ての
データを保存した方がさらに良さそう(Linuxじゃメモリースティックは使えねーな
匿名性については、暗号化ファイルの受け渡しのみを見るとFreenetを超えていると思っています。
暗号化することで、ファイル自体に匿名性(何のファイルかわからない)があるからです。
上位ノードも、そのファイルが何かは、復号していない限りわからない。
下位ノードは、中継なのか、希望している「本人」なのか、上位ノードからは分からない。
しかし、普通にTCP使って、キーファイルの受け渡しを行った場合、匿名性はWinMX並になる。
ノード間の通信を暗号化しても、「外部」からの盗聴を阻止するだけで、内部の
「悪意あるノード」に対しては、簡単に盗聴を許してしまうからです。
そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が
提案しているような、ネットワークレベルで実現する方法を考えています。
問題点は、まだありそうな気もしますが、大枠は見えてきたので、また明日にでも書きます。
あと、「悪意あるノード」の定義や「外部からの攻撃」の定義もしていかないといけない
- 436 ：login:Penguin：2005/07/08(金) 01:49:08 ID:kxCjllha.net
- >425
＞中継キャッシュを消される
これを心配したのは、中継動作を理由にしらばっくれるつもりの仕様であれば、
ある程度の確率の中継キャッシュが残ることが必要だと思ったから。
今言われている仕様だと、中継ノードがキャッシュを持つ理由がなく
(暗号化をキャッシュから直接復号できないので、直接メリットがユーザにみえない)
キャッシュを持っているのが、放流主とリクエストした人だけという状況にならないかなと。
＞内部の情報収集ノード対策
ある程度は諦めた方がいいと思う。
あるノードがファイルを要求するときに、あるクラスタ内で情報が閉鎖的になりすぎていると
検索ができないことになる。オープンソースでやるのなら、キー情報を溜めておいて
ダウンを有利に進めようとする改良ノードが出てもおかしくない。
これらの正規の情報収集ノードと、悪意の情報収集ノードとが、システムからは
区別できないと思う。
- 437 ：login:Penguin：2005/07/08(金) 23:32:43 ID:+d41giv6.net
- 「鍵」から「ファイル」を「連想」するってあたりが、面白そうですね。
うまくいけば、本当に枠組み作れるかもしれませんよ。
>>436
>放流主とリクエストした人だけという状況にならないかなと。
勝手にレスさせてもらいますが、私はキャッシュされることは匿名性とは
無関係だと思います。
「中継」は、「誰」が「誰」に送っているか分からなくする為だけであり、
「キャッシュ」は、中継局の回線資源を有効に使うためだけに存在します。
最終的に、提供者と、もらった人だけがファイルを持ったとしても、
大事なのは、そのことが『誰にも分からない』ということです。
>>435
>キャッシュされたキーファイルに対応する暗号化ファイルは、
>高い確率で、キャッシュされているはずです。
???? そんなはずはないと思いますよ。
私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で
「まったく違う」経路をたどると思います。
理由は、暗号化ファイルのクラスタは、連想鍵が似ている方向に探索クエリを
送信し、キーファイルのクラスタは、自然言語が似ている方向に探索クエリを
送信してするからです。
- 438 ：login:Penguin：2005/07/08(金) 23:34:26 ID:+d41giv6.net
- たとえば、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：2005/07/08(金) 23:36:27 ID:+d41giv6.net
- つまり、暗号化ファイルの探索経路からキーファイルの探索経路が予測でいないので、
ファイル提供者『X』の匿名性は、Freenetぐらい高いと思います。
しかし、中継局は意味の分からないファイルをキャッシュさせられるので、使い勝手は、
Freenetに毛が生えた程度です。
特に、暗号化ファイルは中継局からすれば、わけの分からない「ごみ」です。
でも、分からないだけで、自分が落としたいファイルも暗号化ファイルのキャッシュの中にあるかも知れません。
キーファイルを落としてきて、暗号化ファイル検索したら自分の中にあったら、なんとなく得した気分にになり、
暗号化ファイルが「宝の山」に見えるような心掛けよう。
でも、そりゃ無理ですね。
>>436の言う通り、直接的なメリットは何もないので、「中継局に為らないやつは吊るし上げろ！」
(最終的に、親になってくれるノードがいなくなり孤立する)ってカンジのシステムを作るれば、
中継することを義務付けれます。そうすると、キャッシュを消してしまうと、同じ検索クエリが来たとき、
再度、回線資源を食われてしまいます。つまり、ディスク資源か、回線資源のどちらかを提供しないといけません。
ふつう、回線資源のほうが貴重(ダウンロードが遅くなるのはイヤ)だから、結果的にキャッシュを消すことも少なくなるでしょう。
>>430は、そういうことを言いたかったのではないでしょうか？
>そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が
>提案しているような、ネットワークレベルで実現する方法を考えています。
ソフトイーサを利用したIP偽装とか聞いたことはありますが、管理が面倒だし、
逆にセキュリティホールになってしまいそうな気味します。
第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは?
- 440 ：login:Penguin：2005/07/09(土) 00:05:42 ID:wPON5jd/.net
- あかん・・・パラドックスや・・・
オープンソースでセキュアなP2Pなんてやっぱ無理やで
- 441 ：login:Penguin：2005/07/09(土) 06:46:08 ID:c1VczgQE.net
- >>440
どのあたりが矛盾しているかを書くのがいいと思われ。
人はいるみたいだし、何か知恵が出るかも。
- 442 ：425：2005/07/09(土) 08:28:10 ID:yQGfiko3.net
- >>437
>私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で
>「まったく違う」経路をたどると思います。
仰る通りです。私が勘違いしていました。
クラスタの独立は、匿名性の向上には繋がりますが、中継ホストに残った
暗号化ファイルは、ホストにとってはタダのゴミ。
中継を嫌がるホストが増えるので、システム全体として中継を拒むホストを
孤立させていくような仕組みが必要になりますね。
>第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは?
一応、内部からも分かりにくい方法を考えてみたのですが、逆に攻撃の対象にされてしまうかも知れませんし、
ネットワークに負荷がかかるので止めます。
ネットワーク偽造は、また問題があったときに考え直します。
しかも、上記のような、クラスタの独立による途中経路不一致から、
十分に、匿名性はありそうですし。
- 443 ：425：2005/07/09(土) 08:47:29 ID:Aqub9gDD.net
- >>440
最終的に、内部ノードが通信相手のIPをかき集めれば、ネットワークに参加しているものが
見えてしまっても(これはしょうがないので諦めます)、「誰」が「何処」へ「何」を送って
いるのか分からなくしてしまえば、まったく問題ありません。
>>238が説明してくれているように、ファイル提供者『X』の匿名性は十分守られています。
現実世界で目を付けられるような行動をしてない限り、この匿名性が破られる事はありません。
目星を付けられていても、ファイル提供者『X』は、ローカルにあるキーファイルを消しまえば
良いだけだと思うのだが、どうだろう?(w
落とすだけの輩も、中継ホストになって貰えば、システム上十分な役目を果たしてくれる。キャッシュされなくても、そのホストさえ通ってくれれば、
良い訳ですし、キャッシュしなかった場合、回線資源が喰われて、ダウンロードが遅くなります。
他に、情報が漏れてしまうような箇所はあるでしょうか？
- 444 ：425：2005/07/09(土) 08:48:16 ID:Aqub9gDD.net
- あとは、「クラッカー」対策
このシステム最大の弱点は、情報が書き換えられたキーファイルや、悪意あるノードが
初めから暗号化ファイルをが存在しないキーファイルを大量にネットワーク内に生成し、
大量に出回ると、対応する暗号化ファイルに辿り着けないキーファイルが出て来て、
結果ネットワークが機能しないと言う恐ろしい自体が起こります。
逆に、暗号化ファイルを書き換えられたりしても、キーファイルからは辿り着けない。
この問題を解決するには、2042bit公開鍵を使った署名システムが1番確実で安直でしょう。
キーファイルには、電子署名と公開鍵が付属し、途中で書き換えが起これば、
即座に分かります。
電子署名と公開鍵が双方とも書き換えられている場合は、連想した暗号化ファイルに問題、
または、ファイルが見つからないと言う事が続くようであれば、
その公開鍵が付属する、キーファイルを一切信用しないで捨てる。
このように、公開鍵を一種のIDとしても扱えます。
これは、公開鍵の設計に時間がかかる性質を利用したシステムです。
ファイルアップ用の公開鍵は、インストール時に作成し､その後、変える必要もありません。
- 445 ：login:Penguin：2005/07/09(土) 11:50:32 ID:3O2EbHgy.net
- ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。
この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。
かといって、毎回違う鍵を使えば、署名の意味が全くない。
- 446 ：425：2005/07/09(土) 22:44:19 ID:7r68v9eE.net
- >>444の続きです
急用が出来たので、書いている途中で飛び出してしまいました。
公開鍵の暗号方式は、RSAです。
2042bitなのは、暗号の強度を上げるためではなく、公開鍵の設計を難しくするためです。
クラッカーが、大量に粗悪なキーファイル(暗号化ファイルを持たないキーファイル)を
アップしたとしても公開鍵が同じであれば、全て無視できます。
よって、クラッカーは大量に公開鍵を設計する必要があります。
2042bitの鍵を生成するには、恐らく、最低十数秒はかかるので、
クラッカーに大きな負担となります。
一方、ユーザのは悪質な公開鍵を信用しなければいいし、逆に、常に
暗号化ファイルが存在する良い公開鍵を信用すればいいわけです。
ここで、ポイントとなるのは良い公開鍵になるためには、その公開鍵の秘密鍵を知らなければ不可能である事です。
これによって、良い公開鍵の成り済ましを防げます。
この公開鍵は、変えるのも自由ですが出来るだけ変えないほうが良いでしょう。
- 447 ：425：2005/07/09(土) 22:54:49 ID:7r68v9eE.net
- さらに、キーファイルに信用性の無い公開鍵が載っていたとしても、そのキーファイル自体は良質(暗号化ファイル)が
あれば、そのキーファイルを、別の人間が電子署名と公開鍵を上書き(公開鍵と電子署名を消して書き直)します。
ただし、その別の人間の公開鍵は分かっても、その人間が誰かは、本人しか知りえません。
その公開鍵が、信用性が高い公開鍵であれば信用できます。この動作を「信用性公開鍵の上書き認証」と呼ぶ事にします。
この「認証」は誰でも出来るようにします。と言うより、理論的に誰でも出来てしまいます。
ここで重要になってくるのは、「キーファイルに載っている公開鍵 = ファイル提供者の公開鍵」の公式が
必ずしも、一致しないと言う点です。逆にいえば、ファイル提供者の公開鍵である必要性はないと言うことです。
つまり、公開鍵は「このキーファイルの内容は私(誰か分からないが公開鍵は分かる)が保障する」程度の意味しかありません。
次に問題になってくる攻撃は、信用のある公開鍵が既に上書き認証しているキーファイルを、さらに悪質な公開鍵が認証を
上書きすると言うものです。
そこで、公開鍵を検索ワードに入れることを許す仕様にします。つまり、
「ある公開鍵」と「検索ワード」を含む検索を可能にすると言うコトです。
(念のため、言っておきますが、ここで言う「信用」は、基本的に、そのノードの「経験」によるものです。
つまり、ノードは公開鍵に関する経験をデータベース化しておく必要があります)
運用しだすと、認証を専門に行う「認証屋」が出てくると思います。
つまり、これの狙いは「認証局の分散処理」です。
- 448 ：425：2005/07/09(土) 22:59:22 ID:7r68v9eE.net
- >>445
> ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。
> この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。
「ファイルアップ用」の公開鍵と別に、「ノード間経路暗号用」の公開鍵も実装させ、
これにより、外部からの参照を不可能になり、出来るのは内部ノードの情報収集のみになります。
内部のノードが可能な情報収集手段は極々限られている上、上位ノードから流れてきたキーファイルが、
中継なのかどうなのかも分かりません、トラフィックを分析した所で、キーファイルは小さすぎて、
別のトラフィックで埋もれてしまいます。
現実世界で、ボロを出さない限りまったく問題はありません。
「ノード間経路暗号用」の公開鍵は、ECC40bitあたりでどうかなと思っています。
これも、インストールした時点で決めます。(変えるのは、完全に自由です)
- 449 ：425：2005/07/10(日) 16:44:13 ID:m7iyk48S.net
- クラッカー対策に、いろいろ考えていると、かなり大掛りなものになってしまった。
とりあえず、暫定的に考えている事を、全てまとめてみる。
ノード間通信
検索、キーファイルの受け渡し ⇒ 暗号化（SSLモドキ）
暗号化ファイルの受け渡し ⇒ 暗号化なし(元々してある)
基本構成
「元ファイル」から、「キーファイル」 と 「暗号化ファイル」を生成し、
この2つを、「共有」する。
「キーファイル」は、データを元に「連想鍵」を生成し、
「連想鍵」を元に、「暗号化ファイル」を検索する。
終端ノードで「連想鍵」から「暗号化ファイル」が発見されると、そのノードは、
「暗号化ファイル」から「暗号化チェックサム・キー」を返す。
「暗号化チェックサム・キー」のキャッシュは起こりません。
(キャッシュした所で、共有できない無意味なデータになる)
「暗号化チェックサム・キー」から、「絶対連想鍵」を生成し、
「絶対連想鍵」を元に、再び「暗号化ファイル」を検索する。
つまり、
「キーファイル」(自然言語)のクラスタ
「連想鍵」(暗号化ファイル)のクラスタ
「絶対連想鍵」(信用性情報)のクラスタ
の３つのクラスタが形成され、やや煩雑なものになる。
- 450 ：425：2005/07/10(日) 16:46:00 ID:m7iyk48S.net
- キーファイルが持っている情報
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：2005/07/10(日) 16:50:15 ID:m7iyk48S.net
- 連想鍵
暫定的には、1-2),1-3)を文字連結させ、それを数千回(何回にするかは検討中)
ハッシュにかけた値。ここで使うハッシュは衝突対策で、MD5を想定している。
冗長性などの問題から、計算方法は変わる可能性あり。
絶対連想鍵
絶対連想鍵は、ノードにキャッシュされる度、毎回計算され上書きされる。2-3)をMD4で
ハッシュにかけた値を、連想鍵と文字連結させ、さらにMD5でハッシュにかけた値。
『最終的』に、この値によってダウンロードするファイルを決定する。
- 452 ：425：2005/07/10(日) 16:51:40 ID:m7iyk48S.net
- 暗号化チェックサム・キー
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：2005/07/10(日) 17:00:37 ID:m7iyk48S.net
- 訂正
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：2005/07/10(日) 17:39:23 ID:m7iyk48S.net
- >425
ソンナメンドクサソウナモンダレガツカウ？
って言いたい所だが、オープンソースってのに既に問題があるんじゃないの？
プロトコル名に「LINNY」ってのも、どうなんだ？
オープン仕様、オープンソースならば、Windowsでもいいわけだが・・・
プロトコル名は、「Anonymous Winny」をもじって、「ANONY」に一票。
- 455 ：login:Penguin：2005/07/10(日) 18:24:15 ID:hZ/9wEx5.net
- 「ONANY」
- 456 ：login:Penguin：2005/07/10(日) 23:06:13 ID:pnHySe/b.net
- まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。
- 457 ：login:Penguin：2005/07/10(日) 23:14:38 ID:kOFHOXTv.net
- 鍵の長さって、現時点で論じるべきことなのかと思うがね。
- 458 ：login:Penguin：2005/07/10(日) 23:22:09 ID:SZNYDAl1.net
- 最初は無暗号で徐々に暗号化を実装とかは？
- 459 ：login:Penguin：2005/07/10(日) 23:23:12 ID:rhhJYpWd.net
- で、コード書くやつはいるのか
- 460 ：login:Penguin：2005/07/10(日) 23:31:36 ID:kOFHOXTv.net
- リスクを背負う事無く安全に流通させる経路さえあれば誰か書くんじゃない？
- 461 ：425：2005/07/11(月) 01:33:11 ID:MZK+5YtJ.net
- >>456
>まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。
やっぱり、そう思います？
やはり、「匿名性」と「セキュリティ」と言う相反するものを同居させるには
かなりムリがでてきますね。
この世界、あまりにOSIモデルのように、厳密で繁雑なシステムは
嫌われるので、もう少し簡略化したプロトコルが必要。
簡略化をする方法の1つは、連想鍵と言う概念を無くす方法です。 つまり、
キーファイルに暗号化ファイルのハッシュ値を直接貼り付けておき、
そのハッシュ値を元に、暗号化ファイルを探す方法
詳細は抜きにして、メリット・デメリットについて。
メリット
検索は高速。仕組みは簡単なので、暗号化ファイルの改ざん対策が容易
デメリット
「暗号化ファイル」から「キーファイル」が、解かってしまう。
つまり、キーファイルがなくても、ハードディスクを没収されると、P2Pネット内から
キーファイルを落として、復号されてしまう危険性がある
「キーファイル」検索条件に制限をかけるなどの対策を取れば、ある程度OK?
プロトコル名は、>>454にあやかって「Simple ANonymous winNY」を
もじって「SANNY」なんてのを考えてみる。
- 462 ：login:Penguin：2005/07/11(月) 16:32:40 ID:/TB8jfv9.net
- 階層がわかりにくい…だれか図示してくれ…
何に対しての匿名性を確保して、何に対しての改変耐性を確保する予定なのかを
示してもらえると、もう少しわかりやすくなるかも。
連想鍵で１階層噛ましているの理由がよくわからん。
正規の検索かければ誰でも復号できるんでしょ？
攻撃側に対する耐性になってないと思う。
- 463 ：425：2005/07/11(月) 22:29:31 ID:iaGb8hb0.net
- >>462
>何に対しての匿名性を確保して
「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、
「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。
「暗号化ファイル」単体では、何のファイルで何がかかれているか、
まったく不明にするコトで、完全な匿名性を実現しようとしたもの。
要は､国が本気で動いても、よく言われる「匿名の度合い」での、
「疑いの域を出ない」(Level 5)を実現しようとしたもの。
勿論、「言論の自由」のために(w
>何に対しての改変耐性を確保する予定なのか
運用しだすと、よくありそうなのは、「暗号化ファイル」を落としてみると
どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延
キーファイルだけ作りまくる輩・・・など
- 464 ：425：2005/07/11(月) 22:33:50 ID:iaGb8hb0.net
- >連想鍵で１階層噛ましているの理由がよくわからん。
何故こんなに煩雑なものになったのかと言うと、
キーファイル ⇒ 暗号化ファイル は、分かっても、
暗号化ファイル ⇒ キーファイル は、絶対に分からなくする。
つまり、「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってはいけない。
という、前提条件があるからです。
具体的に言うと、壊れていたり、改ざんされている暗号化ファイルを ネットワーク内で、蔓延させないためには、
暗号化ファイルを キャッシュしたノードは、毎回、暗号化ファイルのハッシュを 行い、その値を公開する。
そして、検索者はそのハッシュ値を元に暗号化ファイルを検索し、
落とすと、壊れたり、改ざんされている暗号化ファイルは、
それ以上、蔓延することは無く消えていく。
これは、Freenetで実装されている技術です(ただし、暗号化はされていない)。
じゃあ、キーファイルに、「暗号化ファイルのハッシュ」を
直接貼り付けると、どう言う事が起こるでしょうか?
暗号化ファイルのハッシュ値は、暗号化ファイルから直ぐに分かってしまい、結果、
「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってしまっている。
で、こんなのになったワケ。
よく見ていただくと分かると思うが、「キーファイル」と「暗号化ファイル」は「同じデータ」を
一つも持っていません。(持っていますが、暗号化されていて分かりません)
ま、はっきり言って、私も､まともに動くとは思えない。（システム全体が重過ぎる
もう少し、使い勝手のいい、安易なものの方がいい。
- 465 ：login:Penguin：2005/07/11(月) 22:53:31 ID:/qz9fPP7.net
- ttp://s2net.s41.xrea.com/
アイデアだけはいっぱい出ているし、国内外問わず研究論文もたくさんある。
問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと
いうこともあるし
いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない
だったら誰も使わないだろう
- 466 ：login:Penguin：2005/07/11(月) 23:20:09 ID:wBE6vaKT.net
- > いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない
> だったら誰も使わないだろう
そこはオープンソースなんだから、UI は誰かが作ってくれるだろう。
通信部分は Winny の時に散々ループしてた dll なり so なりにすればいいじゃん。
- 467 ：425：2005/07/12(火) 02:03:25 ID:cTi5k0J7.net
- >>465
>問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと
確かにいえる。ノードは、全て信用できるものであれば、簡単でしょうけど
規模が大きくなれば、なるほど信用性は薄くなる。
Winnyでも、ウイルス流れたしね。
- 468 ：login:Penguin：2005/07/12(火) 11:11:49 ID:nQBkc+7e.net
- > Winnyでも、ウイルス流れたしね。
どんなウィルス？
- 469 ：login:Penguin：2005/07/12(火) 13:43:43 ID:nQBkc+7e.net
- ん？
> ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・
なんだこれ。
- 470 ：login:Penguin：2005/07/12(火) 14:16:23 ID:5JN9Gt1s.net
- >>463
＞「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、
＞「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。
「意図してダウンロードを開始した、末端ノード」に対しては、
「あるファイル(の暗号化されたもの)」であることはわかるのでは。
「意図して最初にシステムに投入した、末端ノード」に対しても
同様ではないか。
その情報がどこまで伝播してしまうか、で。
隣から見た場合、意図してダウンロードを始めたか否かで
「知っているかどうか」を知ることができるのは危険かなと。
＞どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延
「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは
実際にファイルを展開できたノードにしか判定できない。
その情報を伝播させて大丈夫かな。
それとは別に、システムで検知できる改変(チェックサムが違うとか)は
これだと弾けそうだけど。
- 471 ：425：2005/07/13(水) 00:34:25 ID:dIg+n2Qr.net
- >「意図してダウンロードを開始した、末端ノード」に対しては、
>〜中略〜「知っているかどうか」を知ることができるのは危険かなと。
言っている意味が、分かりにくいので、良ければ、具体例を上げて
その危険性を、教えて欲しえてくれませんか?。
>「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは
>実際にファイルを展開できたノードにしか判定できない。
キーファイルが、「信用」出来る場合を考えてみますと、
ハッシュ値、つまり「メッセージダイジェスト」は、データ情報の特徴を圧縮したもので、同じデータを
ハッシュにかければ、同じ値になるが、1バイトでも違うと、まったく違う値になります。
要は、ハッシュ値が一緒であればファイル内容も同じ(厳密に言うと、非常に低い確率で違う場合もあり)
であると言うことです。
つまり、ハッシュ値を元に検索を行えば、改ざんや破壊が起こっていないファイルを
探す事がで来ます。
そして、改ざんや破壊が起こったファイルは、参照される事無くいつしか消えていきます。
- 472 ：470：2005/07/13(水) 03:23:59 ID:MNJFxM92.net
- >>471
ちゃんと理解できてないんで、誤解してると思うけど。
例えば、このスレの過去ログをネットワークに投入したいとする。
投入する1次upノードは、当然内容を知っているはず。
ネットワークから、このスレの過去ログをダウンロードしようとしたノードは、
(その情報が確かなら)そのデータは過去ログであることを知っているはず。
隣接ノードに、1次upノードであること、またはダウン要求ノードであることが
(ダウン要求の内容(この場合は過去ログであること)も含めて)ばれてしまうことは、
例えどんな暗号化がされていようとも、内容を知った上で送受信しているという事になる。
これは、このスレの過去ログが発禁扱いになっていて、政府が監視中であるなら
危険なことだと思う。言論の自由を目指すんだしw
ダウン要求の内容がばれてしまうことは、ある要求をシステムでの要求に変えることと等価である。
あるファイルが落とせるってことは、投入側と取得側でなんらかの同意がいるってことでしょ。
取得するのと同じやり方で、取得方法だけ持っておいて、ネットワークを流れる要求を
監視されたらやばいんでないの、という意味。
当然中継ノードなら、内容は知らずに、P2Pネットワークとしての責務として
ただ踏み台にされただけだから、(現時点の世界では)こういう心配はしなくていいのでは、と。
- 473 ：470：2005/07/13(水) 03:32:35 ID:MNJFxM92.net
- ＞後段
キーファイルが信頼できるかどうかがそもそもやばいんで内科医ということ。
プロトコル的に、データが改変損傷してないのは保障するとして、
例でいうところの、このスレの過去ログではなく、Winny本スレの過去ログがおちてくる場合
そのキーファイルやら暗号化データはどうするのってこと。
そういうことする香具師はたくさんいるし、ミスってそうなることもあるよ。
内容知っている人にしかネットワークの暗号データは評価できないんだけど、どうやって排除すべきか。
内容が合ってるかどうかを流すことのできるノードも、情報を知っていることになって監視対象入りかも。
そういうことも含めて、誰が何の情報を知っていて、何の情報を知っていることになっていて
隠すべきものは何かな、と考えてたらよくわからなくなってしまって聞いたんだけど。
- 474 ：425：2005/07/13(水) 15:46:02 ID:OdrjvaIG.net
- このシステムは、Winnyと言うより、Freenet的だったので、
さまざまな部分で、効率が悪い。
今度は、Winnyベースの高速な匿名性ファイル共有で、特にファイル提供者の
匿名性が非常に高い物を思いついたので、まとまり次第うｐします。
(キーファイルと暗号化ファイルに分けるという点は変わりません。)
>>472
このシステムにおいて、Freenetのような、アップデートの概念はありません。
あるのは、「検索」と「ダウンロード」だけです。
まず、「あるファイル」を自分の公開領域に置き、その存在をネットワークに知らせます、
知らせる、といっても、「ここにあるよ」と言ったら、匿名性もへったくれもないので、
ネットワークに、そのファイルの「検索クエリ」を送信します。
そして、その検索クエリは、高い確率で自分のノードに戻ってきます。
その時、自分自身で返事を返してやれば、誰にも悟られずに、そのファイルを
ネットワークのクラスタに追加できます。
しかし、キーファイルのような軽いファイルであれば問題ないが、重いファイルの場合、
Freenet同様問題がでてくるので、根本的な見直しが必要
- 475 ：425：2005/07/13(水) 15:54:48 ID:OdrjvaIG.net
- >>473
まぁ、人間ミスするのでそれは、大した問題ではないと思う(笑
そう言うのは、排除する必要もないんじゃ?
問題になってくるのは、例えば『ダイエット本』で検索した時、『ダイエット本』に
関係するキーファイルが落とされます。
しかし、『ダイエット本』と書きながら、暗号化ファイルを落として復号してみたら、
何故か『サラ金の広告』だった場合は問題です。
このための公開鍵です。要は、公開鍵はIDです。信用できないIDは、信用しなければいいだけです。
（その公開鍵であれば、無条件で消す）
そして、このような信用できない公開鍵があれば、信用できる公開鍵も存在するはずです。
公開鍵は、一種のIDです。ならば、信用性のある公開鍵の「なりかわり」の心配はないか?
それは、公開鍵に対する秘密鍵が分からない限り、不可能です。
- 476 ：login:Penguin：2005/07/13(水) 18:17:25 ID:4rsiUBe0.net
- で、いつごろまで屁理屈こねくりまわすの？
- 477 ：login:Penguin：2005/07/13(水) 18:28:32 ID:+oLOISW/.net
- おまえがしびれを切らして愚痴るまで。
つまりあともう少しだな。
- 478 ：login:Penguin：2005/07/13(水) 20:32:46 ID:MNJFxM92.net
- >>474
Freenetよか遅いのは考える意味がないw
この案はこの辺りが潮時か…
＞｢検索クエリ｣
この送受信を傍受されたらどうするのって言ってるんだが。
＞公開鍵
信用できる鍵にあたるまでがんばれってか。
攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。
>>445 で指摘されてるように、固定は危険だし。
- 479 ：login:Penguin：2005/07/13(水) 20:59:14 ID:4rsiUBe0.net
- >>477
すでに愚痴ってるわけだが。
- 480 ：425：2005/07/14(木) 16:51:28 ID:5jVfH12S.net
- >>478
>Freenetよか遅いのは考える意味がないw
私もそう思います。ですが、キーファイルの通信は非常に軽いので
そのあたりで使えると思っています。
>この案はこの辺りが潮時か…
一応、暗号化ファイルの通信を独立させた、次の案があるので、
もう、暫く付き合っていただけませんか?
>この送受信を傍受されたらどうするのって言ってるんだが。
通信を暗号化したレイヤでトンネリング(SSLっぽいの)すれば、外部からのチャプチャリングは、
シャットアウトできます。
内部ノードは、自分の上位ノードと下位ノードのことしか、分からないので、
どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。
- 481 ：425：2005/07/14(木) 16:52:55 ID:5jVfH12S.net
- ・・・続き
>信用できる鍵にあたるまでがんばれってか。
むしろ、信用できる鍵の方が多くなると私は考えています。
RSA2048bit公開鍵の鍵セットを作るには、どんなに強力なマシンでも
かなり時間を喰らうのにくらべ、「除外(一切受け付けない)」のは一瞬で終わる。
「攻撃者」が、鍵セットを作り続けたとしても、どっちが不利かといえば、
圧倒的に「攻撃者」が不利。
かといって、「攻撃者」は、「他の公開鍵」に成り代わろうとしても、
相手の「秘密鍵」を、知らなければいけない。
その「攻撃者」が、RSA2048bitをクラックできるとしたら、ネットバンキングは
とっくの昔に破綻しています。
ならば、そんな馬鹿な事を実際にする香具師は、殆ど現れないはずです。
- 482 ：425：2005/07/14(木) 16:54:57 ID:5jVfH12S.net
- >攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。
上記の理由で、「なりかわり」は、理論上できません。
となれば、「同じ鍵」であれば「同一人物」です。
要は、「あなたは、何を基準に『人』を信用しますか？」ということです。
少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は
「信用できない」
5回連続で、きちんとした暗号化ファイルが存在するキーファイルの鍵は、ある程度は、
「信用できる」
って、ことです。
上記のような簡単な判断は、アプリ側に任せていいと思います。
あと、公開鍵の情報を保存しておく必要もあります。
>>445 で指摘されてるように、固定は危険だし。
外部からの、キャブチャリングは暗号化してしまえば、不可能です。
内部ノードは、上位ノードと下位ノードの事しか知りません。
その状況で、「公開鍵」の発信元を調べるのは、非常に困難を極めます。
「公開鍵」の発信元を調べるスピードよりも、ファイルが拡がるスピードの方が
圧倒的に速いからです。
一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。
- 483 ：login:Penguin：2005/07/14(木) 17:31:19 ID:D9NFH06e.net
- で、何%までできた？。机上の空論もいいけど、コード書いて実装できなきゃ
意味ないぞｗ
- 484 ：login:Penguin：2005/07/14(木) 17:39:02 ID:TU8gjza9.net
- よし、使用言語はObj-Cで決まり。
- 485 ：login:Penguin：2005/07/14(木) 18:27:54 ID:+fLeQjmb.net
- >>482
> 少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は
> 「信用できない」
これだと単純すぎると思う。
暗号化ファイルはちゃんと存在するけど、内容が期待したのと違うっていうような攻撃が来るんじゃないかな。
こういう攻撃だと、除外する側は暗号化ファイルを受信して、内容を調べて判断しなきゃいけない。
鍵を作る手間に比べて、受信した内容を確認・判断する手間って、むしろ大きいんじゃないかな。
期待通りのファイルかどうかを判断するのは、自動化が難しい問題だろうし。
- 486 ：login:Penguin：2005/07/14(木) 20:11:14 ID:PKmLnshm.net
- 実際にコード書いて検証すればいいだけだのに、
どうして机上の空論を書くのに精を出しているのだろう。
- 487 ：login:Penguin：2005/07/14(木) 21:13:19 ID:E+/HEPIn.net
- しびれを切らして愚痴りだした香具師がいるなｗ
机上の空論、大いに結構。
- 488 ：login:Penguin：2005/07/14(木) 21:20:30 ID:PKmLnshm.net
- はて。
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：2005/07/14(木) 21:35:52 ID:ey7oBSjc.net
- 425は机上の空論の妄想野郎。
>>433で本人が認めてるし。こいつ自身は実装やる能力がない。
そんな、脳ナシに標準化なんか出来るか。Freenetに任せとけ。
- 490 ：login:Penguin：2005/07/14(木) 23:14:16 ID:HLeFWI2x.net
- わからんかなぁ
ほら、あれと同じ雰囲気を楽しむスレなんだよここは。
居酒屋や串焼き屋でだ、仲間内で出来もしない事を熱く議論することがあるだろ。
そういう空気が好きなんだよ俺等
- 491 ：login:Penguin：2005/07/14(木) 23:26:53 ID:PKmLnshm.net
- 釣り堀スレか。
- 492 ：きたろう：2005/07/14(木) 23:38:17 ID:3X5YI5cJ.net
- 常に欲求不満でイライラしている。
自分の能力に劣等感を持っている。
出る杭は徹底的に叩かないと気が済まない。
そんなネガティブな感情に流されてる暇人の存在を感じます、父さん！
- 493 ：login:Penguin：2005/07/16(土) 03:35:55 ID:qxGyOozH.net
- >>486
実際に手を動かせるくらいできてればこんなところで考える前に
ダウソで"ちょっとまちなー"ができるって。
システムが中途半端だとコーディングする意味ないし。
>>480
＞通信の傍受
外部からの、ではなく、内部からのってこと。
つまり(正規の動作をある程度行う)スパイノードの存在は大丈夫かなと思って。
＞どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。
検索システムがどのように予定されてるのかはわからないけど。
例えばクエリが帰ってくるようにリターンアドレスを入れておくような実装だと、
「誰が」リクエストを出したのかがばれてしまう、というような情報漏れを心配している。
＞一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。
1次Upノードが特に危険だと思うんだが。
Shareとかは強制拡散してるみたいだし、Freenetとかはバッファにプッシュして
所持ノードの概念がなくなるみたいだし、いろいろ工夫してると思う。
Winnyは、何もしない、という戦略をとったが。
- 494 ：425：2005/07/16(土) 23:10:58 ID:jAChWphq.net
- 新案をコトコト煮詰めています。
暗号化ファイルは、StaticNATを使った面白いネットワーク偽装を
考えています。
>>493
キーファイルの共有は、完全なFreenetスタイルを考えています。
つまり探索とかもいっしょ、大量のノードが協力しない限り、
要求者を求めるのは難しい。
>1次Upノードが特に危険だと思うんだが。
「自分自身」で「自分自身しか持っていないファイル」を探索するクエリを、
隣のノードに送信すると、どうなると思います？
Freenetでは、経路上に多くのループが発生します。
つまり、必ず探索クエリは、自分自身に戻ってきます。
そこで、アップロードしながらダウンロードしたらどうなるでしょうか?
自分の下位ノードは、自分がそのファイルを中継しているか、アップしている
かは分かっても、誰がその要求を出しているのか分かりません。
逆に、上位ノードは、自分がそのファイルを中継しているか、要求している
かはわかっても、そのファイルが何処から流れてきているのかわかりません。
そして、途中経路では「複製」が出来ます。
つまり、1次Upノードは、誰にも悟られる事なくネットワーク上にファイルの
複製を作れます。
つまり、これで誰が1次Upノードかは謎になる。
- 495 ：login:Penguin：2005/07/17(日) 00:28:28 ID:iMIptb/B.net
- ほんとにできてるの？何％くらい
- 496 ：login:Penguin：2005/07/17(日) 01:26:26 ID:ksRYqrdf.net
- >>495
>>489
- 497 ：login:Penguin：2005/07/17(日) 09:10:57 ID:3e1zqbRW.net
- >>495-496
早漏は損だよ
- 498 ：login:Penguin：2005/07/17(日) 17:36:40 ID:hmmV4Rhb.net
- >>494
＞1次Upノード保護
経路のループを利用して自己偽装Down要求ってことですな。
＞Freenetでは、経路上に多くのループが発生します。
＞つまり、必ず探索クエリは、自分自身に戻ってきます。
このループはある程度大きくないと効果が期待できないと思うんですが、
あまり大きいと、中継転送による速度の低下が心配されると思いますが
バランスとかはどうなるでしょうか。
確実にクエリが戻ってくることは期待して大丈夫ですかね。
繋ぎ変えがおこるネットワークならば、ループが切れたりしないかな。
＞ネットワーク偽装
期待してます。よろ。
- 499 ：425：2005/07/18(月) 18:56:18 ID:juv970X8.net
- 「HannyNet（Hashing anonymous winny Network）」案
ちょっとは、まとまった思うので書いてみる。
「HoneyNet」(行動の一部始終を監視できるように設計されたネットワーク)の
真逆を逝っているので、何となくつけてみたくなった。
匿名性の重要度
ファイル提供者 >> ファイル要求者
ファイル提供者の匿名性は最優先される。
なぜなら、「提供する者」がいなくなれば、
「共有」は存在しえないからである。
つまり、ファイルを提供すればするほど、匿名性の保障に優位に立つことができて、逆に、
吸いとるだけの輩は、匿名性を保障しないようにシステム全体が推移するような仕組みが
望ましい。
- 500 ：425：2005/07/18(月) 18:57:13 ID:juv970X8.net
- ファイル構成
1.キーファイル（テキスト形式）
1-0)キーワード情報
クラスタ化に必要な自然言語パターン
1-1)暗号化ファイル共通鍵
読んで字の如く、暗号化ファイルの共通鍵。
1-2)暗号化ハッシュコード
2-1)のハッシュコードを、1-3)の秘密鍵で、暗号化したもの。
(べつに、1-1)で暗号化しても問題ない。)
意味がないように思えるが、非常に意味がある。
暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
つまり、「暗号化ファイル」から「キーファイル」は分からない。
1-3)IP/ポート交換ワンタイム公開鍵(RSA 128bit)
IPとポート番号を申請するときに使う。
詳しくは、後述。
- 501 ：425：2005/07/18(月) 18:58:06 ID:juv970X8.net
- 1-4)公開鍵(RSA 2048bit)
1-5)の公開鍵。
1-5)電子署名
1)〜4)の電子署名。こうした方が、たぶん都合がいい。
1-6)1-4)のハッシュコード
ノードにキャッシュされる度、随時上書きされる。
キーファイルの検索では、同時に公開鍵の参照も許しているが、
256バイトのデータを毎回参照していたのでは、ノードに対する
負担が大きい。
そこで、ハッシュを用いて大まかに検索して送信する。そして、
最終的な判断は、検索クエリを出したノード自体に委譲する。
ここで、使うハッシュ関数は、MD5やMD4のように厳密なものではなく
計算量が、非常に軽いものが望ましい。固定ビット長なので、上手い
方法があるはずです。
- 502 ：425：2005/07/18(月) 18:59:12 ID:juv970X8.net
- 2.暗号化ファイル（バイナリ形式）
2-1)ハッシュコード
2-2),2-3)のファイルの内容をハッシュにかけた値(MD5)
要は、ファイル名。
ノードにキャッシュされる度、随時上書きされる。
2-2)データフィールド
暗号化された、データが入っています。
2-3)IP/ポート交換ワンタイム秘密鍵(RSA 128bit)
ファイル最後尾から、128bitが1-3)に対する秘密鍵になっている。
詳しくは、後述。
- 503 ：425：2005/07/18(月) 19:00:32 ID:juv970X8.net
- 3.通信ポート
3-1)管理ポート(TCP)
ポート番号： インストール時に決定
主に､キーファイルの検索/受け渡しをする。
暗号化ファイルのプロキシ要求(後述)や、NAT要求(後述)もこのポートで行う。
この通信は、暗号化される。
要は、コマンドもファイルも一緒に送り、暗号化の手間を軽減する。
処理の優先度は、
NAT要求 > 検索クエリ > キーファイルの送受信 > プロキシ要求
3-2)暗号化ファイル検索ポート(UDP)
ポート番号： インストール時に決定
3-1)の通信でコネクションが張られていないIPからの要求は、
全て遮断することとする(応答は受け入れる)。
この通信は暗号化されない。
- 504 ：425：2005/07/18(月) 19:01:18 ID:juv970X8.net
- 3-3)暗号化ファイル転送ポート(TCP)
ポート番号：随時決定
特に説明ナシ。この通信も暗号化されない。
3-4)ICMPエコー要求(ICMP)
イワユル、「ping」コマンドで、セキュリティ上は切っておいた方が望ましいが、
相手のマシンが、起動しているかどうかを調べるのに最も楽な方法。
TCPコネクションを確立させる前にpingを送れば、余計なSYNパケットを出さなくてすむ。
- 505 ：425：2005/07/18(月) 19:02:07 ID:juv970X8.net
- コマンド・パケットフォーマットなど
今の段階では適当。とりあえず、決まっている物から
(所詮、暇人の考える程度の事ですから)
4.暗号化ファイル検索パケット(UDP通信)
4-1)余命(8bit)
そのパケットのが後、どれ位生きれるのかを示す。1つノードを通過すると、
年をとって余命が減るかもしれない。また、減らないかもしれないし、
一気に老けてしまうかもしれない(要は適当に決まる)。
勿論、0になった地点で死にます。
4-2)乱数(24bit)
通信を区別するために、適当な乱数を設ける。
4-3)ハッシュコード(128bit)
暗号化ファイルのハッシュ値
- 506 ：425：2005/07/18(月) 19:03:03 ID:juv970X8.net
- 4-4)暗号化IP/返信ポート(128bit)
要求ノードのIPと返信ポートを1-3)で暗号化したもの。
暗号化ファイル、つまり、1-3)の秘密鍵である2-3)を所持している者だけが分かる。
暗号化ファイルを所持していたとしても、キーファイルを所持していなかった場合、
ファイルの内容は分かりません。
128bitRSA暗号なので、公開鍵が分かれば、本気になれば解ける程度の強度。
つまり、キーファイルから暗号が解けるかもしれない。
ですが、キーファイルがあればの話しですし、公開鍵も不明な状態で解けるほど
軟な暗号じゃありません。
キーファイルあっても、ハッシュコードから、直接キーファイルは分からないので
ないも同然。
勿論、所持しているキーファイルの1-2)暗号化ハッシュコードを復号していた場合なら、
公開鍵は、分かってしまいます。
しかし、匿名性の本質は、暗号化の強度では決まりません。
つまり、要求ノードが「ファイル要求者」だとは、限らないということです。
- 507 ：425：2005/07/18(月) 19:06:51 ID:sTNmNfe5.net
- 5.プロキシ要求コマンド 必要引数
5-1)ハッシュコード
暗号化ファイルのハッシュ値
5-2)IP/ポート交換ワンタイム公開鍵(RSA 128bit)
キーファイルの1-3)と同じ
NAT要求コマンド
ポート貸与要求、延長要求、開放要求の3つがあるが、詳しくは後述する。
6.通信体系
6-1)留意点
仕様的に、NAPTユーザーは、使用不可能になる。
まぁ、人(会社､学校)の回線を使って、P2Pするな。
自己責任でせんかい！
って、意味もあります。(どっちにしろコイツ等、吸い取り専門ですし)
6-2)キーファイル通信
キーファイルの通信は、Freenet的で、ノード間の通信は暗号化されます。
Freenetとの違いは、検索が「自然言語」である事。
「自然言語+公開鍵(のハッシュ)」の検索も可。
Freenetは、小さいファイルを扱うには、非常に優れています。
- 508 ：425：2005/07/18(月) 19:08:34 ID:sTNmNfe5.net
- 6-3)暗号化ファイル通信(基本検索､基本通信)
暗号化ファイル通信の通信は、「基本通信」､「プロキシ通信」、「NAT通信」に分かれます。
まずは、基本となる「基本通信」について説明します。
基本通信は、完全な「直接通信」です。この段階では、通信が行われる2つのノード間では
匿名性もへったくれもありません。ですが、「2つのノード」以外には、通信している事は
悟られません。勿論、「2つのノード」のどちらかに悪意がある場合は別になります。
この段階では、匿名性はないに等しいことになります。
検索は、UDPポートを使った、一斉広報による検索方式です。
トラフィックが無駄に膨れ上がる恐れがありますが、上手くいけば高速な回答が予測できます。
検索方法は、まずファイル要求ノードが、現在接続されている全てのノードに検索パケットを送信する。
検索パケットを、受け取ったノードは、自分の公開領域の中から、暗号化ファイルを探します。
暗号化ファイルが存在すれば、暗号化ファイルに埋め込まれている2-3)IP/ポート交換ワンタイム秘密鍵で復号します。
復号すれば、IPと返信ポートとが分かるので、自分のIPと接続を許すポートを付加した応答パケットを『直接』送ります。
「自分のIPと接続を許すポート」は、中間ノードを通らないので暗号化する必要性はないのですが、応答パケットと、
検索パケットの区別を外部から難しくするために、あえて2-3)IP/ポート交換ワンタイム秘密鍵で暗号化して送ります。
- 509 ：425：2005/07/18(月) 19:09:17 ID:sTNmNfe5.net
- これで、要求ノードは、ファイルの存在場所を知る事ができます。匿名性はないに等しいのですが、これが基本となります。
暗号化ファイルを探しなければ、余命を更新して、現在接続されている全てのノードに検索パケットを
送信する(ただし、送信元ノードには送らない)
余命をいくつ減らすかを乱数でランダムに決めますが、余命によって重み付けが変わってきます。
(この例は、適当で極端な例です)
余命 １: 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：2005/07/18(月) 19:10:02 ID:sTNmNfe5.net
- 6-4)暗号化ファイル通信(プロキシ通信)
普通のプロキシ通信ですが、プロキシの選び方はまったくの「デタラメ」です。
まず、接続されているノードの中から適当に、「プロキシ要求コマンド」を送信します。
プロキシ要求コマンドには、5-1)『ハッシュコード』と、5-2)『IP/ポート交換ワンタイム公開鍵』が
含まれます。
プロキシ要求コマンドを受け取ったノードは、9割の確率で、6-3)「基本検索､基本通信」に移行し、
ファイルを中継します。
のこり、1割の確率で、そのノードは、さらに接続されているノードの中から適当に、
「プロキシ要求コマンド」を送信します。
90%以下の確率で、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
99%以下の確率で、上のパターンか、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
つまり、誰が始めに「プロキシ要求コマンド」を出したかを、分かりにくくするのが目的。
中継ノードは、中継ファイルをキャッシュするが、中間ノードの役割は要求者に対するフィルタです。
ですから、キャッシュの消去は個人の自由です。
キャッシュを消去しなっかった場合、6-3)「基本検索､基本通信」で引っかかって、提供ノードに
なってくれます。
- 511 ：425：2005/07/18(月) 19:10:51 ID:sTNmNfe5.net
- 6-4)暗号化ファイル通信(プロキシ通信)
普通のプロキシ通信ですが、プロキシの選び方はまったくの「デタラメ」です。
まず、接続されているノードの中から適当に、「プロキシ要求コマンド」を送信します。
プロキシ要求コマンドには、5-1)『ハッシュコード』と、5-2)『IP/ポート交換ワンタイム公開鍵』が
含まれます。
プロキシ要求コマンドを受け取ったノードは、9割の確率で、6-3)「基本検索､基本通信」に移行し、
ファイルを中継します。
のこり、1割の確率で、そのノードは、さらに接続されているノードの中から適当に、
「プロキシ要求コマンド」を送信します。
90%以下の確率で、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
99%以下の確率で、上のパターンか、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
つまり、誰が始めに「プロキシ要求コマンド」を出したかを、分かりにくくするのが目的。
中継ノードは、中継ファイルをキャッシュするが、中間ノードの役割は要求者に対するフィルタです。
ですから、キャッシュの消去は個人の自由です。
キャッシュを消去しなっかった場合、6-3)「基本検索､基本通信」で引っかかって、提供ノードに
なってくれます。
- 512 ：425：2005/07/18(月) 19:13:05 ID:NWEvQOcw.net
- 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：2005/07/18(月) 19:13:45 ID:NWEvQOcw.net
- 貸与要求したノード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：2005/07/18(月) 19:14:32 ID:NWEvQOcw.net
- ノード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：2005/07/18(月) 19:16:58 ID:NWEvQOcw.net
- つまり、ノードA からの通信は、A→B→Cとなるが、ノードCからの通信は、C→Bとなる。
こうすると、何がいいのかと言うと
(1) 高速転送
ノードA からの通信量より、ノードCからの通信量はの方が遥かに多い。
そのため、直接通信と変わらない速度が期待できる。
(2) ファイル提供者の匿名性が高い(最重要)
ファイル提供者の匿名性について考えてみると、
＊ノードAは、『あるファイル』を、ノードＢから落としているようにしか見えない。
＊ノードBは、「ノードC」と「ノードA」が通信している事は分かるが、「ノードC」が、
「ノードA」に、『どういうファイル』を送っているかは、ノードＢを中継しないので、
『物理的』に、わからない。
しかし、ノードAが「ファイル要求者」の場合、ノードCからは、モロで見えているので、
完全な通信モデル図はこうなる。
NATノード ----------------------------------┐
↑ ｌ
ｌ ｜
ｌ ↓
要求ノード ＝＝＝ 中継ノード <---------- 仮想カード ← 提供ノード
つまり、最終的には、Winnyと同程度のスピードで、クラスタ化はされないので
少々、使い勝手は悪い物になると思われます(前ほどではないが)。
- 516 ：425：2005/07/18(月) 19:18:16 ID:NWEvQOcw.net
- 新手のアラシさんみたいな量になってしまった(笑
- 517 ：525：2005/07/18(月) 20:26:26 ID:UC0vJmtQ.net
- なんだかよう分からんが期待しとるよ
- 518 ：login:Penguin：2005/07/18(月) 22:52:22 ID:g7t80EI+.net
- >>517
>>490
- 519 ：login:Penguin：2005/07/19(火) 03:08:32 ID:K55Dj3jz.net
- ざっとしか読んでないんで間違ってたら訂正よろ。
重要な点をまとめると
1)キーファイルにワンタイムRSA公開鍵、暗号化本体ファイルにワンタイムRSA秘密鍵を仕込んでおく。
ある暗号化本体ファイルを要求するノードは、返答先をキーファイルの公開鍵で暗号化する。
暗号化本体ファイルを持っているノードのみが、これを復号して通信できる。返答の中の保持ノードの
アクセス先は秘密鍵で暗号化され、キーファイルを持っているノードのみ復号できる。
2)キーファイルから、暗号化本体ファイルを落としたいノードは、自分のIPアドレスとポートを
ワンタイム公開鍵で暗号化し、ブロードキャストする。この本体検索要求は、TTLを仕込んでおき
転送されているうちにある程度で破棄されるようにする。
応答があれば、復号した所持ノード情報を元に直接ダウンロードする。
3)もしくは、暗号化本体ファイルのハッシュと、ワンタイム公開鍵を、隣接ノードにプロクシ転送要求をかける。
要求されたノードは、適切な確率で再転送か、2)で示したダウンロードを実行する。
4)自分のIPアドレスとあるポートを、他のノードに貸し出すこともできる。
この場合、貸し出したポートへの通信はすべて転送される。
- 520 ：login:Penguin：2005/07/19(火) 03:15:47 ID:K55Dj3jz.net
- ごめん。正直NATの説明がよくわからなかった。
これって実装の手間を考えたら、効果ってそんなにあるの？
NATに応じなくてもネットワーク的にペナルティないんだったら俺なら応じてやんない。
プロクシ転送要求に応じれば、自分のHDDと帯域は使われるかもしれない。
けれども、自分の出した要求が、他の人の要求の結果だという言い訳ができるし、
ひょっとしたらお宝ファイルかもという期待がある。
転送の中身見れないなら、踏み台になる意味ないじゃん。
>>500
暗号化ファイルのハッシュがわかんないと落とせないんだったら
キーファイルに書いてないと、人間言語からの検索が不可能になるのでは。
- 521 ：425：2005/07/19(火) 21:40:31 ID:mMosH/WX.net
- >>519
スマソ。大体、そんな感じです。
>>520
>ごめん。正直NATの説明がよくわからなかった。
くわしくは、「StaticNAT」か「ポートフォワーディング」でぐぐってください。
>これって実装の手間を考えたら、効果ってそんなにあるの？
私もプログラマじゃないので詳しい事は言えないが、Linuxで実装するなら、
そこまで難しくないと考えられる。
ここに書いていることは、Linuxカーネルが提供するサービスを
サーバOSならば当然持っている機能を組み合わせただけです。
つまり、適当にOS呼び出して使うだけでOK(のはず)
逆に､Windowsでは、面倒かも。
- 522 ：425：2005/07/19(火) 21:45:21 ID:mMosH/WX.net
- 続き・・・
>NATに応じなくてもネットワーク的にペナルティないんだったら俺なら応じてやんない。
べつに、大して重い処理じゃないし、単に転送するだけし、主にACKパケットを
中継するだけなので、帯域を犯される心配もない。ISDNでもOK(笑
ペナルティではなく、応じてくれた相手に対して報酬になるようした方が
よいのでしょうけど、今は詳しくは考えていません。
>プロクシ転送要求に応じれば、自分のHDDと帯域は使われるかもしれない。
>けれども、自分の出した要求が、他の人の要求の結果だという言い訳ができるし、
>ひょっとしたらお宝ファイルかもという期待がある。
>転送の中身見れないなら、踏み台になる意味ないじゃん。
はっきり言って、中継ノードにされることは『踏み台』にされるだけで、
何のメリットもない
(積極的にファイル供給者になると少し変わってくるが、そのことは、また今度)
お宝ファイルがあったとしても、それに対応するキーファイルが見つかる
可能性は、この仕様では薄い。
別に、『踏み台』になるかならないかは、そのノードの自由だと考えています。
ですが、『踏み台』に成らないノードに対して、誰が『踏み台』になろうと思います？
結果、そういうノードは、孤立していきます。
別にプロキシ無しでも通信可能ですし、『言論の自由』を求めない方には丁度いいのかも(w
- 523 ：425：2005/07/19(火) 21:47:03 ID:mMosH/WX.net
- 続き・・・
>>500
>暗号化ファイルのハッシュがわかんないと落とせないんだったら
>キーファイルに書いてないと、人間言語からの検索が不可能になるのでは。
1-0)キーワード情報
クラスタ化に必要な自然言語パターン
↑これのことですか?
これには、色々なキーワードを、URLエンコードされた形で入れておきます。
キーワードは、アップ時に「ジャンル」と「ファイル名」のような物を要求し、
適当にアプリ側で文法解析させて、キーワード情報として入れておきます。
これで、キーファイルを「自然言語」で検索して、キーファイルに付いている
ハッシュの暗号化を、これもまたキーファイルに付いている鍵で復号して、
そのハッシュ値で、暗号化ファイルを検索します。
- 524 ：425：2005/07/19(火) 21:50:39 ID:mMosH/WX.net
- 訂正: クラスタ化 → 検索
結構、書き貯めしていたので、なぜこんな間違いを書いたのかは
まったく記憶にない。
- 525 ：login:Penguin：2005/07/20(水) 00:28:12 ID:IaDxISng.net
- >>523
読み間違えてました。
キーファイルから暗号化本体ファイルへのリンクとなるハッシュは、ワンタイムRSA秘密鍵で
暗号化されてるのね。キーファイルに公開鍵が含まれるから解けると。
＞暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
＞つまり、「暗号化ファイル」から「キーファイル」は分からない。
ってどういう意味？暗号化ファイルを持っていれば、公開者RSA 1-4) 1-5)を除いて
キーファイルは生成できるんじゃ。
>>521
StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、
プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね)
めんどくさそうと。
プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、
インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。
そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、
他で代替可能でないのかについて、ちょっとよくわからなかった。
- 526 ：login:Penguin：2005/07/20(水) 00:30:31 ID:IaDxISng.net
- ちなみに。
RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ
信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。
- 527 ：login:Penguin：2005/07/20(水) 00:38:55 ID:zmMtfR5C.net
- NAT は Skype とかが使ってる UDP なんちゃらで解決しないのか？
- 528 ：425：2005/07/20(水) 21:48:47 ID:d8u1kb3S.net
- >>525
>＞暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
>＞つまり、「暗号化ファイル」から「キーファイル」は分からない。
>ってどういう意味？暗号化ファイルを持っていれば、公開者RSA 1-4) 1-5)を除いて
>キーファイルは生成できるんじゃ。
暗号化ファイル自体は、500>>の
1-1)暗号化ファイル共通鍵
読んで字の如く、暗号化ファイルの共通鍵。
によって暗号化されており、キーファイルがなければ解読不可能です。
>＞つまり、「暗号化ファイル」から「キーファイル」は分からない。
これについては、分かりやすいモデルで説明しますと、こう言うことです。
(実際は、ちょっと違います)
- 529 ：425：2005/07/20(水) 21:51:17 ID:d8u1kb3S.net
- キーファイル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：2005/07/20(水) 22:38:29 ID:X6ELMDVA.net
- >StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、
>プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね)
>めんどくさそうと。
まず、P2Pやるなら市販のパーソナルFWは消しときましょう。
(つうか、linux用のパーソナルFWってあるのか？)
つまり、使ってないポートは、全部斬って置いて、使うポートは、アプリ(デーモン)自体が、
アクセス制限かけないといけません。(httpdとかsendmailとかも、全部そうなってます。)
パーソナルFWは、全自動で使ってないポートは、全部斬ってくれるだけで、
他は大した事はやってくれません(FWとウイルス対策ソフトは基本的に違うモノです)。
つまり、P2Pといっても『サーバ』なので外からの、アクセスを許すことになるので、
必ず、それ相応のリスクは必ず伴います(Winnyのウイルスとか)。
まぁ、デーモンの起動ユーザをプロセスごとに複数の一般ユーザ分ければ、
実質的な被害は、あまり出ないでしょうけど。
- 531 ：425：2005/07/20(水) 22:39:39 ID:X6ELMDVA.net
- >プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、
>インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。
>そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、
>他で代替可能でないのかについて、ちょっとよくわからなかった。
結論から言うと、プロキシの方が、セキュリティ面をしっかり考えなければならない。
「ポートフォワード」で、セキュリティが懸念されるのは、ネットワークの内側(LAN内)に
ネットワークの外側（インターネット）からアクセスがあるからです。
これでは、FWを付けても、その穴から突破されれば、無防備なLAN内のPCに簡単に
アクセスされてしまいます。
一方、P2Pは、「自分」と「その他」の概念しかなく、BがCに「ポートフォワード」して、
AがCにアクセスした所で、セキュリティー的には、AがCに直接アクセスするのと変わりません。
Bは、単なるルータにすぎません。
しかし、プロキシの場合、デーモンつまり、アプリ自身が提供するサービスなので、
アプリ自体に、バグがある場合、速攻で攻撃対象になります。
- 532 ：425：2005/07/20(水) 23:16:59 ID:fW484GcX.net
- >ちなみに。
>RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ
「RSA公開鍵ペア」はIPを交換する鍵ですよね？
「書き換える」ためには、「キーファイル」と「暗号化ファイル」の双方を所持していかないと、
書き換えられません、さらに、書き換えた「キーファイル」と「暗号化ファイル」を流通させないと
いけません。
とても、面倒で時間がかかります。そんな事しなくても「キーファイル」と「暗号化ファイル」を
もっていれば、どこの「中間ノード」と思われるノードが、「どんな」ファイルを
欲しているかは分かります。
じゃあ、何故「中間ノード」を攻撃するのか? 単にクラックが目的であれば、中間ノードなど
関係無しに、当たりかまわず攻撃しまくればいい。
つまり、結論としては、単なる「クラッカー対策」
クラッカー対策は、全てに通じるもので、P2Pに限った問題ではありません。
(それが難しいのですけどね。)
- 533 ：425：2005/07/20(水) 23:18:49 ID:fW484GcX.net
- >信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。
信用を集めてから、粗悪なファイルを流すということですか？
攻撃にしては、時間がかかりすぎると考えられるし、さらに信用を集めるための
ファイルは、何処から持ってくるのかという問題がある。
さらに、匿名性自体を犯す攻撃じゃありません。
結局、得するのは信用を集めている間に、ファイルを得た人々だけです。
- 534 ：425：2005/07/20(水) 23:39:06 ID:BeHtAV13.net
- >>527
>NAT は Skype とかが使ってる UDP なんちゃらで解決しないのか？
UDP hole punching のことですね。
私も、あまり知らないんで詳しい事はいえませんが、
これは、あるサーバーが、IPとポートを貸し出し、通信を
ネットワークレベルで仲介してくれる技術です。
まぁ、これをP2Pと呼べるのか？という疑問もありますし、
匿名性の概念はありません（と思う）
さらにいえば、現在の仕様では、NATの中は通してもらえません。
- 535 ：login:Penguin：2005/07/21(木) 02:58:11 ID:z2CP8IVj.net
- >>532
中間者は、自分用のRSA鍵ペア(ポート用とファイル用)を作っておき、キーファイルの伝播の際に
1-3) 1-4)を自分用のものにすりかえて、1-2) 1-5)をあわせておく。
暗号化ファイル検索要求が来れば、おもむろに自分の秘密鍵で検索をかけたノードを復号できる。
この書き換えは、もともとのキーファイルを持っているだけでよく、
(中身を知る必要がなければ)暗号化ファイルは必要ない。
システム的に排除できる可能性は、1-4)の公開鍵が実績があるかどうかでキーの信頼度を
決めることだろうけど、簡単に信頼度を集められるようにすると、少し正常動作をしてあとは釣り人に
なればいいだけだし、あまり難しくすると長い間同じ鍵を使わなくてはならなくなるのでノードの特定に
繋がったりしそう。
完全に書き換える必要はない。単に、キーファイルが「それっぽい」だけでいいんだから。
せっかくRSAで検索送信者保護をしても間に入られたら意味ないなとふと思っただけだけ。
要求の転送で隠せるからある程度はいいけど、Winnyと同程度になっちゃうな。
- 536 ：login:Penguin：2005/07/21(木) 03:05:45 ID:iQmD7UoW.net
- データ本体のキャッシュの寿命の方はどうなってんの？
完全なるクラスタになっていないかぎり、キャッシュ中のデータのほとんどが要、不要がわからないデータなわけだろ？
要不要が即わかるほどキーファイルが流通するネットワークなら、
わざわざデータファイルのメタデータを隠蔽する意味が不明だし。
転送機能なんてほぼ意味ないよ。
となりがキャッシュをはじめから持ってるのと、いまからキャッシュにし始めるということと、どう違うわけ？クラスタ化されていない状態なら、無駄なキャッシュが増えるだけ。
いかれたパケットを送出するのに、root権限が必要なのだが、それはどうでもいいの？
っつーか、ノード数、ファイルサイズ、ファイル数、各ノードのキャッシュ容量とかどの程度のものを考えてるのかね。
- 537 ：login:Penguin：2005/07/21(木) 03:20:49 ID:z2CP8IVj.net
- >>531
A->B->Cのポートフォワードがおこっているということは、CがBに依頼したということでOK？
この状況で、B->Cのポートフォワードが悪用されたらBはインターネット的に責任をまぬかれるのか、
ということを心配したんだけど。
Cに依頼されたので、Cが落とされるようなパケットが転送されたとしても、依頼したCが悪いんです。
で問題ないか。
もしBが悪意のノードで暇人で、来たパケットを転送する前にごにょごにょ書き換えて送ったとしても
Cは依頼する前にBの悪意を見抜けなかったから泣いて下さい、でシステム的にはOKか。
パケット転送はファイルの転送のみに使用して、コネクションを管理するポートには使わなければ
致命的にはならないね。
- 538 ：login:Penguin：2005/07/21(木) 13:39:18 ID:+geUQqPb.net
- (´-`).｡ｏO(今度こそモノになるかな）
- 539 ：login:Penguin：2005/07/21(木) 14:28:00 ID:RTcoM3Vh.net
- ｌｉｎｕｘ普及のためにOOoに匹敵するプロジェクト
完成を期待します。
- 540 ：login:Penguin：2005/07/22(金) 21:09:49 ID:ySzGffYS.net
- ネタ切れか
- 541 ：login:Penguin：2005/07/22(金) 21:11:58 ID:tBkDAb44.net
- 誰か僕にネットワークプログラミングのやり方を教えてください。
- 542 ：login:Penguin：2005/07/22(金) 23:31:16 ID:eHH1w66m.net
- しばらく見ない間に随分賑やかになっとるなぁ
少し読んでみたのが実際に動き出した時、これがどの程度動くのか、わしにゃ分からん。
>>502
2-3)IP/ポート交換ワンタイム秘密鍵(RSA 128bit)
ファイル最後尾から、128bitが1-3)に対する秘密鍵になっている。
詳しくは、後述。
「ファイル最後尾」に意味はまったくない。
キーファイルの公開鍵でIPを暗号化して、暗号化ファイルの所有者だけに分かるように渡すんでしょ？
ファイルの先頭につけると秘密鍵だけを抜き取られてしまうと考えたんだと思うけど、
レジューム機能を実装させると、まったく意味がないような気するがどうなの?
まぁ、批判は簡単なので暗号化ファイルを全部落とさないと、秘密鍵が分からない仕様を考えてみた。
要は、ハッシュコード生成を少し変え、秘密鍵に非常に軽量な暗号をかける。
- 543 ：login:Penguin：2005/07/22(金) 23:34:12 ID:eHH1w66m.net
- 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：2005/07/23(土) 00:07:29 ID:vcii9dn+.net
- 乗りかかった船なので、私的に、明かに的外れだと思われる質問に勝手に答えてみる。
>>537
>>513
しかし、このままでは不正利用を招くので、ノードBには、TCPのPSHパケットと、UDPパケットは
転送しないよう設定します。
要は、ノードBからは、TCPのコントロールパケットしか飛んで来ないわけだ。
つまり､ACKパケットを、RSTパケットに変えて送った所で、通信が切断されるだけ。
そんな事を、するだけであれば単に中継しなければいい(中継すると契約しといて実はしない)。
しかも、書き換えて攻撃するなど、ややこしい。セキュリティ的には直接攻撃されているのと
変わらん。やる意味がない。攻撃といっても、単に一方的にファイルを送りつけるだけのポートに
できる事って何がある?
さらにいえば、どちらかと言えば、悪意あるノードがノードBを踏み台に攻撃する方が
多いと考えられる。だから、上記の>>513のような一文が加えられているのだと思う。
あってるよね? > 425
つうか、今この質問に答えていて思ったのだが、レジュームの実装って難しいんじゃねぇのか?
- 545 ：login:Penguin：2005/07/23(土) 11:32:29 ID:jtlytnMJ.net
- た
し
ま
り
い
ま
て
っ
が
上
り
盛
- 546 ：425：2005/07/24(日) 23:41:51 ID:hPPfaUHc.net
- 私用PCが・・・クラッシュしちまった＿|￣|○
さらに、夏風邪をこじらして寝込んでしまった。
気を取り直していきましょう。
なんか、活気付いてきましたね。どんどん、意見交換して行きましょう(w
ここで提示しているのは、単なる案ですから、ここをこういう風にした方がいい
って意見は、特に大歓迎です。
>>534
自己レスです。UDP hole punching について、私の中で勘違いがあったので、書き直しておきます。
「UDP hole punching」は、IPマスカレード(NAPT)によって書き換えられた、送り元ポート番号,IPアドレスを
親サーバ上で交換し合い、UDPで通信する仕組みです。上手いこと、システムを騙した通信で面白い。
ですが、必ず、交換し合う親サーバが必要なのと、親サーバが十分信用できないとセキュリィティが守れません。
あと、匿名性の概念もまったくありません。
しかも、そのUDPパケットがFWで弾かれることが多いので、実質的に使える機会は非常に少なかったりします。
- 547 ：425：2005/07/24(日) 23:45:22 ID:hPPfaUHc.net
- >>535
>中間者は、自分用のRSA鍵ペア(ポート用とファイル用)を作っておき、
『鍵ペア』って、そう言う意味だったんですね。
私自身は、1-4)とノードの関係は、現実世界で余ほど目に余る行動を取らない限り、
バレる事はまずあり得ないと、考えています。
仮にバレたところで、1-4)は、『情報の保障』をしている一文であって、
ファイル提供者かどうかを、定めている一文ではありません。
- 548 ：425：2005/07/24(日) 23:46:38 ID:hPPfaUHc.net
- >キーファイルの伝播の際に 1-3) 1-4)を自分用のものにすりかえて、1-2) 1-5)をあわせておく。
「匿名性」や「セキュリティ」を犯す攻撃にはなりえないと考えられます。
理由は以下の通り。
1)暗号化ファイルが見つからない → 公開鍵の評価が下がる。
『1-3)IP/ポート交換ワンタイム公開鍵』を 入れ替えてしまうので、暗号化ファイルにある
『2-3)IP/ポート交換ワンタイム秘密鍵』で、復号不可能になる。
つまり、検索パケットを送ったノードに応答パケットを返せないので、暗号化ファイルが見つからない
よって、公開鍵の評価が下がる。 つまり、相当の信用を得ていない限り、直ぐに「信用できない公開鍵」
として学習され、攻撃ノードは、今後その鍵での攻撃は不可能になる。
2)中間ノードのIP/ポート番号が分かった所で、「匿名性」は犯されない。
中間ノードが、一斉広報で検索をかける際、攻撃者に、そのパケットが届き、
自分が摩り替えた鍵の秘密鍵で復号して、IP/ポート番号が分かった所で、
中間ノードと思われるノードの「IP/ポート番号」が分かったに過ぎない。
さらに、1)の理由で、それが長い間続くわけではない。
中間ノードが分かった所で、長期間に及ぶ大規模な調査がない限り「匿名性」は犯されません。
- 549 ：425：2005/07/24(日) 23:49:53 ID:hPPfaUHc.net
- >>536
>データ本体のキャッシュの寿命の方はどうなってんの？
静的関係のキャッシュに過ぎないので、寿命の概念はまったくありません。
いつでもいい、好きな時に消していいし、消さなくてもいい。
ハードディスクの資源は有限なので、その辺は、適当に設定する。
>要不要が即わかるほどキーファイルが流通するネットワークなら、
>わざわざデータファイルのメタデータを隠蔽する意味が不明だし。
キーファイルが、いくら流通した所で、要か不要かは、データファイルのメタデータ
つまり、キーファイルの暗号化ハッシュコードを復号してみないと分からないと思ういますが?
>>535のような、もう少し具体的な説明をしてもらえませんか?
>となりがキャッシュをはじめから持ってるのと、いまからキャッシュにし始めるということと、
>どう違うわけ？
一応、当り前のことだと思って書きませんでしたが、プロキシ要求を受けたノードは
とりあえず、自分のキャッシュを探し、あれば、それをそのまま返します。
つまり、違いありません。
- 550 ：425：2005/07/24(日) 23:55:29 ID:hPPfaUHc.net
- >クラスタ化されていない状態なら、無駄なキャッシュが増えるだけ。
暗号化ファイルのレベルでは、クラスタ化はありませんが、キーファイルのレベルでは存在します。
どう、言うことかといいますと、プロキシ要求は、3-1)で起こります。
さらに、検索パケットは、3-1)のポートが開いている相手にのみ送るので、
結果として、暗号化ファイルはキーファイルの通信によって、形成されたクラスタの周りを
うろちょろするだけです。
カッコよく言えば、暗号化ファイルは、キーファイルのクラスタを継承します。
この辺はまた詳しく話します。
>いかれたパケットを送出するのに、root権限が必要なのだが、それはどうでもいいの？
その辺が、UNIX系の鬱陶しいところですよね。適当にエージェントを挟むなり、すれば
root権限まで取られる事はないのかな。
P2P専用として使うのなら、落ちたって大した事はない思っていたりする。
>っつーか、ノード数、ファイルサイズ、ファイル数、各ノードのキャッシュ容量とかどの程度のものを考えてるのかね。
ネックとなるのは、キーファイルの通信になります。この辺の仕様を、はっきり決めない事には、分かりません。
現在分かっているのは、各ノードの暗号化ファイルのキャッシュ容量は、まったく自由です。
Freenetを「公開鍵暗号方式」と例えるならば、HannyNetは、「ハイブリッド暗号方式」を徹底的に目指してみたい。
- 551 ：login:Penguin：2005/07/25(月) 02:43:41 ID:HNMfL4hb.net
- キーファイルをみても要不要かわからないってことは、
キーファイルにはファイル名もキーワードもはいってないってことか？
それじゃあ、どうやって検索とかクラスタ化するわけ？
どうにしろ、キャッシュされることを考えていないってのは全く持って意味不明。
流通の効率を全く考えてないって言ってるのと同等じゃないか。
- 552 ：login:Penguin：2005/07/25(月) 15:52:46 ID:DS/oy6EW.net
- HannyNet(仮)とやらは参加ノード全てがハイレベルクラッカーなわけ？
相手のPCを攻撃しながらファイル共有でもしているのかｗ
膨大なクエリでネットワークが埋め尽くされ、キーロスト多発
マルチソースDLどころかレジュームすらまともにできずにゴミキャッシュが
増えるだけの予感
- 553 ：login:Penguin：2005/07/26(火) 07:56:10 ID:LfvsKzx0.net
- 横レスですが
>>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.net
- テスターやりますよ。期待age
- 555 ：425：2005/07/27(水) 00:54:52 ID:if8zYisn.net
- レスが追いつかないので、横レス大歓迎です。
>>542-543
レジュームのことを、すっかり忘れていました。この暗号(?)は使えそうですね。
非常に単純ですけど、強度は十分だと思います。
最も手っ取り早いのは、検索パケットに「先頭からバイト数」(*)の情報を加えて応答パケットに、
「ファイル長(バイト)」から(*)の差を載せて送るようにする方法でしょうね。
検索パケット自体は、IP/ポート番号などを含め、128bitまでの情報を載せることができますから、
IPアドレス + ポート番号 = 48bitなので、十分余裕はあります。
>>544
言葉に若干トゲがありますが、大体そう言うことです(笑
Aの通信が、Bによって書き換えられ、Cを攻撃したのであれば、
Cは、Bに直接攻撃されたのと変わりません。
つまり、Bの攻撃によってCがクラックされた場合、Cのセキュリティが甘かっただけ。
Bが攻撃者である事も分かります(クラック対策は比較的容易)。
むしろ、Aの通信に悪意があり、Bを中継し、Cを攻撃した場合の方が問題。
そのため、Bは、転送するポートに送られたUDPおよびPSHパケットを排除します。
- 556 ：425：2005/07/27(水) 01:05:00 ID:if8zYisn.net
- >>551
>>553を参照してください。
キャッシュされたファイルがあるノードは、検索パケットに対して応答するので、
無駄にはならない。
ただし、暗号化ファイルは、ある程度キーファイル上のクラスタをウロウロする事は
予測できますが、実際問題としてモデルを組まないと正確な事はわからない。
>>552
単に、どんな攻撃が存在するかを適当に言いまくっているだけ。実際には、
純粋(?)にクラックが目的のクラッカーは、タダのPCに魅力は感じないので、
まず来ないでしょう。
検索パケットの最大余命なども決めなければ、帯域を圧迫する恐れあるので
モデルを組んで考えなければならない。
プロキシを使ったマルチソースDL(ファイルの分割化が必要)は仕様として考えていませんが、使わないのであれば、
クライアント側の仕様を適当に変えるだけで、マルチソースDLは可能です。
プロキシ使わなくても、UP側はいつでも匿名ですし、Down側もある程度の匿名性も維持できると思います。
- 557 ：425：2005/07/27(水) 01:06:33 ID:if8zYisn.net
- >>553
>535攻撃は、キーファイルの配布速度と範囲によって有効だとは思う。
確かに言える。しかし、攻撃者がキーファイルを書き換えて攻撃しようとすると、そのキーファイルは
『人気のあるキーファイル』であると予測される物でないと効果は期待できない。
しかし、『人気のあるキーファイル』であると予測される物であれば、高い確率でかなりの量が
流通しているはずです。そのような中で、『書き換えられたキーファイル』が広く流通するとは、
考えにくい。よって、被害を受けるのは極僅か。しかも、匿名性を犯すものではない。
逆に、『人気のないキーファイル』であると予測される物であっても、今度は検索クエリが自分の
場所に届く保障はない。
さらに、同一ノードに関しては、公開鍵の評価が下がっていくので、その公開鍵を使った攻撃は
無意味な物になっていきます。
つまり、攻撃として手間がかかる割に小規模な攻撃しか出来ない。
>中間者がIPアドレスを知ったところで、Winnyと同程度までしか匿名性は落ちないけど
>いろいろしてる割にしょぼくなるな…と思ってしまった。
例えが悪いと思いますが、懲役10,000年の囚人が司法取引で懲役100年になったとします。
たしかに、99,000年も刑期が短くなったわけですが、実際問題として大して変わりません。
その程度だと、考えてもらっていいと思います。
- 558 ：login:Penguin：2005/07/27(水) 01:24:16 ID:AFPD/rL/.net
- ttp://homepage3.nifty.com/toremoro/p2p/p2p.html
ここは読んでみたか？
- 559 ：login:Penguin：2005/07/27(水) 08:43:34 ID:sGzAtD+q.net
- >>557
Winnyではクローズドだったから特には問題にならなかったけど、
キーファイルの改竄は、結構システムとしてやばめの攻撃だと考えている。
チェックサムとか署名でのシステム的な保護をするのはもちろんだけど、
キーファイルというものはリンクであるわけだから、有効なキーファイルかどうかは
実際落として見ないとわからないわけだ。
(スレ立てするときにテンプレの関連スレが有効かどうかを調べるみたいに)
末端ノードでは、自分のチェックした結果と、（もしするなら）伝播してくる信頼度の噂
によって、キーの有効度をテストしなくてはならない。
攻撃側は、いくらでも評価0の公開鍵を作ることができる。
正規配布ノードの公開鍵の評価を上げるシステムか、攻撃者公開鍵の評価を下げる
システムが必要となるけども、この評価伝播システムは、それ自体が攻撃対象となってしまう。
入れないというのもひとつの手だとは思うけど(自分以外みんな敵)、
PGPみたいに信頼のネットワークを導入するのもありかなとは思う。
キーの伝播にどんなシステムが適当かわからないし、システムによるとは思うけど、
攻撃の手間のわりに、結構被害がでかいと私は思っている。
Winnyのキー伝播を仮定すると、"ファイルの公開者トリップを書き換えて遊ぶ"というのが
一時流行ったけど、あれはかなりな効果範囲だった。
IPアドレス収集までいかなくとも、ゴミキーが混ざるだけでも結構検索に支障が出ると思うし。
- 560 ：login:Penguin：2005/07/27(水) 09:00:00 ID:sGzAtD+q.net
- >>558
見てみました。まとまってますね。
425プロトコルは、基本的には多段プロクシに分類されるのかな。
これみて思い出したけど、Winnyで課金可能性についてでてましたけど、
このシステムでは実装可能ですかね。
当時、ぼろくそに言われてましたが、可能かどうかだけでも検討しておいた方が
なにかと良いかと思います。
結局のところ、"監視することができない"というシステムにするなら以前から言われる
｢投げ銭システム｣しかないと思います。
オープンソースシステムでは、不正ノード防止のための工夫が必要になると思いますが
この防止には、結局他ノードの目というのが必要となってくると思います。
例えば、転送量監視だとか、データの損傷(署名が一致するか)だとか、ゴミキーを送ってこないかとか。
そういったシステムを流用して、間接的な監視というものが実現できれば、
PureP2Pでも、課金ができるかもとか考えたりしたんですが、いいシステムは思いついてません…
今のがっちがちなインターネットの課金システムほどは確実には取れないと思いますが、
ちゃんと投げ銭できれば、現状よか使い勝手よく少しは取れるになるのではと思ったり。
- 561 ：425：2005/07/27(水) 20:18:17 ID:pqX40aYh.net
- 人大杉で読めないよ。
しょうがないので携帯からアクセス。
>>558
P2Pの基本と言っても、結局TCP/IPの基本に他ならないと思います。
>>559
実装されるようになると、エンドユーザからは、キーファイルや暗号化ファイルを、
あまり意識する必要がないような、インターフェ―スになると考えられます。
つまり、あるキーワード入れると、全自動であるキーワードに引っかかるキーファイルが
全部落とされてきて、暗号化ファイルのダウンロードも同時進行で行う。
Winnyの基本である『待ち』ですね。待ってれば、落とされます。
その中で、公開鍵の集計を取っていけば、信用性にかける公開鍵はふるいに掛けられます。
落としてきたキーファイルの中にゴミキー30%混じっていた所で、検索にちょっと時間がかかるだけで
信用性にかける公開鍵は、次々とふるいに掛けられるので検索速度は向上していきます。
- 562 ：425：2005/07/27(水) 20:27:50 ID:hYL+POH6.net
- 続き・・・
逆に、攻撃者が全自動でゴミキーを作っていたとしましょう。
信用性にかける公開鍵は、次々とふるいに掛けられるので、攻撃するには新たに公開鍵を
作ってやる必要があります。
さて、ここで問題です。
攻撃者が、RSA2048bitの鍵ペアを作る時間と、探索者が『信用性にかける公開鍵』を
見つける時間は、どちらの方が短いでしょうか?
また、どちらの方のマシンが先に悲鳴を上げるでしょうか?(w
どんな攻撃を仕掛けてきても、「RSA2048bit」という馬鹿みたいに長い鍵のせいで、
長期戦は出来ず、超短期決戦になります。短期決戦では、『匿名性』は崩れる事は
ありません。
- 563 ：425：2005/07/27(水) 20:30:06 ID:hYL+POH6.net
- >>560
>425プロトコルは、基本的には多段プロクシに分類されるのかな。
基本が、WinnyとFreeNetですからそうなりますね。
暗号化ファイルの検索が帯域を圧迫する恐れがあるので、
そのあたりもう少し考えなけれななりません。
- 564 ：login:Penguin：2005/07/27(水) 23:26:59 ID:IJEnt68s.net
- 短期決戦？まさか。
暗号化ファイルが得られるまでキーの妥当性なんか判別できないんだろ。
しかも、人間が判別するわけだろ。
何が先に悲鳴をあげるでしょうか(www
- 565 ：login:Penguin：2005/07/28(木) 02:29:02 ID:fAaYvFoP.net
- >暗号化ファイルが得られるまでキーの妥当性なんか判別できないんだろ。
少なくとも､明らかに「暗号化ファイル」が存在しないものは
システムで見つける事は可能だと思うが?
>>535に対する回答としては十分でないか？
- 566 ：login:Penguin：2005/07/28(木) 08:07:59 ID:eeVn6bw9.net
- >>565
明らかに存在しないのか、単にレアものなのかの区別はどうする？
(キーの配布拡散方針にもよるが)暗号化本体ファイル(2)を持ってるノードがダウンして
キーだけ出回っている状況とどう見分けるのかってこと。
>>562
1000〜のオーダーで順次回されたら、攻撃者鍵と初回ダウンロードな鍵とを
見分けられないのでは。(各ノードはそんなにたくさん鍵を覚えておくのか)
ちなみに以前某所で使った、俺様実装なRSAプログラムでは2048bit鍵生成に1500msでした。
真面目に(攻撃されないように配慮して)鍵を作るのには時間がかかるけど、
それなりにチューンされた多倍長ルーチンを持っていれば
1024bit程度の素数かどうかチェックは秒行くか行かないかな速さでできます。
(´-`).｡oO(自分でしこしこ組んだのより、gmpというルーチンは10倍以上速かった…)
- 567 ：login:Penguin：2005/07/28(木) 14:40:26 ID:d4j3xM1r.net
- 前から出てるけど、暗号化ファイルと無関係なキーワード並べたキーファイルをばらまく攻撃ができるよ。
公開鍵生成しながら、適当に検索かけて、流れてくるキーファイル受信しとく。
検索が来たら、受信したキーファイルの 1-1) を一致するキーワードに書き換えて、ついでにランダムなキーワードも追加。
1-4) を生成しといた鍵に差し換えて、 1-5) の署名をして、検索した人に返信すればいい。
検索した人は、無関係な経路から無関係な暗号化ファイルを受信することになる。
もちろん、復号して確認するまで、無関係な暗号化ファイルかどうかはわからない。
- 568 ：login:Penguin：2005/07/28(木) 18:25:16 ID:oqKZ/QOz.net
- >>566
最低でも15秒はかかると思っていましたが、速いモノですね。
確かに、鍵を作るだけであれば、200個の素数から1090組の
鍵ペアが出来ちゃうんですよね(^^;
いよいよ、公開鍵を元に不正なキーファイルをノード単体で、
探すのは困難になってきたわけですか。
その辺は、前々からちょっと思っていたのですが、「信用できる公開鍵の情報」を
共有してしまえば、「信用性のない公開鍵」を排除できると思います。
自分が分かってる「信用できる公開鍵」の書いたテキストを、キーファイルと
暗号化ファイルにエンコードして公開するだけ。
しかし、そんな親切な人いないので、システム側で支援すべき。
まぁ、データ圧縮や不可逆性の点から考えても「信用できる公開鍵」の情報は、検索時に利用される
(ますよね？)公開鍵のハッシュコードをだけを書いた方がいいのかもしれない。
無事、ファイルが公開できたとしても、今度は、「信用できる公開鍵の情報」のキーファイルの
「公開鍵」が「信用できる公開鍵」なのかという問題が、起こってきたり、来なかったり。
まさに、「もし、この島の人間は皆、ウソツキなので気をつけなされ」状態。
でも、不正なノードもある程度ネットワークが大きくなければ出て来ないでしょうから、
その間に、いかに信頼関係を気付いていくかが問題なんでしょうね。
どちらかと言うと、ソーシャルネットワーク見ないなもんなのかな。
- 569 ：login:Penguin：2005/07/29(金) 05:00:12 ID:LUTJPErB.net
- 議論がキーの信用問題になってるけど、他にも弱点を指摘よろです。
>>568
キーファイルの有効性については、1-4)1-5)にある公開鍵による署名をよりどころにする
という認識でok?
ゴミファイルor捏造であるかどうかを含めて、公開鍵の評価に反映させる、と。
極論すれば、｢信頼のない公開鍵で認証されたキーファイルは破棄する｣とかいうシステムですな。
となると、攻撃対象は"公開鍵の信用性の伝播"に移ると思うんですが、耐性はあるかな。
外部からファイルを投入してくれる「職人さん」というのがあるけど、ファイルの有効性を確かめて
信頼情報を流してくれる"情報職人"というのができればいいけど。
信頼情報の署名を含めて、PGPでの信頼の輪みたいに共有していくシステムがいるね。
ネットワークに参加する際、一番初めの「信頼できる公開鍵」を何にするかという問題もあるな。
公開鍵の信頼の輪が、意見の相違によっていくつかに分かれたりもするかも。
信頼の輪にクラスタ化がいるのかもね。
- 570 ：login:Penguin：2005/07/29(金) 05:04:53 ID:LUTJPErB.net
- 情報屋は大変かも。一度でも間違えた評価をするとみんなから評価してもらえなくなったりとか。
評価の伝播は、＋〜0だけでマイナスは伝播しないようにしたほうがいいのかな。
それとも、マイナスだけ流した方がいいのかな。
どっちが攻撃に対して強いのかな。
- 571 ：425：2005/08/03(水) 12:00:36 ID:dOb0lEGI.net
- 振替休日万歳！
ちと、今の仕様だと完全にDMZに置かないと話にならないので、
もう少し安易な物を考えている。
winny上でwinnyする仕様(winny over winny?)
現在同様、自分のキャッシュに入ってる内容は、まったく
分からないし、中継されるファイルの内容も選べないが、
上手くいくとWinnyより早くダウンロードが始まる。
(言うだけはタダ)
公開鍵やキーファイルについての議論がありますが、
これは、既にWinnyでも実装済みの機能だったりします。
キーファイルは、winnyで言う所のキー(ファイル情報)
公開鍵は、winnyで言う所のトリップですね。
ただし、winnyのキーは、暗号化ファイルのインデックスで
あるだけなので、暗号化ファイルからインデックスを逆に
検索を掛けれるので、winnyの暗号化ファイルは可逆で
あります。
そこで、暗号化を不可逆にして、暗号化ファイルからインデックスの
逆参照を不可能にしようと思ったのが、そもそもの始まりです。
- 572 ：425：2005/08/03(水) 12:15:10 ID:4RkUfwZp.net
- それと､匿名性以前の問題でWinnyでは、コネクションの確立
方法は、β1.0から全て共通です。
つまり、どんなP2Pソフトでもコネクション接続要求の
パケットを止められてしまうと何処とも接続できない。
コントロールポートをUDPに限定すれば、UDP53番ポートを使うとか、RTPヘッダをつけるとか、いくつか打開策はあり。
- 573 ：login:Penguin：2005/08/03(水) 18:13:41 ID:vcqACEF4.net
- >>572
パケットを蹴られないようにするだけなら、HTTPリクエストに偽装するとか方法はあると思う。
(流石にWeb閲覧を全面的に蹴るプロバイダはいないだろうし)
パケットが通るかどうかまで心配するとなると、それこそインターネットの再発明になるから
実装する気にもなんないんだけど。
Winnyのネゴは結構正直にやりすぎな気はするんである程度の偽装は必要かもしれないけど
細かいところに凝りすぎて、全体を見失ないつつある気がする。
「通信している内容は単独復号できない」
「通信をしているのはノードの意思ではない場合がある」
これだけで、多段プロクシとしての匿名性は得られてるんじゃないかな。
- 574 ：login:Penguin：2005/08/03(水) 20:33:33 ID:huf+rSCg.net
- 通信がノードの意思でなくとも警察が要求すれば
ログの提出しなきゃならないってことはないの？
- 575 ：425：2005/08/03(水) 21:13:48 ID:bxsn0g1D.net
- パケットの量は、80番(HTTP)より53番(DNS)の方が多かったりする。
あと、サーバ動かしていたら、そのポートつかえません。
well-knownポート使った偽装は、明らかな偽装なので、面白みに
欠けるのでRTPヘッダを使った方が面白いかもしれません。
リアルタイム通信のパケットを時間をかけて調べる事は出来ません
からね(w
- 576 ：login:Penguin：2005/08/03(水) 22:47:17 ID:2/5EZX4h.net
- ログ以前に、中継してるだけで限りなく黒に近い。特にwinnyみたいに99%違法流通してるようなところでは。
- 577 ：login:Penguin：2005/08/03(水) 23:24:14 ID:huf+rSCg.net
- どうせユーザ数が多くないと話にならないだろうし、だったら
2ch的なものと混ぜてしまえばいい。
2chブラウザより使い勝手を良くして、2chやその他bbsのログを
一本化して共有、●なくても読み書き可能にすれば2chは用済み、
2chのユーザ+nyのユーザを乗っ取れば膨大な掲示板トラフィックと
区別が付かなくなる。
- 578 ：425：2005/08/04(木) 01:10:23 ID:WsgB/OyK.net
- >>576
>中継してるだけで限りなく黒に近い。
と言うか、黒なファイルが中継されるであろうクラスタに
属している事自体に法的問題があると思われる。
つまり、winnyの暗号化ファイルが可逆である事がそもそもの発端。
中継動作しているものに暗号化ファイルが何であるか不明にすれば
いいだけ。
>577
>どうせユーザ数が多くないと話にならないだろうし
ユーザが少なければ、逆に表沙汰にならないので
逆に問題ない。
1024以下はroot権限ないと起動できないから、その辺が鬱陶しい。
Xenと併用するのであれば、問題ないが面倒。
RTPヘッダを使うと、リアルタイム通信として扱われるので、
下手に、通信のタイミングをずらすような処理が出来ないのが
ポイント(w
あとは、適当にRTPヘッダを使う大義名分を考えればいいか・・・
- 579 ：login:Penguin：2005/08/04(木) 01:38:50 ID:iT6MgWDt.net
- ばかじゃねーの。もし、winnyのキャッシュがキーなしで復号できなくても、黒は黒だろ。
winnyのネットワーク自体が真っ黒なんだから。
何が問題ないんだか。
- 580 ：login:Penguin：2005/08/04(木) 01:48:24 ID:CWTMyEJZ.net
- >>579
うｐろだの管理人も真っ黒になってしまいますね
- 581 ：login:Penguin：2005/08/04(木) 08:47:47 ID:mCeiRwwd.net
- 当然でしょう
- 582 ：login:Penguin：2005/08/04(木) 09:02:27 ID:lKwo9ozd.net
- 復号できないのに黒だとわかる>>579ってすごいですね。
でも証明できないんじゃ意味がないですよね。
- 583 ：login:Penguin：2005/08/07(日) 23:49:45 ID:MAErsDxd.net
- けんか腰の奴と一緒になってけんか腰で議論する必要はないない
- 584 ：login:Penguin：2005/08/08(月) 03:26:21 ID:GElm0bvw.net
- まだですか。
bitなんたらで洋物エロ動画落としてるんだけど、全然速度でねぇしjavaのazura何とか
すげぇメモリ食うからやだし。
そもそもそういう用途に使うもんじゃないから匿名性なんてまったくないし。繋がってる相手丸見えだもんよ。
- 585 ：login:Penguin：2005/08/12(金) 16:49:10 ID:++zxKhYc.net
- ｗｉｎｎｙて
1 匿名性
2 分配方式
の2点が特徴に思いますが
2のみだけでもオープンソースでできれば
後は勝手に1を満たすよう誰かが進化させてしまうんじゃないでしょうか
誰か匿名性の無い分配式共有ソフトをつくってくれませんかね （厨房より）
- 586 ：＿：2005/08/15(月) 00:39:47 ID:kuEK/e6W.net
- つうか、Winnyのソースって出回ってるだろ?
ある種のオープンソースでねーか?
- 587 ：login:Penguin：2005/08/15(月) 06:24:45 ID:WYCWTctv.net
- >>586
UpとDownの著しい不均衡とか、キーがちっとも広がらないとかいう問題は、
クローズドだからこその解決法でなんとかしてたわけで。
もし、全盛期に改造ビルトが流行ってたらネットワークは維持できてなかったと思う。
v4キーの書き換え(キーハッシュの衝突の脆弱性)でも一時やばかったわけだし。
そういうとこを含めて、公開しても大丈夫なシステムが組めればいいなと
>>585
BitTorrentじゃないの、それって。
- 588 ：login:Penguin：2005/08/28(日) 21:06:16 ID:jFvBDF3F.net
- よくよく考えてみると、47氏はwinnyを開発した事による
著作権幇助の疑いで捕まったわけですよね？
オープンソースで、バイナリではなく、ソフトをソース配布すれば、
技術のない房は弾けるし、「表現の自由」によって「憲法」で
保護されると思うのだがどうよ。
ソースはCのような高級言語でなくても、アセンブリでも問題ないと思われ。
47氏も、アセンブリでソース配布すれば、めんどくさい裁判を受けなくて住んだかも?
- 589 ：login:Penguin：2005/08/29(月) 12:10:02 ID:8UYsqZTy.net
- >>588
ひょっとしてそれはギャグで（ｒｙ
- 590 ：login:Penguin：2005/08/29(月) 15:48:03 ID:Lic1bBnN.net
- *+*++*+/.,/.,/.,/.,//,/:;*+*+*+*+
＿｜￣｜○
*+*+*+*+・。、・。、・。、＊＋＊＋？＜？＋
：；：?。*；+*>*＞？＜＞？？＜＞＊＋・。、・。、＊＋
- 591 ：login:Penguin：2005/08/30(火) 15:57:40 ID:4Ij1IBiF.net
- decss?
- 592 ：login:Penguin：2005/09/04(日) 01:44:20 ID:hmo/M5vH.net
- 所 詮 パ ク リ
- 593 ：login:Penguin：2005/09/04(日) 14:39:29 ID:pXpKd7Rm.net
- そ れ 以 前 の 問 題 だ と 思 う が
- 594 ：login:Penguin：2005/09/20(火) 13:51:25 ID:PscRxDnC.net
- いざ作ってみるとなかなか難しいものだな。
- 595 ：login:Penguin：2005/09/22(木) 05:05:33 ID:jWL/+1Tx.net
- 製作者ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!
(´-`).｡oO(というか真面目にむずいよな）
- 596 ：login:Penguin：2005/09/22(木) 19:33:00 ID:hK6hjCOG.net
- > オープンソースで、バイナリではなく、ソフトをソース配布すれば、
> 技術のない房は弾けるし、
勝手にコンパイルして配布する人や、まとめサイトを作ってくれる人に
関してはどう対処する？
> 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。
憲法をどう解釈するかに関しては、裁判所でどうぞ。
- 597 ：login:Penguin：2005/09/24(土) 15:57:21 ID:on+fKY/Q.net
- ○学生の出てくるエロ漫画を描いても、表現の自由で保護され･･･たっけ？
- 598 ：login:Penguin：2005/09/24(土) 16:05:18 ID:uOc/XLUk.net
- >>597
宗教ならおｋじゃなかったか？
- 599 ：login:Penguin：2005/09/25(日) 01:33:10 ID:/r0bHCUi.net
- 47氏の本が出版されるらしいね。Linny開発に弾みがつくといいな。
- 600 ：login:Penguin：2005/09/28(水) 17:26:52 ID:Ej2805fD.net
- その本をスキャンしたやつをlinnyに流そうぜ
- 601 ：login:Penguin：2005/09/29(木) 22:05:37 ID:BIai3mBJ.net
- > 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。
要は、「爆弾の作り方」は書いても言いが、「爆弾を作ってはいけない」
ってことだな。バイナリで流してる奴がいたら、そいつが捕まって、
はい、オシマイってわけ？人生そんな上手くはいかないよ。
- 602 ：login:Penguin：2005/09/30(金) 02:55:59 ID:G/RjxJmT.net
- 作り方と作ることを、バイナリとソースの対比で言い出したら、
バイナリでもOS上で実行しない限り走らな(ry とかになってくるし。
アイデアは良くて、アルゴリズムはダメでとか、
アルゴリズムはいいけど、走るソースはダメだとか。
結局、何を配布したとしても、最終的に自分の意志での実行コマンドの発行が必要である以上
ウイルスとかの自動実行系の配布とは一線を画するとは思うんだが。
- 603 ：login:Penguin：2005/09/30(金) 13:26:30 ID:U0TBEIz/.net
- 京都府警はおろか司法の中の人たちも、この手の新しいテクノロズィに関する
お話になると、どうも理解があやしい。
挙句、既成概念の外からやって来た”異物”に対して、理論的根拠なきまま
攻撃的に排除する方向で対応している。
社会システムの理性であるべき司法も所詮、硬直化した官僚組織だ。
構造改革は行財政だけでなく、司法にも直接メスを入れる必要があるな。
- 604 ：login:Penguin：2005/09/30(金) 13:29:14 ID:os075Rrp.net
- >>603
藻前が何を熱く語ったところで、世の中変わらないから安心して妄想汁。
- 605 ：login:Penguin：2005/09/30(金) 13:44:53 ID:U0TBEIz/.net
- これはこれは。
素早い反応、乙であります。
- 606 ：login:Penguin：2005/10/02(日) 02:27:49 ID:akB9j0NI.net
- 603が一番理解があやしそうだが。
- 607 ：login:Penguin：2005/10/02(日) 03:31:25 ID:XdmTWX16.net
- >>603
既成の概念を破ることを悪いとは言わないが、
破ることによって新たに得られる物がまだ準備できない段階で、
むやみに破壊するってのもやばいでしょう。
異物が成功することのほうが少ないんだし、排除しようとする動きは当然かも。
- 608 ：login:Penguin：2005/10/03(月) 22:23:47 ID:lHDFlLbA.net
- > 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。
まぁ、未だに64kの低速回線でファイル共有自体には興味はないが、
これはあながち間違ってはいない。
と言うのは、Winnyによる著作権侵害の問題が社会問題にまで発展したの
には、マスメディアの力によるものが大きい。それでも、マスメディアが
「表現の自由」に守られているからです。
かつて、「OPEN-SSL」の輸入が米国の法律上の関係で、認められない時期がありました。
しかし、何処かの頭のいい馬鹿が、ソースをプリントアウトして日本に持ち込みました。
その時代、電子データは「人が読めるもの」であっても「文書」には当たらなかったのですが、
プリントアウトして、尚且つソースは「人に読める」ので「文書」になります。
「文書」になった地点で「表現の自由」が認められ、晴れて輸入できたわけですね。
現在では、「電子データ」であっても、人が読めるものであれば「文書」になるので、
「表現の自由」が認められるワケですね。
あ、でも昔、コレと似たような問題として「偽造テレカ」の問題がありました。
当時の法律では、コレを「偽造」とするのには難しい物があり裁判所が、
ムリヤリこじつけて有罪にしてました。
興味がある方は調べてみてください。
- 609 ：login:Penguin：2005/10/03(月) 22:34:53 ID:lHDFlLbA.net
- 一応、関連分野だけど、どうでもいいネタを思い出した。
SQLインジェクション攻撃は、多くの場合、日本の法律では「不正アクセス」には
なりません。
だって、名前を書く欄に人間が読める文字(SQL)を打ち込んだら、
「頼んでもいないのに」 「勝ってに」 「向こうから」
情報を送ってきますからね。
- 610 ：login:Penguin：2005/10/04(火) 00:04:49 ID:3MN3X/VT.net
- >> 609
勝手に送られてきた情報でも、悪用すれば損害賠償に発展するし
利益が伴えば横領だろうから、よい個はやらないように
- 611 ：login:Penguin：2005/10/06(木) 20:54:13 ID:d52gi3Mh.net
- 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.net
- 47氏に「こちらの設計能力不足によるもの」なんて言われても・・・
- 613 ：login:Penguin：2005/10/10(月) 14:04:07 ID:rLVx9fSs.net
- 47氏の本を読んだ人、なんか言うことあったらどーぞ
- 614 ：login:Penguin：2005/10/10(月) 18:21:40 ID:7ub5fEMT.net
- ﾉｼ
・pthread使えよ
・コネクション開けすぎだろ
・DOM対策は黙殺かよ
- 615 ：login:Penguin：2005/10/10(月) 23:20:57 ID:qNvmUTIs.net
- >>614
つーかDOM対策の仕方が分かんないからオープンソースにできないんでしょ？
- 616 ：login:Penguin：2005/10/11(火) 01:45:25 ID:kh40LmyH.net
- つうか、回線資源が豊富な時代のファイル交換ではない「ファイル共有」に、
『DOM対策』と言うのは、多発する自動販売機荒らしのためにガードマンを
雇うようなものだろう・・・放置で問題ないのでは？
あと、帯域制御ではなく、パケット優先制御にするって手もありそうだが実装が面倒だろうな。
- 617 ：login:Penguin：2005/10/11(火) 10:11:42 ID:PfV9tu8k.net
- >>614
Windows用のソフトでpthread使えと言う方がどうかと思うが
- 618 ：login:Penguin：2005/10/13(木) 20:30:00 ID:aQX6KbtT.net
- Linnyへの言及は無かったの？
- 619 ：login:Penguin：2005/10/16(日) 14:22:14 ID:Pzhwvu3/.net
- 俺が47氏と対談してやろうか？
確か東大教授だったか。
いやマジで。
- 620 ：600：2005/10/18(火) 18:32:18 ID:OVuRaYPv.net
-
金子勇氏が『winnyの技術』PDF版の配布を開始
http://news19.2ch.net/test/read.cgi/news/1129625712/
- 621 ：login:Penguin：2005/10/19(水) 18:54:23 ID:wirADuqX.net
- 47氏の逮捕が残念でならない。
あと、数年逮捕がなければ
ｌｉｎｎｙは実現してたんじゃないかと
それは、ｌｉｎｕｘの普及に弾みを付けたであったろうに
金子さん残念です。できそうにないっす（ノ＿・、）
- 622 ：login:Penguin：2005/11/01(火) 18:58:39 ID:AD9WRUWi.net
- http://www.2chlinux.org/index.php?Winny
wine de winny
これを使えばｌｉｎｎｙは不要なんだね
- 623 ：login:Penguin：2005/11/06(日) 17:17:06 ID:Tn4QjnGn.net
- 前スレくらいに、47氏が来てたきがする。
- 624 ：login:Penguin：2005/11/06(日) 21:04:51 ID:XTX2yjfR.net
- >>623
Linny開発プロジェクト
http://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.net
- Project page not found
- 626 ：login:Penguin：2005/12/16(金) 21:15:51 ID:xaaeI0JY.net
- 掛け声ばかりで何もしないのが犬糞ｸｵﾘﾃｨ
- 627 ：login:Penguin：2005/12/17(土) 07:19:10 ID:TnkcQday.net
- Azureusでいいんじゃないかな？トラッカー不要だし、匿名でもできるんでしょ。
- 628 ：login:Penguin：2006/03/12(日) 18:35:31 ID:pV0uMcQl.net
- poenyとか作っちゃった人いるし。
- 629 ：安倍：2006/03/15(水) 22:18:54 ID:6/zNNY2A.net
- ここも閉鎖してくださいね
- 630 ：login:Penguin：2006/03/15(水) 23:04:18 ID:ZjUHtBRx.net
- >>629
なにげにIDにNYはいってるな。
- 631 ：login:Penguin：2006/04/08(土) 23:52:50 ID:1z63VHJc.net
- お宝動画.mpg .sh*
- 632 ：login:Penguin：2006/04/10(月) 17:24:40 ID:Qx/LpCHc.net
- >>631
./お宝動画.mpg.sh
- 633 ：login:Penguin：2006/04/17(月) 02:23:40 ID:lVQElzvx.net
- poenyのコードが出ているからLinuxに移植して、shareにも対応させてくれ。
- 634 ：login:Penguin：2006/04/17(月) 04:51:08 ID:dIINE0d7.net
- >>633
pyny ってのなら OS independent みたいだが。
http://pyny.sourceforge.net/
- 635 ：login:Penguin：2006/04/18(火) 00:34:17 ID:7qWnvAZT.net
- いいね。まだ完成は遠そうだけども。
- 636 ：login:Penguin：2006/04/19(水) 08:49:27 ID:fuiVWiVy.net
- 何このスレ…
ただ議論してるだけの口だけですか、ざっと見たところコードの一つも書かれてないしねぇ。
ダメだねこりゃ。
ま、ネタだからいっか！
- 637 ：login:Penguin：2006/04/19(水) 18:12:57 ID:aO8UYN14.net
- オープンソースでもうまくいくアイデアが出てきてないのに
コード書いてどうすんの？
- 638 ：login:Penguin：2006/04/19(水) 23:38:54 ID:iW2WqGmJ.net
- この程度のはさらっと無視しようよ。
- 639 ：login:Penguin：2006/04/20(木) 02:01:26 ID:PojcW3ph.net
- >>638
真性の馬鹿かよ…お前。
今まで議論してきたんならそれをまとめ上げて設計を煮詰めることぐらいできるはずだろう？
しかもオープンソースでもうまくいくアイデアて…。
それよりも進める、進めるべき問題があるだろうに…所詮ここに居る人間は
ただWinnyのLinux版が欲しいだけの、ただの無能なんだろうよ。
絶対に完成することは無いと断言する。
まぁそれでも馬鹿みたいにナーナー喚いてたいなら、そうしてればいいんじゃないの？
- 640 ：login:Penguin：2006/04/20(木) 11:45:35 ID:kn8mRmOs.net
- 春だな。
- 641 ：login:Penguin：2006/04/23(日) 16:24:21 ID:4/zRYzSe.net
- 639がなんでそんなに必死なのかわからんな。
ﾏﾀｰﾘｦﾁの邪魔すんじゃねぇよｳﾞｫｹが。
- 642 ：login:Penguin：2006/05/09(火) 21:58:56 ID:BY7OQNQc.net
- んで、どこまで進んでるの？
- 643 ：login:Penguin：2006/05/09(火) 23:01:55 ID:+PKMm0aS.net
- ネタスレ上げんな
- 644 ：login:Penguin：2006/05/10(水) 00:28:44 ID:q5RoQNNY.net
- オープンソースの必要なし、それに、匿名で、つくらないと警察がうるさいのでだめだろう。
- 645 ：login:Penguin：2006/05/16(火) 18:02:37 ID:bb3cOoYb.net
- 勇気あるやつはいないの？
俺は形式的にやめとけと言っとくけど。
- 646 ：login:Penguin：2006/05/17(水) 12:48:33 ID:pJkTeqZ7.net
- 勇気は、あるけど、つくる技術がない。
つくれたらWinnyで匿名で流す。
- 647 ：login:Penguin：2006/05/17(水) 12:53:25 ID:2TSMmOa8.net
- 俺は勇気と技術はあるが、やる気がない。
大半の奴がそうだろ。やる気さえあれば全部ついてくる。
- 648 ：login:Penguin：2006/05/17(水) 20:15:43 ID:/kiMxzMb.net
- 俺はやる気がないから、技術がない。
大半の奴がそうだろ。やる気さえあれば全部ついてくる。
- 649 ：login:Penguin：2006/05/18(木) 01:05:34 ID:6S1wN1WK.net
- やる気があっても、技術はなかなか身につかないんだよ。
簡単にいうな。
- 650 ：login:Penguin：2006/05/18(木) 09:22:16 ID:Z8fGq0bJ.net
- 納期のある仕事じゃないだろ。身につくまでやるだけさ。
- 651 ：login:Penguin：2006/05/19(金) 01:15:22 ID:TU/BQMI9.net
- とりあえず、JAVAを勉強すればいいのか？
- 652 ：login:Penguin：2006/05/19(金) 03:08:09 ID:TU/BQMI9.net
- perl や Javascriptでは、無理か？
- 653 ：login:Penguin：2006/05/19(金) 04:17:38 ID:aTw9MFAu.net
- perl は POE でできるんじゃね？
Javascript って、常駐プロセスできるの？
- 654 ：login:Penguin：2006/05/21(日) 01:15:24 ID:BV3/rKWP.net
- 最近のISPポート遮断も考慮に入れないとな…
- 655 ：login:Penguin：2006/05/21(日) 02:14:01 ID:7NI4CdpF.net
- 7743 でいいんじゃね？
- 656 ：login:Penguin：2006/05/22(月) 05:42:41 ID:wwhT7Auj.net
- やっぱりperlじゃ無理だろ。
JAVAでつくることにして、JAVAでも勉強するか。
- 657 ：login:Penguin：2006/06/11(日) 15:12:52 ID:j2Yz1QFx.net
- 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.net
- ・保証済みリストの追加は…
該当のノードから一定量のデータ供給があった場合
保証者認証にて保証済みと認定された場合…などなど
・保証無しノードについて
保証無しノードを一方的に拒否すると
ノードがネットワークへ参入ができない
回避策としては保証済みと保証無しノードで
優先度(帯域制限とか)を変える
・仕様のバグ
保証者認証要求を何でもOKと返すノードが増えると全く意味なし
各ノード毎に優秀なデータベースが必要
トラフィック量が認証の通信だけでﾊﾝﾊﾟﾈｪ
仕様のバグあったら指摘よろしく
やる気でたらそのうちコード書くんでよろしく
自分プログラミング初心者なんでよろしく
- 659 ：login:Penguin：2006/06/14(水) 23:12:12 ID:3WQsyC6y.net
- 初心者ならまず作ってみてそれが可能か確かめることだ
- 660 ：login:Penguin：2006/06/15(木) 02:46:48 ID:ikJkVB7c.net
- 理論的には不可能じゃない。
処理能力的に不可能。
- 661 ：login:Penguin：2006/06/30(金) 12:45:51 ID:8rNwoRlz.net
- Winny今日でオワリ＼(^o^)／
- 662 ：login:Penguin：2006/11/08(水) 13:31:51 ID:W7dud1LU.net
- 進展あり
- 663 ：login:Penguin：2006/12/31(日) 12:30:02 ID:VZWpvELQ.net
- ttp://linny.sourceforge.jp/
404出てるが。。
- 664 ：login:Penguin：2007/01/12(金) 21:38:38 ID:5RZHoj7P.net
- なんかすげぇｗｗｗ
- 665 ：login:Penguin：2007/01/13(土) 05:29:57 ID:+PPdjV/T.net
- このプロジェクト復活するのかな
- 666 ：login:Penguin：2007/01/13(土) 07:58:59 ID:DaWyErcl.net
- wine+winnypでいいじゃん
- 667 ：login:Penguin：2007/01/13(土) 10:40:54 ID:BfnrT5+F.net
- ひろゆきは嫌いだけど2chは好き。是非開発してほしい。
- 668 ：login:Penguin：2007/01/13(土) 11:38:40 ID:+PPdjV/T.net
- Linuxの爆発的普及のきっかけになるかも知れないのに・・・
- 669 ：login:Penguin：2007/01/13(土) 11:49:27 ID:TsrbH3i8.net
- Linnyが普及すれば、掲示板もあるし、アップローダも付いてるし、Linux普及を盛り上げてWindowsのシェアを大幅に下げる祭りができるし、良いことずくめ。
- 670 ：login:Penguin：2007/01/13(土) 12:36:05 ID:0o36Q73e.net
- winny開発が有罪なんだからlinnyも・・・
- 671 ：login:Penguin：2007/01/13(土) 12:41:18 ID:TsrbH3i8.net
- ばれなきゃ良いんだよ。
- 672 ：login:Penguin：2007/01/13(土) 14:01:39 ID:iK5MOlrr.net
- グリーンダヨ！
- 673 ：login:Penguin：2007/01/13(土) 20:52:42 ID:BfnrT5+F.net
- P2P掲示板だけでいいから誰か作ってYO!!!
- 674 ：login:Penguin：2007/01/13(土) 21:40:17 ID:TsrbH3i8.net
- >>673
ほらよ
http://shingetsu.info/index.ja
- 675 ：login:Penguin：2007/03/27(火) 11:14:35 ID:5bVcjYXr.net
- いまだにできないということは日本の
ハッカー、LINUXER、２ｃｈねらーは
レベルが低いということでよろしいか
- 676 ：login:Penguin：2007/04/01(日) 10:21:45 ID:Ef2nx0n0.net
- 日本人にハッカーなんていないでしょ。
せいぜいHP書き換えたりクレカ番号盗んだりするスクリプトキッズがいるだけで。
- 677 ：login:Penguin：2007/04/01(日) 10:26:18 ID:liwrsMPf.net
- ハッカーですって言う奴いるの？
- 678 ：login:Penguin：2007/04/01(日) 16:03:10 ID:WazxHIEt.net
- 金子勇
- 679 ：login:Penguin：2007/04/03(火) 04:56:44 ID:wNn/7D39.net
- 何かスースーするね。
これ何？
ハッカー！！！！！
- 680 ：login:Penguin：2007/04/04(水) 13:37:57 ID:yYIflZC3.net
- 荷物預けたいなぁ。
あ、あそこにあった。
ロッカー！！！！！
- 681 ：login:Penguin：2007/05/23(水) 19:50:11 ID:yn77ijmC.net
- poenyをLinuxで使えたりはしないのかな？
- 682 ：login:Penguin：2007/07/27(金) 11:08:51 ID:ktyIqQnV.net
- あれからいろいろあって・・・
もうこのプロジェクトのニーズもすっかりしぼんじゃったね。
- 683 ：login:Penguin：2007/07/27(金) 13:00:08 ID:LeXmC4Lv.net
- ニーズに応えようとするとロクな事にならん
- 684 ：login:Penguin：2007/07/27(金) 23:49:08 ID:AgtN6pgh.net
- 行動するやつがいねーから全然駄目ジャン
- 685 ：login:Penguin：2007/07/28(土) 16:28:29 ID:SX3ABxnb.net
- そりゃそうだよ
誰もが変なファイルを欲しがると思っちゃイカン
- 686 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:15:56 ID:lmuP9iVu.net
- え！？
LinnyってWinnyでもう放流されてじゃん
もうVer1.42だにょん
- 687 ：login:Penguin：2007/07/29(日) 23:31:04 ID:3vNf8O1V0.net
- 釣ろうったってそうはいかんざき
- 688 ：login:Penguin：2007/08/14(火) 07:14:41 ID:dAO75AnG.net
- limewireで十分
- 689 ：login:Penguin：2007/11/10(土) 16:35:15 ID:e1dttwm1.net
- Linny 1.43aがdebのパッケージであった
- 690 ：login:Penguin：2007/11/10(土) 17:59:07 ID:x1O44yXp.net
- どうでもいいけどwinnyの規格でwinnyのプロトコルとネットワークを利用して
「対抗する」とはどういうことだw
- 691 ：login:Penguin：2008/11/30(日) 00:58:24 ID:M52Dfabw.net
- で、なんか進展あった？
- 692 ：login:Penguin：2008/11/30(日) 01:36:59 ID:PtRq6nov.net
- 今更winnyプロトコルも無いだろ。
- 693 ：login:Penguin：2009/01/30(金) 13:50:48 ID:rqAG7/h4.net
- wineで動くんだから要らないじゃん
- 694 ：login:Penguin：2009/06/13(土) 11:14:11 ID:UoCK19vt.net
- 長いこと離れてたから、P2Pの今って解らんのだが…
>>692
じゃ、「今時のp2pプロトコル」ってどんなの？
そっから定義していく感じなの？
- 695 ：login:Penguin：2009/06/27(土) 22:50:01 ID:QpZPbqgX.net
- 主流はなんだろね
ShareかPDか
- 696 ：login:Penguin：2010/05/16(日) 01:49:28 ID:0RhxZSNM.net
- BitTorrentだろｗ
- 697 ：login:Penguin：2012/05/04(金) 01:37:28.94 ID:7s1XXkpj.net
- 逮捕しますよ！
- 698 ：login:Penguin：2012/06/17(日) 20:09:55.15 ID:rHHgTy3f.net
- 私は、小学３年です。 は、彼氏がいます。彼とわたしは、デートの時 、どちらかの家に行き、だれもいないとき、部屋 で横になって裸でだきあいます。
それがだんだ んエスカレートしていって、学校の体育倉庫で服 をぬがされ、まだ３年生ですが学年で１番大きい おっぱいを、つかむように触られたり、しゃぶっ たりされます。
最初は、苦手だったんだけどだん だん気持ちよくなりサイコーです。しかも、わたし は、学年１美人でもてます。
彼も同じで、美男 美女でよくみんなにうらやましく、思われます。
: : このカキコ見たあなたは4日後に不幸おとづれ 44日後に死にます。それがイヤならコレをコピペ して5ケ所にカキコして下さい。
- 699 ：login:Penguin：2012/06/19(火) 00:14:28.45 ID:O65fkc/9.net
- IPv6 に対応したものって何かあるの?
- 700 ：login:Penguin：2012/06/24(日) 03:36:31.61 ID:umzlEnuG.net
- Sc_356833.dat
DLキーワード ipv6
どこに置けばいいのかわからず、とりあえずここに置いてみた。
総レス数 700
243 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200