5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Linny開発プロジェクト Part2

1 :login:Penguin:03/06/22 19:40 ID:zhqumg4k
今までの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のアカウントを取得してください。

419 :login:Penguin:2005/07/03(日) 15:06:07 ID:IZCijWVL
プログラマーとしてはダメダメだが、思いついたことを書いてみる。

ttp://www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html
とかをまとめて見ると

要は、トラフィック解析した時に分かる「Winnyパケット」の「振る舞い」が、
問題になる。その「振る舞い」によって、らしきパケットは限定されてしまう

1.無効なSYNパケットが多い
2.特定サイズの暗号化通信が連続する

そして、限定されたパケットの中から詳細に分析しているのである。

1.の原因は恐らく、通信しようとした時にPCの電源が切られていることが多いから。


2.の原因は恐らく「TCPの仕様」が原因である。と言うのも、大きなデータを
転送する際は、ネットワークを効率的に利用するためにMSSの最大レートで、
送られるパケットが大量に出るため、『不明なポート』から『不明なポート』へ
「不明なデータ」が大量に、「あるホスト」から「あるホストに」流れている事は
すぐに分かる。現在の仕様では、どんなに頑張ってもトラフィックを観察されると
ある程度,ファイルの流れはバレてしまう。(freenetでも同様)


420 :login:Penguin:2005/07/03(日) 15:07:28 ID:IZCijWVL
1.の解決方法

TCP接続前にUDPを使って、応答を待つ方法

TCP接続前にPingを使って、応答を待つ方法も考えられるが、
受信者が、Pingを切っている可能性もある。

しかし、特定のUDPパケットにICMP到達不能メッセージが多いと
結局イタチごっこになる。

そのため、ポート番号をUDP接続が成功するたびに、次回の接続を
変えてやる必要がある。



2.の解決方法

UDPで新たな、ネットワーク層を偽装するトランスポート層を作成する。
つまり、「送信元IP」を偽装するのです。

できるようになれば、freenetより外部からの匿名性は高くなるが、
資源を思いっきり喰らう、ICMPメッセージは届かなくなる、
NAPTユーザは使えないなどの欠点がある。

考えられるアルゴリズムを、書いてみる。


421 :login:Penguin:2005/07/03(日) 15:08:56 ID:IZCijWVL
(1)各ホストには、IPと対応する「nodeID」を付ける。

(2)つける方法は何でもいいが、当然「nodeID」はユニークでないといけない。IPと無関係な十分に長い文字列(小学校のときの「将来の夢」作文に限定する)をハッシュにかけて、「nodeID」を生成するのが望ましい。

(3)TCP接続された制御用ポートで、ノードにnodeIDとIPを渡しあい、「ダミー送信元IP」を要求しあう(勿論、この通信はSSLで暗号化する)

(4)要求されたノードは、接続されているホストのIPの中からランダムに選び、「ダミー送信元IP」を、要求したノードに渡す。

(5)「ダミー送信元IP」の寿命をどのように決めるかが問題。寿命が来れば、再び「ダミー送信元IP」を要求

(6)ノードでは、次のようなテーブルが作られる(イメージ)
このテーブルによって、誰の通信が何処から来たかを見分ける

-----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
(7)パケットのフォーマットは、TCP over UDP+α的なもの
--------------------------------------------------------------------
|Ver〜HeaderChecksum|///送信元IP(ダミー)////|///宛先IP(本物)///////|
--------------------------------------------------------------------
|送信元ポート////|宛先ポート//////|/////Length/////|///Checksum////|
--------------------------------------------------------------------
|/////////nodeID////////////////////////16オクテット///////////////|↓SSL暗号化範囲
--------------------------------------------------------------------
|///////////TCP////////////////////////40オクテット////////////////|ココのTCP通信のポートは固定にしておいても問題ない。4747版で固定なんてどうでしょうか?。
--------------------------------------------------------------------
|/////////DATA/////////////////////////////////////////////////////|↑SSL暗号化範囲
-----------------------------------
たとえ、SSLの暗号が破られても、外部の者はパケット単体から「nodeID」から本当の「送信元IP」を
割り出す事は出来ない。

(8)問題点は、所属するISPが自己ルーティングを規制している場合や、NAPTをしている場合。



423 :login:Penguin:2005/07/03(日) 15:46:30 ID:IZCijWVL
上記の理由より、外部からの匿名性は高くなるが、
内部の「悪意あるノード」に対しては、対処出来ない。
むしろ、内部からの攻撃には非常に脆いと考えられる。

「認証」を、どのようにするか?コレが問題

236 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)