■次期P2Pの仕様 part6■

Winnyに参加しただけで摘発も？　〜ACCS
http://www.zdnet.co.jp/broadband/0312/04/lp13.html

ちなみに、Linux板で開発中のLinnyの仕様で決めること（？）です。
参考にしてください。
ファイルの検索
キーの流通
持ってる側からファイルの情報をばらまく広告タイプ
検索する側が検索要求を投げる検索タイプ
そのハイブリッド(Winnyね)。
検索条件
ハッシュ値
BBS等でハッシュ値をやりとり？
ファイル名
その他メタ情報(カテゴリ名とか)
評価値(点数)
Winnyでは無視条件に入れられた情報が広まっていく真偽値。
ダウンロード
どう中継させるか
マルチソース(多重ダウン)
ノードの区別はどうするか
キャッシュの保持
管理責任を無効化するにはどうすればいいか
アプリ本体が鍵を持つ慣用暗号で暗号化
暗号化してキャッシュを持つノードには鍵を保存しない
通信路
TCP？UDP？
UDP だと完全性確認や再送を自前でやらないといけない。
UDP なら IP Multicast も使える(w
暗号化
単なるストリーム暗号をそのまま使う(WinnyはRC4)
自前で鍵交換しないといけない
SSL(TLS)に準拠？
HTTPS等と区別が付かない
SSLの中の暗号化は例えばRC4-128。選択可能。

>　「（前述のとおり）Winnyは、参加するだけでリスキーだと説明しているが、
>よく知らずに違法ファイルを中継してしまったユーザーまで、摘発の対象に
>しようとは思っていない」。

つーことだね、よく知らずに導入させる方法を考えるほうが速いな。
ソフトの開発よりは運用重視で、その上で必要になるツールを開発していく。

強制転送モードとIM機能をつけることにした

>>805
キーの拡散にどれくらい時間がかかるかは分かりませんが、残念ながら間違いなく
winnyよりは長くなると思います。しかし、さんざん既出なように匿名性と効率が
トレードオフの関係にあるのは仕方ないことだと思います。
191さんは>>771で、「nyの仕組みはかなりの強度がある」と結論されていますが、
その点に疑問を覚える人は、私だけではないと思います。なぜそのような結論に
達したのか、よかったら教えてください。その理由次第では、私の考えているような
複雑なシステムは不要になりますので。


>>808
この転送システムでは、送受信のたびに公開鍵や共通鍵を変更する仕様なので、
プログラム側でランダムに鍵を作成することになると思います。その鍵作成部分の
ソースが公開されていても、匿名性に問題がないかどうかが分からないです。
素人がいらぬ心配してるだけでしょうか?

＞中継IPのデータは流す必要がないんじゃない？
確かにそうですね。暗号が解読される心配もなくなりますし。後でWiki修正します。thx。
他にもこういう点をどんどん指摘して頂けると助かります。

鍵の生成部分のソースはほとんどの公開鍵暗号方式で公開されています。
共通鍵も同じです。よって何ら問題はありません。

>>824
今日はちょっと暇がないので、明日作っておきます

>>832
Winnyの暗号は解読されてないでしょ。RC4が解読されたら、それこそ世界中がパニックにｗ
P2Pに参加しているだけで危険みたいですね。合法的な機能をつけなければｗ
帯域をある程度使う合法サービスは・・・ビデオ・音声チャット？

http://x.plala.jp/up/src/up0160.avi
テストでやってみた。

なにはともあれP2Pソフトを作る人・研究目的の人はダウソ板で開発すれば、最大の難点、テスターを大量に
得ることができるからがんがってくれ。

匿名発表かつ家宅捜索の危険性付きだけどな・・・

まずwinnyを解体、または同じ物を作る事が出来なければ超える事は出来ないと思うんだが。

ん、"実験"コードで"ソース公開"すれば問題無いでしょ。
(実験&検証コードで、実用に足らないなら。)


そのコードを元に、実際に組めばいい。

ちょっと時間が出来たので作ってみました。

ttp://fosae2003.tripod.com/
完全キャッシュしか変換できなくする暗号化と、
仮想ハードディスクです。

>>843
グッジョブ

>>843
グッジョッブ

>>843
グッジッョッブ

>>843
GB!!

>>843
なんなの？君のそのグッジョブふりは…
　　　　　　　　 ,-､　　　　　　　　　　　　,.-､
　　　　　　　 ./:::::＼　　　　　　　　　 ／::::::ヽ
　　　　　　　/::::::::::::;ゝ--──-- ､._/::::::::::::::|
　　　　　　 /,.-‐''"´ 　　　　　　　　 ＼:::::::::::|
　　　　　／　 　　　　　　　　　　　　　　ヽ､::::|
　　　　/　　　　　　　　　　　　　　　　　　　ヽ|
　　 　 l　　　　　　　　　　 　 　 　 　 　 　 　 l
　　　 .|　　　 ●　　　　　　　　　　　　　　　　|
　 　 　l　　, , ,　　　　　　　　　　　●　　　　 l
　　　　` ､　　　　　　(_人__丿　　　　､､､ 　 / 　　＜ Good Job!!
　　　　　　`ｰ ､__　　　　　　　 　　 　　　 ／
　　　　　　　　　/`'''ｰ‐‐──‐‐‐┬'''""´
　　　　　　　　./　　　　　　　　___　l　__
　　　　　　 　 l　　 ./　　　　／　 |／　|
　　　　　　 　 `ｰ-<　　　　/　　./　　./
　　　　　　　　　　　`ｰ‐--{___／ゝ､,ノ

>>843
グッジョ

>>843
(ﾟДﾟ；≡；ﾟдﾟ)グッジョブ

ニュー速で祭り
SONY GRAND WEGA KDF-50HD900 49800 円
「ベガエンジン」を搭載し、定評ある基本高画質性能を飛躍的に向上させた
BS・110度CSデジタルチューナー内蔵50V型〈グランドベガ〉HD900シリーズ

>>843

　　 ∩∩
　　（･ｅ･） <　GJ !!
　　 ﾟしJﾟ

　　　　光が射した

８４３はどうやって使うの？ってその前に実行して大丈夫？

>>843
ソースきぼん

>>854
実行するとウィルスかもしれませんｗ

使い方が分からなかったらここに書いてくださいね

>>855
ソースはバグとかフィックスしてから、明日アップします。

ﾀﾞｳｿの地に射した光を遮らない様、素人の漏れは遠くから見守ることにします…。

漏れも、見学者チックに遠くから見守ります。しばらくは。

変形RAID5をもう一段階進化？させて秘密情報閾値分散化の考え方を取り入れて
分割数ｎと復元必要数k（k<=n）の調節で元ファイルサイズに対して分割後容量を
100%以上ある程度自由に設定できるような方法を考えていま実装検証しましたが
うまくいったぽいです。
行列演算とxor演算と正規ビット欠落によって実現しているのですが、文字でうまく
説明できないので初期の検証に用いたExcel表を画像化してどかでうぷします。
閾値分散化の手法を参考にしたので分割後のファイル断片からはまったく
元の情報を引き出せなくなってます。
これでおいらの中ではファイルの分割部の問題は解決したつもりなので、あとは
ネットワークの転送部とファイルの永続性をどう解決するか（冗長化の手法のこと）
を考え中です。
たぶん5年後ぐらいには公開できる鴎。

>>857
CacheProtector.exeのbutton2_Click、Open/SavaFileDialogのTitle
"ファイルを開く"と"キャッシュを保存"が逆っす。

786 名前：[名無し]さん(bin+cue).rar 投稿日：2003/12/04(木) 03:40 ID:nlhhDDuT
>>783
「踏み込まれても」とか言ってる時点で自分がレベル低すぎる書き込みしてることに
気づいたがいいよ。既出だし、レス違いだし、しかも非現実的。
君は本気で警察に踏み込まれてシラをきりとおすなんて思ってるのか？
政治犯じゃないんだから、こんな略式起訴の罰金刑で済む罪を裁判で争うってか？
ちゃんと現実の社会を見なさい。それとも君はリアル厨なのかな？

ここはそんな非現実的なお子様の理屈じゃなく、現実的にP2Pやっても
「まず特定することは困難」なものの仕様を話し合う場です。

スレ汚しすいませんでした。

これってアレだな。ある程度の奴なら誰でも出来る処理なんだけど、
流す意図は何なの？もしかしてP2Pファイル共有ソフト作るの？

>862
なぜそんなにいきり立っているのかわかりませんが、
発信元を特定することが困難」なものの仕様にするのは当然のことですが、
完全キャッシュが残らないことにすることも重要だと思います。

部分キャッシュのみで、それだけでは全く復号できないものが、
送信可能化権に抵触するかは、議論のあるところで、
警察も慎重にならざるを得ないと思います。

ちょっと素人のひらめきで申し訳ないんだけどさ、
現ny2のノードを中継するソフトって作れないの?
ny2と別に起動して使うヤツで。
で、ny2のノードリストにはその中継してるノードを入れるとか。

nyに入ってくるパケットは折り返して他ノードに送信。出て行くバケットはそのままみたいな。

出来るとしても、ny利用者が全て使わないといけないんだろうけど、
転送者を確率的に増加させればUp側の特定も難しくなるような気がした。

出来ないなら厨房で罵ってもらってオケ。以上、FWをじーっと見てて思ったことですた。
アウポでnyの受信送信止められるから、似たような感じで折り返したりも出来るんじゃないかとｵﾓﾃ。
ほいじゃっ。

>843
　　_n
　（　l　　　　_、_
　 ＼ ＼　（ <_,`　）
　　　ヽ___￣￣　 ） 　　ｸﾞｯｼﾞｮﾌﾞ!!
　　　　　/ 　 　/

>>865
それは、nyを解析せにゃならんのじゃないかと思われ。

>865
出来る出来ないは別にして、個人的に着眼点は面白いと思う。

>>867
やっぱ無理なんですか、、、
FWは特定のアプリに入ってくるパケットを手前で止められるでしょ?これをそのまま外に
折り返すって無理なんですね、やっぱ。
そういうソフトが出来たら、nyを二つ起動させて片一方はこのソフトで折り返し転送。
もう片方は普通に使うとかしたら、転送の発生確率が上がるかなと思って。

ダメでしたか、、、失礼しました｡ｶﾞｯｸｼ

>>868
ありがとう、おやすみなさい。

>>864

自分と違う意見だったら、すぐに厨だのなんだの言って、
荒らす人がいます。
そういう人は無視するに限るよ。

>>865
けっこう面白いかもな。
ちょっと考えてみたが、難しそうだ。
ＡというＮｙ中継補助ソフトがあるとして
１　ＡがＮｙに届くデータをインターセプトしてコピー、片方をＮｙに渡す
２　Ａがもう片方をつながってる検索ノードのＩＰのどれかに転送
３　受信した他ノードのＡが送信ノードのＡから送られたデータをコピーして、やっぱり検索ノードのどれかに転送。

これを繰り返せばいいのかな？
匿名性に穴がありそうだが。

>>872
何も考えずにやると、Ｎｙが不正パケットということで破棄してしまうだろうから、Ｎｙのプロトコルを解析せんとまともなものにはならんわな。

こういうのあるんだけど使えるかい？

世界中のストレージを統合するグリッド基本ソフトウェア「Gfarm」を無償公開
ttp://www.aist.go.jp/aist_j/press_release/pr2003/pr20031125/pr20031125.html
Gfarmは、ネットワークにつながった世界中のたくさんのストレージを、１つのストレージと
して使えるようにするソフトウェアです。全体で１つのファイルシステムを実現するため、
ユーザは実際にデータを格納するリソースの配置場所を気にすることなく、超大規模データの
処理を行うことができます。管理組織の異なるリソースも、グリッド単一認証技術を用いて、
一度の認証で安全に共有できます。
Gfarmでは、大規模データの処理を世界中に分散させて処理することにより、データアクセスの
局所性を利用し高い処理性能を実現します。同じデータの複製を複数の場所に置き、利用者に
意識させること無く自動的に近くにあるデータを利用します。このため、プロセッサ台数に
応じて性能が向上します。一部の装置が故障したりネットワークが不通になった場合には、
他の複製を参照することにより高い信頼性を実現します。

グリッドデータファーム
ttp://datafarm.apgrid.org/arch.ja.html
グリッドデータファームはペタバイトスケールのデータインテンシブコンピューティングの
ためのプロジェクトです． 広域に存在する PC のローカルディスクを利用して，
大規模並列ファイルシステムの構築，大規模データ処理の実現， 安全な共有を目指しています

>>874
効率性重視だから中継機能が入ってないだろな。
やめとけ。

「送信はクロ、受信はシロなので送信側だけ匿名のネットワークを考えれば無駄が少ないのではないか」という素人考えです。笑ってやってください。

Ａ−Ｅ− Ｉ
｜　｜　｜
Ｂ　 F　 Ｊ
｜　｜　｜
Ｃ　 Ｇ　 Ｋ
｜　｜　｜
Ｄ　 Ｈ　 Ｌ

これまでのWinnyの検索リンクネットワーク（以後検索ネット)と同じ構造
検索ネットには、
・ノード情報（各ノードのIPとクラスタワード)
・保持キー情報(ファイル名、ハッシュ値、サイズ…)
が独自に常に流れている。

ノードＢにキャッシュされているファイルＸをノードＫが落とすもとのする。

１．検索ネットをたどって、ノードＢからファイルXの保持キー情報がノードＫに伝わる。
２．ノードＫは、リクエスト情報(自ノードのIPとファイルXのハッシュ値)を検索ネットに流す。
３．検索ネットをたどってリクエスト情報がノードＢに到達する。

さて、これからキャッシュを保持しているノードＢからそれを受け取るノードＫに転送経路を造ってゆくのですが、経路の造り方の前に、経路がどのような仕組みなのかを説明します。

仮想リンク暗号に基づいたプロトコルです。匿名接続が確立された後は、最初のノードはコンスタントに一定のサイズのパケットを第２ノードに一定間隔で送り続けます。
第２ノードは一定時間に受け取った複数のパケットをシャッフルしてランダムな順序で他のノードに転送します。

転送経路は一本道です。経路の最初のノード(この場合ノードＢ)を「コーラー」、最後のノード(この場合ノードＫ)を「レシーバー」と呼びます。
残りのノードは「スイッチ」と呼びます。この仕組みの匿名性は、非対称です。すなわち、コーラーは匿名ですが、レシーバーは匿名ではありません。
経路内の各ノードはコーラーと公開鍵を交換しあいます。各ノードはそれぞれのホップID(コーラーから何ホップ目か)を知っています。隣どうしのノードはお互い一組のリンクIDを共有しあいます。

よって、経路内の各スイッチは鍵ペア(コーラーの公開鍵と自ノードの秘密鍵のペア)、ホップID、二つのリンクIDを持ちます。直前のノード（コーラに一つ近い）と共有したリンクIDを「タイプA」、
一つ後ろのノードと共有したリンクIDを「タイプB」と呼びます。スイッチは一定時間毎に各リンクIDのタグが付いたパケットが来るのを待機します。タイプAのタグが付いたパケットを受け取ると各スイッチは、

１．秘密鍵でそのパケットを暗号解除し、
２．それのシーケンス・ナンバーを調べ
３．シーケンス・ナンバーを取り除いて、
４．タイプBのIDでパケットにタグを付け、
５．次のノードに転送する準備をする。

もし、タグBが付けられたパケットを受信したら、
１．パケットにシケンス・ナンバーを追記し、
２．公開鍵でパケットを暗号化し、
３．タイプAのタグを付け、
４．直前のノードに転送する準備をする。

もし、妥当なシーケンス・ナンバーを持たないパケットがあったら捨てる。全パケットが予想通りに届いた時にだけパケットは転送する。(ランダムな順序で)

コーラーからレシーバーに送る各パケットには、コーラーによってシーケンス・ナンバー付け、各ノードの公開鍵での暗号化と言う作業を転送経路の
ノード数分幾度も処理しないといけない。それが終了してからコーラーは適切なリンクIDでタグ付けして最初のスイッチに送る。各スイッチは暗号化、
シーケンス・ナンバーという「層」を一枚剥ぎ取って次のノードに転送します。レシーバーからコーラーへ送られるパケットはレシーバーによってシーケンス・ナンバー付け、
コーラーと交わした秘密鍵での暗号化をして末端のスイッチに送ります。各スイッチはシーケンス・ナンバー付け、暗号化という「層」を受け取ったパケットに上貼りして直前のノードに送ります。


このような経路の仕組みをふまえた上で、経路の造り方を説明します。
１．コーラー(この場合はノードＢ)は検索ネットから流れてくるノード情報からアトランダムに第１転送ノード(N1)(ノードＧとか)を選び、そのノード(N1)とお互いの公開鍵＋秘密鍵ペア(K1)とリンクID(S1)を決め、
２．もう一つ別のノード(ノードＩとか)を第2転送ノード(N2)としてアトランダムに選び
３．N1に、N2とのリンクID(S2)を取り決めるようにリクエストし、
４．N2とお互いの公開鍵＋秘密鍵ペア(K2)をN1を通して決め、
５．N1に、S1というタグが付いた全てのメッセージをK1を使って暗号解除しそのメッセージをS2というタグを付けしてN2に転送するようにリクエストする。
また、N1にS2というタグが付けられた全てのメッセージをK1を使って暗号化し、それにS1というタグを付けてN0(コーラー(この場合ノードＢ))に転送するようリクエストする。
６．転送さたい回数(ランダム)だけステップ２〜４と同様の動作を繰り返す。
７．最後にランダムノードの代わりにレシーバ(この場合ノードＫ)に接続させる。

この様に転送リンクの接続は送信側から受信側に張られます。よって受信側がポートを開いていないと受信することは出来ません。ポート０は受信出来ないと言うことです。

>>878
なかなか面白いが、すべてのノードでデクリプトエンクリプトを繰り返すと
マシンパワーがいくらあっても足りないよ。

64bitのハッシュキーを生成するいいアルゴリズムないですか?

>>879
そうですか、実はこれAnonという匿名P2Pの原理であるPipenet(>>696)を
パクってNyのシステムに引っ付けてみただけのものです。
Nyのネットワーク速度とこれが目指す速度は、マッチしないのかもしれませんね。