Linny開発プロジェクト Part2

Linny開発プロジェク� ..

529:425
05/07/20 21:51:17 d8u1kb3S
キーファイルA　　　523*769
キーファイルB　　　617*857
キーファイルC　　　677*787
キーファイルD　　　727*643
キーファイルE　　　809*661
キーファイルF　　　563*619
キーファイルG　　　467*647
キーファイルH　　　503*991

暗号化ファイルA　　534749
暗号化ファイルB　　498473
暗号化ファイルC　　402187

キーファイルの右に書いているのが、「暗号化ハッシュコード」で
暗号化ファイルの右に書いているのが、「ハッシュコード」です。

キーファイルから、暗号化ファイルを見つけるには、

キーファイルAの「暗号化ハッシュコード」は、「523*769」

　　　　　523*769 = 402187

なので、「キーファイルA」の暗号化ファイルは「暗号化ファイルC」だと
簡単に分かります。

暗号化ファイルAに対する、キーファイルはどれでしょうか？(制限時間30秒)
普通、ムリですよね？

つまり、「キーファイル」から「暗号化ファイル」は分かっても、
「暗号化ファイル」から「キーファイル」は分からない。

530:425
05/07/20 22:38:29 X6ELMDVA
>StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、
>プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね)
>めんどくさそうと。

　まず、P2Pやるなら市販のパーソナルFWは消しときましょう。
　(つうか、linux用のパーソナルFWってあるのか？)

　つまり、使ってないポートは、全部斬って置いて、使うポートは、アプリ(デーモン)自体が、
　アクセス制限かけないといけません。(httpdとかsendmailとかも、全部そうなってます。)

　パーソナルFWは、全自動で使ってないポートは、全部斬ってくれるだけで、
　他は大した事はやってくれません(FWとウイルス対策ソフトは基本的に違うモノです)。

　つまり、P2Pといっても『サーバ』なので外からの、アクセスを許すことになるので、

　必ず、それ相応のリスクは必ず伴います(Winnyのウイルスとか)。

　まぁ、デーモンの起動ユーザをプロセスごとに複数の一般ユーザ分ければ、
　実質的な被害は、あまり出ないでしょうけど。

531:425
05/07/20 22:39:39 X6ELMDVA
>プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、
>インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。
>そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、
>他で代替可能でないのかについて、ちょっとよくわからなかった。

　結論から言うと、プロキシの方が、セキュリティ面をしっかり考えなければならない。

　「ポートフォワード」で、セキュリティが懸念されるのは、ネットワークの内側(LAN内)に
　ネットワークの外側（インターネット）からアクセスがあるからです。

　これでは、FWを付けても、その穴から突破されれば、無防備なLAN内のPCに簡単に
　アクセスされてしまいます。

　一方、P2Pは、「自分」と「その他」の概念しかなく、BがCに「ポートフォワード」して、
　AがCにアクセスした所で、セキュリティー的には、AがCに直接アクセスするのと変わりません。

　Bは、単なるルータにすぎません。

　しかし、プロキシの場合、デーモンつまり、アプリ自身が提供するサービスなので、
　アプリ自体に、バグがある場合、速攻で攻撃対象になります。

532:425
05/07/20 23:16:59 fW484GcX
>ちなみに。
>RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ

「RSA公開鍵ペア」はIPを交換する鍵ですよね？

「書き換える」ためには、「キーファイル」と「暗号化ファイル」の双方を所持していかないと、
書き換えられません、さらに、書き換えた「キーファイル」と「暗号化ファイル」を流通させないと
いけません。

とても、面倒で時間がかかります。そんな事しなくても「キーファイル」と「暗号化ファイル」を

もっていれば、どこの「中間ノード」と思われるノードが、「どんな」ファイルを
欲しているかは分かります。

じゃあ、何故「中間ノード」を攻撃するのか?　単にクラックが目的であれば、中間ノードなど
関係無しに、当たりかまわず攻撃しまくればいい。

つまり、結論としては、単なる「クラッカー対策」

クラッカー対策は、全てに通じるもので、P2Pに限った問題ではありません。
(それが難しいのですけどね。)

533:425
05/07/20 23:18:49 fW484GcX
>信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。

　信用を集めてから、粗悪なファイルを流すということですか？

　攻撃にしては、時間がかかりすぎると考えられるし、さらに信用を集めるための
　ファイルは、何処から持ってくるのかという問題がある。

　さらに、匿名性自体を犯す攻撃じゃありません。

　結局、得するのは信用を集めている間に、ファイルを得た人々だけです。

534:425
05/07/20 23:39:06 BeHtAV13
>>527
>NAT は Skype とかが使ってる UDP なんちゃらで解決しないのか？

UDP hole punching のことですね。

私も、あまり知らないんで詳しい事はいえませんが、

これは、あるサーバーが、IPとポートを貸し出し、通信を
ネットワークレベルで仲介してくれる技術です。

まぁ、これをP2Pと呼べるのか？という疑問もありますし、
匿名性の概念はありません（と思う）

さらにいえば、現在の仕様では、NATの中は通してもらえません。

535:login:Penguin
05/07/21 02:58:11 z2CP8IVj
>>532
中間者は、自分用のRSA鍵ペア(ポート用とファイル用)を作っておき、キーファイルの伝播の際に
1-3) 1-4)を自分用のものにすりかえて、1-2) 1-5)をあわせておく。
暗号化ファイル検索要求が来れば、おもむろに自分の秘密鍵で検索をかけたノードを復号できる。
この書き換えは、もともとのキーファイルを持っているだけでよく、
(中身を知る必要がなければ)暗号化ファイルは必要ない。

システム的に排除できる可能性は、1-4)の公開鍵が実績があるかどうかでキーの信頼度を
決めることだろうけど、簡単に信頼度を集められるようにすると、少し正常動作をしてあとは釣り人に
なればいいだけだし、あまり難しくすると長い間同じ鍵を使わなくてはならなくなるのでノードの特定に
繋がったりしそう。

完全に書き換える必要はない。単に、キーファイルが「それっぽい」だけでいいんだから。
せっかくRSAで検索送信者保護をしても間に入られたら意味ないなとふと思っただけだけ。
要求の転送で隠せるからある程度はいいけど、Winnyと同程度になっちゃうな。

536:login:Penguin
05/07/21 03:05:45 iQmD7UoW
データ本体のキャッシュの寿命の方はどうなってんの？
完全なるクラスタになっていないかぎり、キャッシュ中のデータのほとんどが要、不要がわからないデータなわけだろ？
要不要が即わかるほどキーファイルが流通するネットワークなら、
わざわざデータファイルのメタデータを隠蔽する意味が不明だし。

転送機能なんてほぼ意味ないよ。
となりがキャッシュをはじめから持ってるのと、いまからキャッシュにし始めるということと、どう違うわけ？クラスタ化されていない状態なら、無駄なキャッシュが増えるだけ。

いかれたパケットを送出するのに、root権限が必要なのだが、それはどうでもいいの？

っつーか、ノード数、ファイルサイズ、ファイル数、各ノードのキャッシュ容量とかどの程度のものを考えてるのかね。

537:login:Penguin
05/07/21 03:20:49 z2CP8IVj
>>531
A->B->Cのポートフォワードがおこっているということは、CがBに依頼したということでOK？
この状況で、B->Cのポートフォワードが悪用されたらBはインターネット的に責任をまぬかれるのか、
ということを心配したんだけど。
Cに依頼されたので、Cが落とされるようなパケットが転送されたとしても、依頼したCが悪いんです。
で問題ないか。

もしBが悪意のノードで暇人で、来たパケットを転送する前にごにょごにょ書き換えて送ったとしても
Cは依頼する前にBの悪意を見抜けなかったから泣いて下さい、でシステム的にはOKか。
パケット転送はファイルの転送のみに使用して、コネクションを管理するポートには使わなければ
致命的にはならないね。

538:login:Penguin
05/07/21 13:39:18 +geUQqPb
(´-`).｡ｏO(今度こそモノになるかな）

539:login:Penguin
05/07/21 14:28:00 RTcoM3Vh
ｌｉｎｕｘ普及のためにOOoに匹敵するプロジェクト
完成を期待します。

540:login:Penguin
05/07/22 21:09:49 ySzGffYS
ネタ切れか

541:login:Penguin
05/07/22 21:11:58 tBkDAb44
誰か僕にネットワークプログラミングのやり方を教えてください。

542:login:Penguin
05/07/22 23:31:16 eHH1w66m
しばらく見ない間に随分賑やかになっとるなぁ

少し読んでみたのが実際に動き出した時、これがどの程度動くのか、わしにゃ分からん。

>>502

2-3)IP/ポート交換ワンタイム秘密鍵(RSA 128bit)
　　　　ファイル最後尾から、128bitが1-3)に対する秘密鍵になっている。　　　　
　　　　詳しくは、後述。

「ファイル最後尾」に意味はまったくない。

キーファイルの公開鍵でIPを暗号化して、暗号化ファイルの所有者だけに分かるように渡すんでしょ？

ファイルの先頭につけると秘密鍵だけを抜き取られてしまうと考えたんだと思うけど、
レジューム機能を実装させると、まったく意味がないような気するがどうなの?

まぁ、批判は簡単なので暗号化ファイルを全部落とさないと、秘密鍵が分からない仕様を考えてみた。
要は、ハッシュコード生成を少し変え、秘密鍵に非常に軽量な暗号をかける。

543:login:Penguin
05/07/22 23:34:12 eHH1w66m
2.暗号化ファイル（バイナリ形式）

　　2-1)ハッシュコード (変更)
　　　　2-4)をハッシュにかけた値(MD5) を、さらに2-3)を連結させて
　　　　再度、ハッシュにかけた値(MD5)

　　　　ノードにキャッシュされる度、随時上書きされる。

2-2)IP/ポート交換ワンタイム秘密鍵
ノードで毎回、計算される。
　　　　
　　　　計算方法は、2-4)をハッシュにかけた値(MD5)と2-3)の
　　　　XORをとった値が、IP/ポート交換ワンタイム秘密鍵となる。

　　　　2-4)をハッシュにかけた値(MD5)は、2-1)を生成する際に計算したものを
　　　　利用できるので、計算量としては大した事はない。

これは、ファイルとは直接関係ないトランザクションデータとして扱われる。

　　2-3)XOR_IP/ポート交換ワンタイム秘密鍵(RSA 128bit) (変更)
　　　　「ファイル先頭」から128bit。

　　　　単に、2-4)をハッシュにかけた値(MD5)とIP/ポート交換ワンタイム秘密鍵のXORをとった値。もう一度、2-4)をハッシュにかけた値(MD5)でXORをとると元に戻る。つまり、完全な2-4)がない限り2-3)から2-2)は分からないってコト。
　　　　非常に単純な方法だが、手強いはずだ(w

　　2-4)データフィールド
　　　　暗号化された、データが入っています。

ま、わしにゃ、こんな事ぐらいしか思い浮かばんが、ガンバっとくれい。

544:login:Penguin
05/07/23 00:07:29 vcii9dn+
乗りかかった船なので、私的に、明かに的外れだと思われる質問に勝手に答えてみる。

>>537

>>513
　しかし、このままでは不正利用を招くので、ノードBには、TCPのPSHパケットと、UDPパケットは
　転送しないよう設定します。

要は、ノードBからは、TCPのコントロールパケットしか飛んで来ないわけだ。

つまり､ACKパケットを、RSTパケットに変えて送った所で、通信が切断されるだけ。
そんな事を、するだけであれば単に中継しなければいい(中継すると契約しといて実はしない)。

しかも、書き換えて攻撃するなど、ややこしい。セキュリティ的には直接攻撃されているのと
変わらん。やる意味がない。攻撃といっても、単に一方的にファイルを送りつけるだけのポートに
できる事って何がある?

さらにいえば、どちらかと言えば、悪意あるノードがノードBを踏み台に攻撃する方が
多いと考えられる。だから、上記の>>513のような一文が加えられているのだと思う。

あってるよね? > 425

つうか、今この質問に答えていて思ったのだが、レジュームの実装って難しいんじゃねぇのか?

545:login:Penguin
05/07/23 11:32:29 jtlytnMJ
　　　　　　　　　　　　　　　　　　　　　　た
　　　　　　　　　　　　　　　　　　　　し
　　　　　　　　　　　　　　　　　　ま
　　　　　　　　　　　　　　　　り
　　　　　　　　　　　　　　い
　　　　　　　　　　　　ま
　　　　　　　　　　て
　　　　　　　　っ
　　　　　　が
　　　　上
　　り
盛

546:425
05/07/24 23:41:51 hPPfaUHc
私用PCが・・・クラッシュしちまった＿|￣|○

さらに、夏風邪をこじらして寝込んでしまった。

気を取り直していきましょう。

なんか、活気付いてきましたね。どんどん、意見交換して行きましょう(w

ここで提示しているのは、単なる案ですから、ここをこういう風にした方がいい
って意見は、特に大歓迎です。
>>534

　自己レスです。UDP hole punching について、私の中で勘違いがあったので、書き直しておきます。

　「UDP hole punching」は、IPマスカレード(NAPT)によって書き換えられた、送り元ポート番号,IPアドレスを
　親サーバ上で交換し合い、UDPで通信する仕組みです。上手いこと、システムを騙した通信で面白い。

　ですが、必ず、交換し合う親サーバが必要なのと、親サーバが十分信用できないとセキュリィティが守れません。

　あと、匿名性の概念もまったくありません。

　しかも、そのUDPパケットがFWで弾かれることが多いので、実質的に使える機会は非常に少なかったりします。

547:425
05/07/24 23:45:22 hPPfaUHc
>>535

>中間者は、自分用のRSA鍵ペア(ポート用とファイル用)を作っておき、

　『鍵ペア』って、そう言う意味だったんですね。
　
　私自身は、1-4)とノードの関係は、現実世界で余ほど目に余る行動を取らない限り、
　バレる事はまずあり得ないと、考えています。

　仮にバレたところで、1-4)は、『情報の保障』をしている一文であって、
　ファイル提供者かどうかを、定めている一文ではありません。

548:425
05/07/24 23:46:38 hPPfaUHc
>キーファイルの伝播の際に 1-3) 1-4)を自分用のものにすりかえて、1-2) 1-5)をあわせておく。

　「匿名性」や「セキュリティ」を犯す攻撃にはなりえないと考えられます。
　理由は以下の通り。

　1)暗号化ファイルが見つからない → 公開鍵の評価が下がる。
　　『1-3)IP/ポート交換ワンタイム公開鍵』を　入れ替えてしまうので、暗号化ファイルにある
　　『2-3)IP/ポート交換ワンタイム秘密鍵』で、復号不可能になる。

　　つまり、検索パケットを送ったノードに応答パケットを返せないので、暗号化ファイルが見つからない

　　よって、公開鍵の評価が下がる。　つまり、相当の信用を得ていない限り、直ぐに「信用できない公開鍵」
　　として学習され、攻撃ノードは、今後その鍵での攻撃は不可能になる。

　2)中間ノードのIP/ポート番号が分かった所で、「匿名性」は犯されない。

　　中間ノードが、一斉広報で検索をかける際、攻撃者に、そのパケットが届き、
　　自分が摩り替えた鍵の秘密鍵で復号して、IP/ポート番号が分かった所で、
　　中間ノードと思われるノードの「IP/ポート番号」が分かったに過ぎない。

　　さらに、1)の理由で、それが長い間続くわけではない。

　　中間ノードが分かった所で、長期間に及ぶ大規模な調査がない限り「匿名性」は犯されません。

549:425
05/07/24 23:49:53 hPPfaUHc
>>536

>データ本体のキャッシュの寿命の方はどうなってんの？

　静的関係のキャッシュに過ぎないので、寿命の概念はまったくありません。
　いつでもいい、好きな時に消していいし、消さなくてもいい。

ハードディスクの資源は有限なので、その辺は、適当に設定する。

>要不要が即わかるほどキーファイルが流通するネットワークなら、
>わざわざデータファイルのメタデータを隠蔽する意味が不明だし。

　キーファイルが、いくら流通した所で、要か不要かは、データファイルのメタデータ

　つまり、キーファイルの暗号化ハッシュコードを復号してみないと分からないと思ういますが?

　>>535のような、もう少し具体的な説明をしてもらえませんか?

>となりがキャッシュをはじめから持ってるのと、いまからキャッシュにし始めるということと、
>どう違うわけ？

　一応、当り前のことだと思って書きませんでしたが、プロキシ要求を受けたノードは
　とりあえず、自分のキャッシュを探し、あれば、それをそのまま返します。

　つまり、違いありません。

550:425
05/07/24 23:55:29 hPPfaUHc
>クラスタ化されていない状態なら、無駄なキャッシュが増えるだけ。

　暗号化ファイルのレベルでは、クラスタ化はありませんが、キーファイルのレベルでは存在します。
　どう、言うことかといいますと、プロキシ要求は、3-1)で起こります。

　さらに、検索パケットは、3-1)のポートが開いている相手にのみ送るので、

　結果として、暗号化ファイルはキーファイルの通信によって、形成されたクラスタの周りを
　うろちょろするだけです。

　カッコよく言えば、暗号化ファイルは、キーファイルのクラスタを継承します。

　この辺はまた詳しく話します。

>いかれたパケットを送出するのに、root権限が必要なのだが、それはどうでもいいの？

　その辺が、UNIX系の鬱陶しいところですよね。適当にエージェントを挟むなり、すれば
　root権限まで取られる事はないのかな。

　P2P専用として使うのなら、落ちたって大した事はない思っていたりする。

>っつーか、ノード数、ファイルサイズ、ファイル数、各ノードのキャッシュ容量とかどの程度のものを考えてるのかね。　

　ネックとなるのは、キーファイルの通信になります。この辺の仕様を、はっきり決めない事には、分かりません。
　現在分かっているのは、各ノードの暗号化ファイルのキャッシュ容量は、まったく自由です。

　Freenetを「公開鍵暗号方式」と例えるならば、HannyNetは、「ハイブリッド暗号方式」を徹底的に目指してみたい。

551:login:Penguin
05/07/25 02:43:41 HNMfL4hb
キーファイルをみても要不要かわからないってことは、
キーファイルにはファイル名もキーワードもはいってないってことか？
それじゃあ、どうやって検索とかクラスタ化するわけ？
どうにしろ、キャッシュされることを考えていないってのは全く持って意味不明。
流通の効率を全く考えてないって言ってるのと同等じゃないか。

552:login:Penguin
05/07/25 15:52:46 DS/oy6EW
HannyNet(仮)とやらは参加ノード全てがハイレベルクラッカーなわけ？
相手のPCを攻撃しながらファイル共有でもしているのかｗ
膨大なクエリでネットワークが埋め尽くされ、キーロスト多発
マルチソースDLどころかレジュームすらまともにできずにゴミキャッシュが
増えるだけの予感

553:login:Penguin
05/07/26 07:56:10 LfvsKzx0
横レスですが
>>551
キーファイルを見ても要不要がわからない、というのは、
実体のファイルを落とすまで本当のファイルとしては何かわからないというのと同義でしょう。
WinnyでもWebでも本質的には同じことで、codecがないから再生できないっていう状況も
あるから、ネットワークのシステム自体が判定することは無理でしょう。
で、この仕様だと自然言語からキーファイルをFreenet的に検索するみたいなんで
（自然言語→キーファイルは暗号化されていない）クラスタ化は可能かと。

キーファイルの流通に関しては結構やばそうな感じはするけど。
WinnyでもキーにTTLみたいなのを持たせて、あんまりクラスタ距離的に遠くまでは
キーが流通しにくくしてダウンロード枠を確保してたみたいだけど。

>>548
どんな感じのキー流通になるかはあまり言及がないのであれだけど。
535攻撃は、キーファイルの配布速度と範囲によって有効だとは思う。
｢信頼できる配布公開鍵(1-5)｣の情報が伝わらない(基本的には自分で試してみるしかない)
わけで、ダウンロード枠待ちor失敗と、攻撃を受けていること、をすぐには見分けられないかも。
中間者がIPアドレスを知ったところで、Winnyと同程度までしか匿名性は落ちないけど
いろいろしてる割にしょぼくなるな…と思ってしまった。
ちょっとしたダウンロード妨害の嫌がらせ攻撃としても有効だと思うし。

554:login:Penguin
05/07/26 19:00:18 8pmsTF99
テスターやりますよ。期待age

555:425
05/07/27 00:54:52 if8zYisn
レスが追いつかないので、横レス大歓迎です。

>>542-543

　レジュームのことを、すっかり忘れていました。この暗号(?)は使えそうですね。
　非常に単純ですけど、強度は十分だと思います。

　最も手っ取り早いのは、検索パケットに「先頭からバイト数」(*)の情報を加えて応答パケットに、
　「ファイル長(バイト)」から(*)の差を載せて送るようにする方法でしょうね。

　検索パケット自体は、IP/ポート番号などを含め、128bitまでの情報を載せることができますから、
　IPアドレス + ポート番号 = 48bitなので、十分余裕はあります。

>>544
　言葉に若干トゲがありますが、大体そう言うことです(笑　

　Aの通信が、Bによって書き換えられ、Cを攻撃したのであれば、
　Cは、Bに直接攻撃されたのと変わりません。

　つまり、Bの攻撃によってCがクラックされた場合、Cのセキュリティが甘かっただけ。
　Bが攻撃者である事も分かります(クラック対策は比較的容易)。

　むしろ、Aの通信に悪意があり、Bを中継し、Cを攻撃した場合の方が問題。

　そのため、Bは、転送するポートに送られたUDPおよびPSHパケットを排除します。

556:425
05/07/27 01:05:00 if8zYisn
>>551
　>>553を参照してください。

　キャッシュされたファイルがあるノードは、検索パケットに対して応答するので、
　無駄にはならない。

　ただし、暗号化ファイルは、ある程度キーファイル上のクラスタをウロウロする事は
　予測できますが、実際問題としてモデルを組まないと正確な事はわからない。

>>552
　単に、どんな攻撃が存在するかを適当に言いまくっているだけ。実際には、
　純粋(?)にクラックが目的のクラッカーは、タダのPCに魅力は感じないので、
　まず来ないでしょう。
　
　検索パケットの最大余命なども決めなければ、帯域を圧迫する恐れあるので
　モデルを組んで考えなければならない。

　プロキシを使ったマルチソースDL(ファイルの分割化が必要)は仕様として考えていませんが、使わないのであれば、
　クライアント側の仕様を適当に変えるだけで、マルチソースDLは可能です。

　プロキシ使わなくても、UP側はいつでも匿名ですし、Down側もある程度の匿名性も維持できると思います。

557:425
05/07/27 01:06:33 if8zYisn
>>553
　>535攻撃は、キーファイルの配布速度と範囲によって有効だとは思う。
　
　確かに言える。しかし、攻撃者がキーファイルを書き換えて攻撃しようとすると、そのキーファイルは
　『人気のあるキーファイル』であると予測される物でないと効果は期待できない。

　しかし、『人気のあるキーファイル』であると予測される物であれば、高い確率でかなりの量が
　流通しているはずです。そのような中で、『書き換えられたキーファイル』が広く流通するとは、
　考えにくい。よって、被害を受けるのは極僅か。しかも、匿名性を犯すものではない。

　逆に、『人気のないキーファイル』であると予測される物であっても、今度は検索クエリが自分の
　場所に届く保障はない。

　さらに、同一ノードに関しては、公開鍵の評価が下がっていくので、その公開鍵を使った攻撃は
　無意味な物になっていきます。

　つまり、攻撃として手間がかかる割に小規模な攻撃しか出来ない。

　>中間者がIPアドレスを知ったところで、Winnyと同程度までしか匿名性は落ちないけど
　>いろいろしてる割にしょぼくなるな…と思ってしまった。

　例えが悪いと思いますが、懲役10,000年の囚人が司法取引で懲役100年になったとします。
　たしかに、99,000年も刑期が短くなったわけですが、実際問題として大して変わりません。

　その程度だと、考えてもらっていいと思います。　

558:login:Penguin
05/07/27 01:24:16 AFPD/rL/
URLﾘﾝｸ(homepage3.nifty.com)
ここは読んでみたか？

559:login:Penguin
05/07/27 08:43:34 sGzAtD+q
>>557
Winnyではクローズドだったから特には問題にならなかったけど、
キーファイルの改竄は、結構システムとしてやばめの攻撃だと考えている。
チェックサムとか署名でのシステム的な保護をするのはもちろんだけど、
キーファイルというものはリンクであるわけだから、有効なキーファイルかどうかは
実際落として見ないとわからないわけだ。
(スレ立てするときにテンプレの関連スレが有効かどうかを調べるみたいに)

末端ノードでは、自分のチェックした結果と、（もしするなら）伝播してくる信頼度の噂
によって、キーの有効度をテストしなくてはならない。
攻撃側は、いくらでも評価0の公開鍵を作ることができる。
正規配布ノードの公開鍵の評価を上げるシステムか、攻撃者公開鍵の評価を下げる
システムが必要となるけども、この評価伝播システムは、それ自体が攻撃対象となってしまう。
入れないというのもひとつの手だとは思うけど(自分以外みんな敵)、
PGPみたいに信頼のネットワークを導入するのもありかなとは思う。

キーの伝播にどんなシステムが適当かわからないし、システムによるとは思うけど、
攻撃の手間のわりに、結構被害がでかいと私は思っている。
Winnyのキー伝播を仮定すると、"ファイルの公開者トリップを書き換えて遊ぶ"というのが
一時流行ったけど、あれはかなりな効果範囲だった。
IPアドレス収集までいかなくとも、ゴミキーが混ざるだけでも結構検索に支障が出ると思うし。

560:login:Penguin
05/07/27 09:00:00 sGzAtD+q
>>558
見てみました。まとまってますね。
425プロトコルは、基本的には多段プロクシに分類されるのかな。

これみて思い出したけど、Winnyで課金可能性についてでてましたけど、
このシステムでは実装可能ですかね。
当時、ぼろくそに言われてましたが、可能かどうかだけでも検討しておいた方が
なにかと良いかと思います。
結局のところ、"監視することができない"というシステムにするなら以前から言われる
｢投げ銭システム｣しかないと思います。
オープンソースシステムでは、不正ノード防止のための工夫が必要になると思いますが
この防止には、結局他ノードの目というのが必要となってくると思います。
例えば、転送量監視だとか、データの損傷(署名が一致するか)だとか、ゴミキーを送ってこないかとか。
そういったシステムを流用して、間接的な監視というものが実現できれば、
PureP2Pでも、課金ができるかもとか考えたりしたんですが、いいシステムは思いついてません…
今のがっちがちなインターネットの課金システムほどは確実には取れないと思いますが、
ちゃんと投げ銭できれば、現状よか使い勝手よく少しは取れるになるのではと思ったり。

561:425
05/07/27 20:18:17 pqX40aYh
人大杉で読めないよ。

しょうがないので携帯からアクセス。

>>558
　P2Pの基本と言っても、結局TCP/IPの基本に他ならないと思います。

>>559
　実装されるようになると、エンドユーザからは、キーファイルや暗号化ファイルを、
　あまり意識する必要がないような、インターフェ―スになると考えられます。

　つまり、あるキーワード入れると、全自動であるキーワードに引っかかるキーファイルが
　全部落とされてきて、暗号化ファイルのダウンロードも同時進行で行う。

　Winnyの基本である『待ち』ですね。待ってれば、落とされます。

　その中で、公開鍵の集計を取っていけば、信用性にかける公開鍵はふるいに掛けられます。

　落としてきたキーファイルの中にゴミキー30%混じっていた所で、検索にちょっと時間がかかるだけで
　信用性にかける公開鍵は、次々とふるいに掛けられるので検索速度は向上していきます。

562:425
05/07/27 20:27:50 hYL+POH6
続き・・・

　逆に、攻撃者が全自動でゴミキーを作っていたとしましょう。

　信用性にかける公開鍵は、次々とふるいに掛けられるので、攻撃するには新たに公開鍵を
　作ってやる必要があります。

　さて、ここで問題です。

　攻撃者が、RSA2048bitの鍵ペアを作る時間と、探索者が『信用性にかける公開鍵』を
　見つける時間は、どちらの方が短いでしょうか?

　また、どちらの方のマシンが先に悲鳴を上げるでしょうか?(w

　どんな攻撃を仕掛けてきても、「RSA2048bit」という馬鹿みたいに長い鍵のせいで、
　長期戦は出来ず、超短期決戦になります。短期決戦では、『匿名性』は崩れる事は
　ありません。

563:425
05/07/27 20:30:06 hYL+POH6
>>560
　>425プロトコルは、基本的には多段プロクシに分類されるのかな。

　基本が、WinnyとFreeNetですからそうなりますね。

　暗号化ファイルの検索が帯域を圧迫する恐れがあるので、
　そのあたりもう少し考えなけれななりません。

564:login:Penguin
05/07/27 23:26:59 IJEnt68s
短期決戦？まさか。
暗号化ファイルが得られるまでキーの妥当性なんか判別できないんだろ。
しかも、人間が判別するわけだろ。
何が先に悲鳴をあげるでしょうか(www

565:login:Penguin
05/07/28 02:29:02 fAaYvFoP
>暗号化ファイルが得られるまでキーの妥当性なんか判別できないんだろ。

　少なくとも､明らかに「暗号化ファイル」が存在しないものは
　システムで見つける事は可能だと思うが?

　>>535に対する回答としては十分でないか？

566:login:Penguin
05/07/28 08:07:59 eeVn6bw9
>>565
明らかに存在しないのか、単にレアものなのかの区別はどうする？
(キーの配布拡散方針にもよるが)暗号化本体ファイル(2)を持ってるノードがダウンして
キーだけ出回っている状況とどう見分けるのかってこと。

>>562
1000～のオーダーで順次回されたら、攻撃者鍵と初回ダウンロードな鍵とを
見分けられないのでは。(各ノードはそんなにたくさん鍵を覚えておくのか)

ちなみに以前某所で使った、俺様実装なRSAプログラムでは2048bit鍵生成に1500msでした。
真面目に(攻撃されないように配慮して)鍵を作るのには時間がかかるけど、
それなりにチューンされた多倍長ルーチンを持っていれば
1024bit程度の素数かどうかチェックは秒行くか行かないかな速さでできます。

(´-`).｡oO(自分でしこしこ組んだのより、gmpというルーチンは10倍以上速かった…)

567:login:Penguin
05/07/28 14:40:26 d4j3xM1r
前から出てるけど、暗号化ファイルと無関係なキーワード並べたキーファイルをばらまく攻撃ができるよ。

公開鍵生成しながら、適当に検索かけて、流れてくるキーファイル受信しとく。
検索が来たら、受信したキーファイルの 1-1) を一致するキーワードに書き換えて、ついでにランダムなキーワードも追加。
1-4) を生成しといた鍵に差し換えて、 1-5) の署名をして、検索した人に返信すればいい。
検索した人は、無関係な経路から無関係な暗号化ファイルを受信することになる。

もちろん、復号して確認するまで、無関係な暗号化ファイルかどうかはわからない。

568:login:Penguin
05/07/28 18:25:16 oqKZ/QOz
>>566

最低でも15秒はかかると思っていましたが、速いモノですね。

確かに、鍵を作るだけであれば、200個の素数から1090組の
鍵ペアが出来ちゃうんですよね(^^;

いよいよ、公開鍵を元に不正なキーファイルをノード単体で、
探すのは困難になってきたわけですか。

その辺は、前々からちょっと思っていたのですが、「信用できる公開鍵の情報」を
共有してしまえば、「信用性のない公開鍵」を排除できると思います。

自分が分かってる「信用できる公開鍵」の書いたテキストを、キーファイルと
暗号化ファイルにエンコードして公開するだけ。

しかし、そんな親切な人いないので、システム側で支援すべき。

まぁ、データ圧縮や不可逆性の点から考えても「信用できる公開鍵」の情報は、検索時に利用される
(ますよね？)公開鍵のハッシュコードをだけを書いた方がいいのかもしれない。

無事、ファイルが公開できたとしても、今度は、「信用できる公開鍵の情報」のキーファイルの
「公開鍵」が「信用できる公開鍵」なのかという問題が、起こってきたり、来なかったり。

まさに、「もし、この島の人間は皆、ウソツキなので気をつけなされ」状態。

でも、不正なノードもある程度ネットワークが大きくなければ出て来ないでしょうから、
その間に、いかに信頼関係を気付いていくかが問題なんでしょうね。

どちらかと言うと、ソーシャルネットワーク見ないなもんなのかな。

569:login:Penguin
05/07/29 05:00:12 LUTJPErB
議論がキーの信用問題になってるけど、他にも弱点を指摘よろです。

>>568
キーファイルの有効性については、1-4)1-5)にある公開鍵による署名をよりどころにする
という認識でok?
ゴミファイルor捏造であるかどうかを含めて、公開鍵の評価に反映させる、と。
極論すれば、｢信頼のない公開鍵で認証されたキーファイルは破棄する｣とかいうシステムですな。

となると、攻撃対象は"公開鍵の信用性の伝播"に移ると思うんですが、耐性はあるかな。
外部からファイルを投入してくれる「職人さん」というのがあるけど、ファイルの有効性を確かめて
信頼情報を流してくれる"情報職人"というのができればいいけど。
信頼情報の署名を含めて、PGPでの信頼の輪みたいに共有していくシステムがいるね。

ネットワークに参加する際、一番初めの「信頼できる公開鍵」を何にするかという問題もあるな。
公開鍵の信頼の輪が、意見の相違によっていくつかに分かれたりもするかも。
信頼の輪にクラスタ化がいるのかもね。

570:login:Penguin
05/07/29 05:04:53 LUTJPErB
情報屋は大変かも。一度でも間違えた評価をするとみんなから評価してもらえなくなったりとか。

評価の伝播は、＋～0だけでマイナスは伝播しないようにしたほうがいいのかな。
それとも、マイナスだけ流した方がいいのかな。
どっちが攻撃に対して強いのかな。

571:425
05/08/03 12:00:36 dOb0lEGI
振替休日万歳！

ちと、今の仕様だと完全にDMZに置かないと話にならないので、
もう少し安易な物を考えている。

winny上でwinnyする仕様(winny over winny?)

　現在同様、自分のキャッシュに入ってる内容は、まったく
分からないし、中継されるファイルの内容も選べないが、
上手くいくとWinnyより早くダウンロードが始まる。
(言うだけはタダ)

公開鍵やキーファイルについての議論がありますが、
これは、既にWinnyでも実装済みの機能だったりします。

キーファイルは、winnyで言う所のキー(ファイル情報)
公開鍵は、winnyで言う所のトリップですね。

ただし、winnyのキーは、暗号化ファイルのインデックスで
あるだけなので、暗号化ファイルからインデックスを逆に
検索を掛けれるので、winnyの暗号化ファイルは可逆で
あります。

そこで、暗号化を不可逆にして、暗号化ファイルからインデックスの
逆参照を不可能にしようと思ったのが、そもそもの始まりです。

572:425
05/08/03 12:15:10 4RkUfwZp
それと､匿名性以前の問題でWinnyでは、コネクションの確立
方法は、β1.0から全て共通です。

つまり、どんなP2Pソフトでもコネクション接続要求の
パケットを止められてしまうと何処とも接続できない。

コントロールポートをUDPに限定すれば、UDP53番ポートを使うとか、RTPヘッダをつけるとか、いくつか打開策はあり。

573:login:Penguin
05/08/03 18:13:41 vcqACEF4
>>572
パケットを蹴られないようにするだけなら、HTTPリクエストに偽装するとか方法はあると思う。
(流石にWeb閲覧を全面的に蹴るプロバイダはいないだろうし)
パケットが通るかどうかまで心配するとなると、それこそインターネットの再発明になるから
実装する気にもなんないんだけど。

Winnyのネゴは結構正直にやりすぎな気はするんである程度の偽装は必要かもしれないけど
細かいところに凝りすぎて、全体を見失ないつつある気がする。

「通信している内容は単独復号できない」
「通信をしているのはノードの意思ではない場合がある」
これだけで、多段プロクシとしての匿名性は得られてるんじゃないかな。

574:login:Penguin
05/08/03 20:33:33 huf+rSCg
通信がノードの意思でなくとも警察が要求すれば
ログの提出しなきゃならないってことはないの？

575:425
05/08/03 21:13:48 bxsn0g1D
パケットの量は、80番(HTTP)より53番(DNS)の方が多かったりする。
あと、サーバ動かしていたら、そのポートつかえません。

well-knownポート使った偽装は、明らかな偽装なので、面白みに
欠けるのでRTPヘッダを使った方が面白いかもしれません。

リアルタイム通信のパケットを時間をかけて調べる事は出来ません
からね(w

576:login:Penguin
05/08/03 22:47:17 2/5EZX4h
ログ以前に、中継してるだけで限りなく黒に近い。特にwinnyみたいに99%違法流通してるようなところでは。

577:login:Penguin
05/08/03 23:24:14 huf+rSCg
どうせユーザ数が多くないと話にならないだろうし、だったら
2ch的なものと混ぜてしまえばいい。

2chブラウザより使い勝手を良くして、2chやその他bbsのログを
一本化して共有、●なくても読み書き可能にすれば2chは用済み、
2chのユーザ+nyのユーザを乗っ取れば膨大な掲示板トラフィックと
区別が付かなくなる。

578:425
05/08/04 01:10:23 WsgB/OyK
>>576
>中継してるだけで限りなく黒に近い。

と言うか、黒なファイルが中継されるであろうクラスタに
属している事自体に法的問題があると思われる。

つまり、winnyの暗号化ファイルが可逆である事がそもそもの発端。

中継動作しているものに暗号化ファイルが何であるか不明にすれば
いいだけ。

>577
　>どうせユーザ数が多くないと話にならないだろうし
　ユーザが少なければ、逆に表沙汰にならないので
　　逆に問題ない。

　1024以下はroot権限ないと起動できないから、その辺が鬱陶しい。
　Xenと併用するのであれば、問題ないが面倒。
　
RTPヘッダを使うと、リアルタイム通信として扱われるので、
　下手に、通信のタイミングをずらすような処理が出来ないのが
　ポイント(w

　あとは、適当にRTPヘッダを使う大義名分を考えればいいか・・・

579:login:Penguin
05/08/04 01:38:50 iT6MgWDt
ばかじゃねーの。もし、winnyのキャッシュがキーなしで復号できなくても、黒は黒だろ。
winnyのネットワーク自体が真っ黒なんだから。
何が問題ないんだか。

580:login:Penguin
05/08/04 01:48:24 CWTMyEJZ
>>579
うｐろだの管理人も真っ黒になってしまいますね

581:login:Penguin
05/08/04 08:47:47 mCeiRwwd
当然でしょう

582:login:Penguin
05/08/04 09:02:27 lKwo9ozd
復号できないのに黒だとわかる>>579ってすごいですね。
でも証明できないんじゃ意味がないですよね。

583:login:Penguin
05/08/07 23:49:45 MAErsDxd
けんか腰の奴と一緒になってけんか腰で議論する必要はないない

584:login:Penguin
05/08/08 03:26:21 GElm0bvw
まだですか。
bitなんたらで洋物エロ動画落としてるんだけど、全然速度でねぇしjavaのazura何とか
すげぇメモリ食うからやだし。
そもそもそういう用途に使うもんじゃないから匿名性なんてまったくないし。繋がってる相手丸見えだもんよ。

585:login:Penguin
05/08/12 16:49:10 ++zxKhYc
ｗｉｎｎｙて
1　匿名性
2　分配方式
の2点が特徴に思いますが
2のみだけでもオープンソースでできれば
後は勝手に1を満たすよう誰かが進化させてしまうんじゃないでしょうか

誰か匿名性の無い分配式共有ソフトをつくってくれませんかね　（厨房より）

586:＿
05/08/15 00:39:47 kuEK/e6W
つうか、Winnyのソースって出回ってるだろ?
ある種のオープンソースでねーか?

587:login:Penguin
05/08/15 06:24:45 WYCWTctv
>>586
UpとDownの著しい不均衡とか、キーがちっとも広がらないとかいう問題は、
クローズドだからこその解決法でなんとかしてたわけで。
もし、全盛期に改造ビルトが流行ってたらネットワークは維持できてなかったと思う。
v4キーの書き換え(キーハッシュの衝突の脆弱性)でも一時やばかったわけだし。

そういうとこを含めて、公開しても大丈夫なシステムが組めればいいなと

>>585
BitTorrentじゃないの、それって。

588:login:Penguin
05/08/28 21:06:16 jFvBDF3F
よくよく考えてみると、47氏はwinnyを開発した事による
著作権幇助の疑いで捕まったわけですよね？

オープンソースで、バイナリではなく、ソフトをソース配布すれば、
技術のない房は弾けるし、「表現の自由」によって「憲法」で
保護されると思うのだがどうよ。

ソースはCのような高級言語でなくても、アセンブリでも問題ないと思われ。
47氏も、アセンブリでソース配布すれば、めんどくさい裁判を受けなくて住んだかも?

589:login:Penguin
05/08/29 12:10:02 8UYsqZTy
>>588
ひょっとしてそれはギャグで（ｒｙ

590:login:Penguin
05/08/29 15:48:03 Lic1bBnN
*+*++*+/.,/.,/.,/.,//,/:;*+*+*+*+
＿｜￣｜○
*+*+*+*+・。、・。、・。、＊＋＊＋？＜？＋
：；：?。*；+*>*＞？＜＞？？＜＞＊＋・。、・。、＊＋

591:login:Penguin
05/08/30 15:57:40 4Ij1IBiF
decss?

592:login:Penguin
05/09/04 01:44:20 hmo/M5vH
所詮パクリ

593:login:Penguin
05/09/04 14:39:29 pXpKd7Rm
それ以前の問題だと思うが

594:login:Penguin
05/09/20 13:51:25 PscRxDnC
いざ作ってみるとなかなか難しいものだな。

595:login:Penguin
05/09/22 05:05:33 jWL/+1Tx
製作者ｷﾀ━━━(ﾟ∀ﾟ)━━━ !!

(´-`).｡oO(というか真面目にむずいよな）

596:login:Penguin
05/09/22 19:33:00 hK6hjCOG
> オープンソースで、バイナリではなく、ソフトをソース配布すれば、
> 技術のない房は弾けるし、

勝手にコンパイルして配布する人や、まとめサイトを作ってくれる人に
関してはどう対処する？

> 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。

憲法をどう解釈するかに関しては、裁判所でどうぞ。

597:login:Penguin
05/09/24 15:57:21 on+fKY/Q
○学生の出てくるエロ漫画を描いても、表現の自由で保護され･･･たっけ？

598:login:Penguin
05/09/24 16:05:18 uOc/XLUk
>>597
宗教ならおｋじゃなかったか？

599:login:Penguin
05/09/25 01:33:10 /r0bHCUi
47氏の本が出版されるらしいね。Linny開発に弾みがつくといいな。

600:login:Penguin
05/09/28 17:26:52 Ej2805fD
その本をスキャンしたやつをlinnyに流そうぜ

601:login:Penguin
05/09/29 22:05:37 BIai3mBJ
> 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。

要は、「爆弾の作り方」は書いても言いが、「爆弾を作ってはいけない」
ってことだな。バイナリで流してる奴がいたら、そいつが捕まって、
はい、オシマイってわけ？人生そんな上手くはいかないよ。

602:login:Penguin
05/09/30 02:55:59 G/RjxJmT
作り方と作ることを、バイナリとソースの対比で言い出したら、
バイナリでもOS上で実行しない限り走らな(ry とかになってくるし。
アイデアは良くて、アルゴリズムはダメでとか、
アルゴリズムはいいけど、走るソースはダメだとか。

結局、何を配布したとしても、最終的に自分の意志での実行コマンドの発行が必要である以上
ウイルスとかの自動実行系の配布とは一線を画するとは思うんだが。

603:login:Penguin
05/09/30 13:26:30 U0TBEIz/
京都府警はおろか司法の中の人たちも、この手の新しいテクノロズィに関する
お話になると、どうも理解があやしい。
挙句、既成概念の外からやって来た”異物”に対して、理論的根拠なきまま
攻撃的に排除する方向で対応している。

社会システムの理性であるべき司法も所詮、硬直化した官僚組織だ。
構造改革は行財政だけでなく、司法にも直接メスを入れる必要があるな。

604:login:Penguin
05/09/30 13:29:14 os075Rrp
>>603
藻前が何を熱く語ったところで、世の中変わらないから安心して妄想汁。

605:login:Penguin
05/09/30 13:44:53 U0TBEIz/
これはこれは。

素早い反応、乙であります。

606:login:Penguin
05/10/02 02:27:49 akB9j0NI
603が一番理解があやしそうだが。

607:login:Penguin
05/10/02 03:31:25 XdmTWX16
>>603
既成の概念を破ることを悪いとは言わないが、
破ることによって新たに得られる物がまだ準備できない段階で、
むやみに破壊するってのもやばいでしょう。
異物が成功することのほうが少ないんだし、排除しようとする動きは当然かも。

608:login:Penguin
05/10/03 22:23:47 lHDFlLbA
> 「表現の自由」によって「憲法」で保護されると思うのだがどうよ。

まぁ、未だに64kの低速回線でファイル共有自体には興味はないが、
これはあながち間違ってはいない。

と言うのは、Winnyによる著作権侵害の問題が社会問題にまで発展したの
には、マスメディアの力によるものが大きい。それでも、マスメディアが
「表現の自由」に守られているからです。

かつて、「OPEN-SSL」の輸入が米国の法律上の関係で、認められない時期がありました。
しかし、何処かの頭のいい馬鹿が、ソースをプリントアウトして日本に持ち込みました。

その時代、電子データは「人が読めるもの」であっても「文書」には当たらなかったのですが、
プリントアウトして、尚且つソースは「人に読める」ので「文書」になります。

「文書」になった地点で「表現の自由」が認められ、晴れて輸入できたわけですね。

現在では、「電子データ」であっても、人が読めるものであれば「文書」になるので、
「表現の自由」が認められるワケですね。

あ、でも昔、コレと似たような問題として「偽造テレカ」の問題がありました。

当時の法律では、コレを「偽造」とするのには難しい物があり裁判所が、
ムリヤリこじつけて有罪にしてました。

興味がある方は調べてみてください。

609:login:Penguin
05/10/03 22:34:53 lHDFlLbA
一応、関連分野だけど、どうでもいいネタを思い出した。

SQLインジェクション攻撃は、多くの場合、日本の法律では「不正アクセス」には
なりません。

だって、名前を書く欄に人間が読める文字(SQL)を打ち込んだら、
「頼んでもいないのに」　「勝ってに」　「向こうから」
情報を送ってきますからね。

610:login:Penguin
05/10/04 00:04:49 3MN3X/VT
>> 609
勝手に送られてきた情報でも、悪用すれば損害賠償に発展するし
利益が伴えば横領だろうから、よい個はやらないように

611:login:Penguin
05/10/06 20:54:13 d52gi3Mh
882 ：47 ◆KbtLZwerNc ：sage ：03/06/19 08:50 ID:AhStOI42
Winny作者ですが

あれがクローズドシステムになっているのは、好きでそうしているわけではなく、
こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。

その際には現在のWinnyとの互換性はなくなると思いますが。

今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、
オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。

とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。
だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で
オープンにできないのであればUNIX版ができることは無いと思います。

612:login:Penguin
05/10/06 21:04:34 Fgb6CUKR
47氏に「こちらの設計能力不足によるもの」なんて言われても・・・

613:login:Penguin
05/10/10 14:04:07 rLVx9fSs
47氏の本を読んだ人、なんか言うことあったらどーぞ

614:login:Penguin
05/10/10 18:21:40 7ub5fEMT
ﾉｼ
・pthread使えよ
・コネクション開けすぎだろ
・DOM対策は黙殺かよ

615:login:Penguin
05/10/10 23:20:57 qNvmUTIs
>>614
つーかDOM対策の仕方が分かんないからオープンソースにできないんでしょ？

616:login:Penguin
05/10/11 01:45:25 kh40LmyH
つうか、回線資源が豊富な時代のファイル交換ではない「ファイル共有」に、
『DOM対策』と言うのは、多発する自動販売機荒らしのためにガードマンを
雇うようなものだろう・・・放置で問題ないのでは？

あと、帯域制御ではなく、パケット優先制御にするって手もありそうだが実装が面倒だろうな。

617:login:Penguin
05/10/11 10:11:42 PfV9tu8k
>>614
Windows用のソフトでpthread使えと言う方がどうかと思うが

618:login:Penguin
05/10/13 20:30:00 aQX6KbtT
Linnyへの言及は無かったの？

619:login:Penguin
05/10/16 14:22:14 Pzhwvu3/
俺が47氏と対談してやろうか？
確か東大教授だったか。
いやマジで。

620:600
05/10/18 18:32:18 OVuRaYPv

金子勇氏が『winnyの技術』PDF版の配布を開始
ｽﾚﾘﾝｸ(news板)

621:login:Penguin
05/10/19 18:54:23 wirADuqX
47氏の逮捕が残念でならない。
あと、数年逮捕がなければ
ｌｉｎｎｙは実現してたんじゃないかと
それは、ｌｉｎｕｘの普及に弾みを付けたであったろうに
金子さん残念です。できそうにないっす（ノ＿・、）

622:login:Penguin
05/11/01 18:58:39 AD9WRUWi
URLﾘﾝｸ(www.2chlinux.org)
wine de winny
これを使えばｌｉｎｎｙは不要なんだね

623:login:Penguin
05/11/06 17:17:06 Tn4QjnGn
前スレくらいに、47氏が来てたきがする。

624:login:Penguin
05/11/06 21:04:51 XTX2yjfR
>>623
Linny開発プロジェクト
ｽﾚﾘﾝｸ(linux板:882番)

882 ：47 ◆KbtLZwerNc [sage] ：03/06/19 08:50 ID:AhStOI42
Winny作者ですが

あれがクローズドシステムになっているのは、好きでそうしているわけではなく、
こちらの設計能力不足によるものですので、もしオープンソースでも問題ないメカニズムが
導入できるのなら、こちらでそれを取り入れてWinnyのソースを公開するのもありかと思ってます。

その際には現在のWinnyとの互換性はなくなると思いますが。

今やってるWinny2のその次を考えるとどうしても一人でやっているのは限界があるわけで、
オープンシステム化かもしくは別の方法による大規模化は避けて通れないでしょう。

とりあえず設計さえ煮詰まれば実装はこちらでやっても良いので、考えるのだけはよろしくお願いします。
だめならソース非公開なままでUNIX版を作るという手もありですが、こちらの時間的余裕の問題で
オープンにできないのであればUNIX版ができることは無いと思います。

625:login:Penguin
05/12/16 20:57:31 Kqp2Iu7t
Project page not found

626:login:Penguin
05/12/16 21:15:51 xaaeI0JY
掛け声ばかりで何もしないのが犬糞ｸｵﾘﾃｨ

627:login:Penguin
05/12/17 07:19:10 TnkcQday
Azureusでいいんじゃないかな？トラッカー不要だし、匿名でもできるんでしょ。

628:login:Penguin
06/03/12 18:35:31 pV0uMcQl
poenyとか作っちゃった人いるし。

629:安倍
06/03/15 22:18:54 6/zNNY2A
ここも閉鎖してくださいね

630:login:Penguin
06/03/15 23:04:18 ZjUHtBRx
>>629
なにげにIDにNYはいってるな。

631:login:Penguin
06/04/08 23:52:50 1z63VHJc
お宝動画.mpg .sh*

次ページ