Linny開発プロジェクト Part2

Linny開発プロジェク� ..

331:login:Penguin
04/07/01 17:19 hhBC6xMz
言論の自由が保障されている国に住みながら、表現の自由のためとは何事？
違法行為をしたいだけじゃないのか。

332:login:Penguin
04/07/01 19:30 nV7KzNbc
>>331
個人情報保護法案を濫用されるようじゃだめぽ

333:login:Penguin
04/07/02 00:22 23tKNoDx
破壊活動防止の名のもとに、いわゆる盗聴法案で通信の傍受が行われ、
米国のテロ対策のためにエシュロンによる一方的な傍受が行われています。
別に、身元の安全を保証されて訴えたい事は今の所無いわけですが、
だからといって因果関係の説明がハッキリしない幇助罪の濫用を認めると、
他の法案との兼ね合いから恐ろしいことになります。

通信の機密を高める研究がおざなりだった事が、太平洋戦争の作戦面での
敗因をいくつも作っているし、日米自動車会談での米側の通信傍受によって
経済的な敗北を招いた事もあり、国益の面から考えても重要な課題です。

逆に、犯罪者が使う事も考えられますが、まず個人をマークできていなければ
通信の内容をクリアにした所で防ぎきれないのは911が証明してしまいました。
殆どの犯罪捜査の面で、通信の強度が最大の問題になりえないでしょう。
計画的な犯行の内容を知りながら、止める事が出来ないのですから。

334:login:Penguin
04/07/12 13:39 oP37bQUb
この手のはどこいったんだ？

335:login:Penguin
04/07/13 01:13 Wjb7ht7F
ここで相談しているだけで幇jy(ry

336:login:Penguin
04/07/13 03:12 UBZ1ootY
凶吐腐刑様が見てる

337:login:Penguin
04/07/20 09:21 uwPwIKQc
>>333
アホくさ！警視庁、警察庁公安部が所謂、盗聴法に基づいて、
主なプロダイバのサーバー横ににメール盗聴用のＢＯＸを設置してますが、なにか？
あのなぁエシュロンどうだとかより、足元の公安部のほうがタチ悪いんだけどねｗ

マルタイ対象者のメールは事実上、筒抜けというのがホントのとこ
そういうこと理解してないだろ！！ｗ

338:login:Penguin
04/07/20 12:06 ZHO2cB4v
俺のメールも盗聴してもらえるようになりたいものだ。

339:login:Penguin
04/07/20 14:21 NLHpUOa+
GnuPGはどうやって解読しているのやら。

340:login:Penguin
04/07/20 16:40 Ir/Sk1kn
実際のところ暗号化してメールしてる香具師なんてごく少数。
一番DQNだと思うのはSSLで住所とか入力させて、
確認用にふつーのメールで入力した住所とか送ってくるサイト

そういうサイトに限ってSSL対応だから絶対安心です、とか意味不明なことが書いてある。

341:login:Penguin
04/07/22 04:23 CHk2gMcm
i2pはどうよ？

342:login:Penguin
04/07/31 03:03 74tIdb2R
>>337
先頭の段落だけに反応してもしょうがないが、タチが悪い良いの話ではなく
ツツ抜けにしたところで分析を間違えれば防げないという話でせう。
「マルタイ対象者のメール」の絞込みから、内容の解読まで、エシュロンに
関わってる人間の多さ優秀さに比べればザルなんだろう…と、
長官狙撃事件の起訴見送りなんて大失態から伺えるなあってこったな。

ま、置いといて。

P2Pは悪くない，事業者が考えるべき策はまだある
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
興味深いのがYBBネットワークを設計した人ってところ。

343:login:Penguin
04/08/05 22:23 XEhm8+iR
P2Pとネットワーク技術の未来にあるもの
URLﾘﾝｸ(blog.japan.cnet.com)

344:login:Penguin
04/08/06 09:58 aRUsbpKu
キンタマで例のファイル見た。京都府警って素敵。w
しかもファイルを回収しようとしてるらしいからもう最高。

345:login:Penguin
04/08/10 10:50 thjax6dy
Torで書き込みテスト

346:345
04/08/10 10:50 thjax6dy
んで、もう一回書き込んでみると…

347:345
04/08/10 10:51 thjax6dy
うまく使えてないっぽい…

348:login:Penguin
04/08/10 11:13 thjax6dy
テスツ

349:login:Penguin
04/08/10 12:17 DncnYLgd
>>345-348
しっかりやれ (^^;
ていうか、/.jp への書きこみによると 2ch は対策を進めてるってことだけど、
それは関係ない?
URLﾘﾝｸ(slashdot.jp)
# オレは今のところ興味なくて、2ch の関連スレは読んでないけど。

350:login:Penguin
04/08/10 21:11 KaowJ+lx
ssh で使うときは socks 対応で(sshを)コンパイルし直さないと駄目なん？ > tor

351:login:Penguin
04/08/15 02:55 xoy5jEX1
【信州大学】P2Pソフト MARIE【新進気鋭】
ｽﾚﾘﾝｸ(download板)

352:login:Penguin
04/09/08 16:24 q40OB9ny
保守

353:login:Penguin
04/09/19 16:25:54 InKV6cb8
そういえば、昔このスレに47氏がカキコしてくれたなぁ。
ってことは、テレビに出たあの人もLinnyという言葉を知っているのか。
なんかすごいな。

354:login:Penguin
04/10/19 13:05:06 xgM0KVMN
>>351
某エロゲーメーカーのスクリプトエンジンと同じ名前だね。

355:login:Penguin
04/10/19 19:15:22 vSo4KyTx
Linnyはデーモンになるんですか？

356:login:Penguin
04/12/17 15:48:25 QCBUlcCx
>>355
その前提で只今開発中です。

357:login:Penguin
04/12/17 20:19:22 Caiw6Ncr
>>356
通報しますた

358:login:Penguin
05/02/19 09:27:04 BJUsIJg+
よーし、パパsystem3.5って言うP2Pソフトつくっちゃうぞ～

359:login:Penguin
05/02/19 18:04:42 crB44SZQ
　国産、linux ｐ２ｐソフト！！
期待します

360:login:Penguin
05/03/04 10:20:03 UoO0prm/
ファイル共有無くていいからLinnyBBS作って欲しいYO!!

361:login:Penguin
05/03/05 03:15:03 Jm1oAewG
実質、ファイル共有部を利用してBBSのデータをやり取りしてるから
結局は両方実装しなければならない…

362:login:Penguin
05/03/09 13:40:49 PMkWko3y
あのー
ずーっと待ってるんですけど。

363:login:Penguin
05/03/09 16:37:12 ufK0IMdA
>>362
だから何だ？

364:login:Penguin
05/03/09 16:44:39 PMkWko3y
>>363
まだー？
ってこと。

まあ、おまえには関係ないと思うけど。
なんでしゃしゃり出てきたの？

365:login:Penguin
05/03/09 17:41:52 JUJhub6J
バカ

366:login:Penguin
05/03/09 22:26:36 6CE5KbUl
待ってるだけじゃねぇ。

367:login:Penguin
05/03/10 03:47:15 PPPryd0b
なんか伸びてると思ったら…

BBS関連だけでも抜き出せないかとソースのようなものさんのを参考に見てみたけど
結局自分で書き直さないとぐちゃぐちゃだし、
共有関連も持ってこないとBBSデータのやり取りもできなさそうなので、めんどくなった。

これ解析するくらいなら、新しいの設計した方が速い気がしてやる気がでないし。
誰かやらないかな…

368:login:Penguin
05/03/12 15:33:17 AtiTv2c3
winnyのlinux版があれば全て解決。

369:login:Penguin
05/03/14 05:37:26 0YyTOLGz
>>368
47氏にでも依頼するのかい？
Linux版とかは作る気はない、とか言ってた気がするけど。

370:login:Penguin
05/03/15 15:43:32 fvSF73Mo
厨房避けに最適なのに

371:login:Penguin
05/03/22 20:38:19 yam08RNP
wikiは見れなくなっているのだな

372:login:Penguin
05/04/10 14:23:26 Qg6Yp9sw
Winnyをソース化しよう
ｽﾚﾘﾝｸ(download板)

ここか。

373:login:Penguin
05/04/19 20:18:53 QwGOconk
>>369
オープンソースで成り立てばLinux版も可能といっていた。

374:login:Penguin
05/04/19 20:28:15 iza5jbtz
要は暗号化と匿名化するのにソース非公開の方法しか
思い浮かばなかったんでしょ？
暗号化はともかく、
匿名をオープンソースで実現することは可能なんだろうか。

375:login:Penguin
05/04/20 00:08:19 1AqW0Nsw
暗号化も匿名化も出来る(っていうか暗号化は匿名化の手段でもある)が、
クラック避けが難しいって事じゃなかったかな>オープンソース化

376:login:Penguin
05/04/20 00:42:36 8LKPMmt8
ソース公開の匿名化はFreenetが(ry

377:login:Penguin
05/04/20 10:38:18 kXbvBhdm
ソース改変しても
相手の IP とか探ることはできないようになってるの？

378:login:Penguin
05/04/20 14:52:19 eT3XmLKY
>>377
おまいさん、通信相手のIPアドレスがわからずにどうやってTCP/IPの通信をするつもりだい

重要なことは、誰が何を公開しようとしたかがわからないことであって、
誰が何のデータを持っているかは(プロクシ動作のために)意味を持たないと思う。

379:login:Penguin
05/04/23 11:56:45 wBX6QwFp
>>377
nyの一番重要なところは、プロクシ動作であり、流れるデータが常にキャッシュされるところ、
そのためキャッシュだけを見た時に、データが単にプロクシ動作のためにキャッシュされたものなのか、
直接的にアップしたものなのかわからない。

だから、相手が何を流してきたか？、何て事は全く意味を持たなくなる。
そのデータは相手が直接流したものなのか？単なるプロクシ動作によるキャッシュなのか？
それがわからないからだ。

もし、キャッシュに違法なデータが含まれていたとしても、法的に立件することは難しい。
なぜならば、キャッシュ動作を否定することは、ネット自体を否定することになるから。

ネット自体、データを途中にあるルータや鯖にキャッシュしながら通信が成り立っている。
そのキャッシュの中には法に触れるデータも含まれるであろう。

つまり、nyの動作はインターネットそのものであり、nyの動作を否定することは、
ネットそのものを否定することになる。
だから自分のPCのキャッシュに違法なデータが含まれていたとしても、
それだけで捕まえることは無理なのだ。

47氏はただ単に通信の手段を与えたにすぎず、nyの開発をしただけでの逮捕は違法といえる。
しかしなぜ逮捕できたか？それは47氏が著作権を崩壊させるのが目的であると、
nyの開発動機を語っていたから。つまり苦し紛れの理由で無理矢理
ﾀｲ━━||Φ|(|ﾟ|∀|ﾟ|)|Φ||━━ﾎ!!

相手のIPや通信経路が分かったところで、それが無意味だって事が
わかったかい？>>377

380:login:Penguin
05/04/23 14:09:15 szBMljw1
>>379
あんた弁護士かい？
47はキャッシュ動作(Upload)の違法性を認識しており、自分用にはDownload Onlyの
クライアントを作成していたと言われているが、その件についてはどうかな？

381:login:Penguin
05/04/23 14:38:53 mU74wke+
犯罪に使われる可能性のある道具というのはいっぱいあるよね。包丁とか銃とか。
さらにほとんど犯罪にしか使われない道具もある。ピッキングツールとか。

犯罪にしか使われないソフトウェアというとクラッキングツールが
そうだけど、そこら辺はどうなるんだろうね。

382:login:Penguin
05/04/23 15:14:04 wBX6QwFp
>>381
そう、結局はそこが曖昧なままなのが問題。
犯罪に使われる「可能性」のある道具を作るのが違法ならば
インターネット自体が違法になりうるし、携帯電話だってなんだって当てはまってしまう。
最後には何も作ることが出来なくなる。
道具は使いようだからね。

>>380
つまりはキャッシュ動作の違法性も曖昧なままだ。
DLオンリーのクライアントがあったとしても、
47氏がキャッシュ動作が違法であると認識して作成したとは言えない。
それに、DLオンリーのクライアントを作成する理由は、他にいくらでもある。
本当にそんなクライアントがあったのかは知らないが・・
そもそも47氏がそんなもの使って一生懸命DLしてたと思えない。
やりたいことありすぎて時間もないだろうしな。
どっちにしても本人に直接聞かないことには推測の域は出ないので不毛。

つうか、別に違法性がどうのこうの言うつもりはなかったんだが・・・
ただ単に377があまりnyについて理解がなさ過ぎなのでレスしてみただけ。

383:login:Penguin
05/04/24 03:33:43 U52lbyvj
>>380
意図的に1次Upノードになることは公衆送信可能化権の侵害になることは明らかだが、
意図しない中継動作による2次以上のUpノードは明確には違法とはいえないのでは。
ただし、1次Upノードを、多数の中継Upノードの中に隠してしまうと、警察の捜査が
困難になることは認識していたと思われ。その意思が違法かどうかは微妙だが。

DownOnlyのノードがあったとしても、改造によるネットワークへの影響を調べていた
という言い訳ができたりもする。

384:login:Penguin
05/04/26 22:27:04 b+Bgg3SS
っていうか中継動作が違法になるんなら、海外のエロページが見える国内のゲートウェイは全部違法だろ。

385:login:Penguin
05/05/06 00:25:53 fBpY2R2q
中継動作をもって、それは合法ともいえないでしょ。しかも、中継動作なんて本質の部分ではないし。
「nyの否定」=[ネットの否定」ってのもぶっ飛びすぎでしょ。

47の目的は実験かもしれないけど、一般公開の実験にしては危険側によりすぎていると思うね。

386:login:Penguin
05/05/06 10:42:22 yIkyZYFZ
でも端から見てておもしろい実験だったよ。

387:login:Penguin
05/05/06 20:51:18 NC7j+KH8
>>385
つうかさ、それを言ったら、包丁作ったら逮捕。
みたいなのはどうなのよ。ぶっ飛んでませんか？

388:login:Penguin
05/05/06 22:15:02 +qWs8XmI
Winnyでネギは切れそうもないので包丁は関係無いと思う。

389:login:Penguin
05/05/06 23:09:51 fBpY2R2q
>>388
激しく同意。

390:login:Penguin
05/05/07 02:06:55 VV46m7bs
>>388-389
お前ら・・・・ほんとに頭悪いんだな・・

391:login:Penguin
05/05/07 09:12:45 N9jtnJjA
包丁いっぱい作って無料で配りまくるのと似てるかも。

392:login:Penguin
05/05/07 09:14:17 wZZgaFg6
たとえ話は脱線しがちだからほどほどに。

393:login:Penguin
05/05/07 10:07:08 i/BfrLdB
サリンを誰にでも使えるようにして、俺は使ってないから無罪といいはるのと同様かと。

394:login:Penguin
05/05/07 11:03:45 T+EVrL8z
サリンって使い道あるの？
包丁はちゃんとした使い道あるけど。

つまりnyもちゃんと使い方があって、それをちゃんと証明できるなら…

395:login:Penguin
05/05/07 13:06:54 tx50SVHK
自作ポエ（

396:login:Penguin
05/05/07 16:32:40 XnmIFUld
ブロードバンド時代に、プロバイダのバックボーンが耐えられるかの負荷テスト(ry

397:login:Penguin
05/05/07 16:38:29 hgkPuTxN
>>396
おまいは、厨房ともちゃでつか？

398:login:Penguin
05/05/16 22:51:09 HnJ5Ynpd
ダウソ板で開発宣言したのがまずかったのかな。

399:login:Penguin
05/06/22 20:48:18 GGpxtaXf
保守

400:login:Penguin
05/06/22 22:57:54 rSsOc9Il
包丁でサリンを切るスレはここですか

401:login:Penguin
05/06/23 14:56:46 bF+VLH9U
Linny マンセー
早く作れ！

402:login:Penguin
05/06/23 18:40:29 eVPle0x9
>>401
言いだしっぺ（ｒｙ

403:login:Penguin
05/06/28 00:02:34 /QQcXqnr
すごく出来が悪かろうと、公開さえしてくれれば
2ｃｈとしては反応がすごいのにな～需要はあるだけに
どなたか挑戦してみない？

404:login:Penguin
05/06/28 00:37:58 sxypLrzh
>>403
開発したら何か得するの？

405:login:Penguin
05/06/28 01:12:49 Woj5she8
>>404
いや、別に・・
需要ってあるよね

406:login:Penguin
05/06/28 01:35:17 sxypLrzh
>>405
ちゃんと市場調査してくれよな。

407:login:Penguin
05/06/28 01:39:16 eyx1+LDG
やはりこういうソフトはプロジェクトじゃなくて、
社会的にアレなはみだしプログラマが、社会への恨みつらみを糧に
夜な夜なせっせと書き上げて、2chで無造作にバイナリのみ公開。
自分だけ吸い上げ専用バージョンを用意してｳﾏｰ、というのが収まりが良い。

408:login:Penguin
05/06/28 01:40:30 sxypLrzh
>>407
根拠きぼんぬ。

409:login:Penguin
05/06/28 01:41:30 n+gd5yH6
やっぱオープンソースだろ

410:login:Penguin
05/06/28 16:33:52 9XnSpYyO
>>407
アレな人は多いけど、技術と執念がないんだな

411:login:Penguin
05/06/28 17:47:11 sxypLrzh
>>410
ご自分のことでつか？

412:login:Penguin
05/06/28 20:43:23 yfr2aRZu
オープンソースでも完全に成り立つ仕組みを考えればそれだけでも
このスレの名は売れるだろう。
WinnyにしてもShareにしても暗号鍵をバイナリに埋め込むことで
保護している。ここの部分を何とかしないとオープンソースでは難しいだろう。

413:login:Penguin
05/06/28 20:46:35 n+gd5yH6
いっそ暗号化部分だけ切り離してしまって、バイナリだけの動的モジュールにしたら？

414:login:Penguin
05/06/28 20:51:09 yfr2aRZu
それじゃあつまらなくない？
クラスタワードを鍵にするのも考えてみたけど、あんまりよくないね。

415:login:Penguin
05/06/28 23:59:23 n+gd5yH6
ちとつまらないかもしれませんね。
とりあえず俺はアホだが色々書籍を読み漁る予定。

416:login:Penguin
05/06/29 03:11:34 HU+dn+SH
>>413
隠すことによるセキュリティーは長続きしない。
根本的に、オープンでやっても維持できるシステムを構築すべき。

今までに出ているのは、ノードごとの相互監視をプロテクトにする案。
ちゃんとデータのやり取りをしているノード以外をネットワークから弾いてしまう、と。

末端同士のデータのやり取りの内容を隠す暗号化は、気分的なものと
中間ルータでキャプチャを簡単にはできなくするためだけであって、システムに
本質的に必要なものとは思わない。

Winnyのミソは、自分の保持データは、望んだものか中継なのかがわからず
機械的なプロクシとしての免責を企んでいる点。

417:login:Penguin
05/06/29 03:22:47 pkrk1XKs
ちゅーかx86がターゲットの時点でディスアセンブラで解析されるんだから。

418:login:Penguin
05/06/30 21:18:29 70M3Hd0P
Linnyのノードは完全に平等な権利をもたない。

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

URLﾘﾝｸ(www.itmedia.co.jp)
とかをまとめて見ると

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

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

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

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

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

420:login:Penguin
05/07/03 15:07:28 IZCijWVL
１．の解決方法

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

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

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

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

２．の解決方法

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

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

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

421:login:Penguin
05/07/03 15:08:56 IZCijWVL
（１）各ホストには、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
05/07/03 15:20:01 IZCijWVL
（７）パケットのフォーマットは、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
05/07/03 15:46:30 IZCijWVL
上記の理由より、外部からの匿名性は高くなるが、
内部の「悪意あるノード」に対しては、対処出来ない。
むしろ、内部からの攻撃には非常に脆いと考えられる。

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

424:login:Penguin
05/07/03 18:51:41 I4l1Sle2
結局、プロバイダに対して偽装をするとなると、インターネットoverインターネットを
構築することになって激しく面倒。
どっちみち、むこうさんから見れば激しいUpトラフィックを打ち落とせばいいだけだし。

確か、ノードにIDを振り、自分以外の誰にもIPアドレスとの対応を明かさないで、
バケツリレーでたまたま自分のところにきたものを黙って受け取る、とかいうルーティングしてた
P2Pソフトがあったと思われ。
muteだったはず。蟻がどうのこうののルーティング手法らしい。

425:login:Penguin
05/07/05 23:27:28 3m7vbi8S
現在のWinnyを鍵と暗号化ファイルを別々に管理できる仕様、つまり、
暗号化ファイルだけダウンロード、鍵だけダウンロードできる仕様にする。

このとき、暗号化ファイルのファイル名などから、鍵を連想して、P2Pネット内から、検索、
鍵をダウンロード出来ないようにする。

『鍵』をハッシュにかけた値を暗号化ファイルのファイル名にするのが妥当だろうか?

つまり、意味のある「キーワード検索」で引っかかるのは、鍵だけにする。
そして、鍵を落としたら、鍵をハッシュにかけて、再び検索クエリを流す。
理論的に、暗号化ファイルから、鍵を連想して、P2Pネット内から鍵を
落とす事は不可能になる。

鍵のキャッシュ保管用ディレクトリを、ハードディスクに物理的に1MBのパーミッションを
設定する。

ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・
一瞬で終わるぞ・・・・(w

そして、暗号化ファイルは論理的に「闇」に葬られる。

その後、暗号化ファイルは、まったく意味を成さないかと言うとそうでもない。

自分自身が、再び落としてくるファイルの中にキャッシュに含まれるファイルを
落とす可能性が高いからである。

鍵を落とすだけであれば、殆ど時間は要らないだろう。

コレだけで、匿名性は十分だと思うのだが・・・どうなのだろう?

426:login:Penguin
05/07/06 01:23:30 7XIcnn6N
そうか、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
05/07/06 03:31:05 Vmpb7hhF
Winnyの例でいうと、(といってもその時代に参加してなかったが)
暗号化キーがかけられたファイルというのがあって、暗号化キーがわからない限り
キャッシュが復号できない機能が存在してた。が、後になくなった。

消えた理由は、使われなくて不評だったから。
キャッシュですら消されてしまうのに、得体の知れない復号できないキャッシュを
残しておいてくれるお人よしな人はいなかったらしい。
簡単に復号できないキャッシュは、そういう運用をされることを考えた方がいいと思う。
なんかメリットがないか、ペナルティがないと持っててくれないと思う。

428:login:Penguin
05/07/06 16:34:55 pbi5Lyod
>>427
Winnyの暗号は、知っているもの同士が、集まって決めて、知らないものは
利用できなかったから、結果的に廃止になったのだと思う。

>>425の例では、クラスタワードに引っかかるのが、復号のための鍵の情報しか持っていない
キーファイルだけにして、キーファイルからハッシュなどの方法で連想できる値を元に、
再び検索をかけているので、暗号化ファイルは誰からも閲覧可能である。

キーファイルから暗号化ファイルは連想できるが、暗号化ファイルからキーファイルが
連想できない原理は、「1632412」から「偶数」であることを「連想」できても、
「偶数」から、「1632412」が「連想」できないのと同じこと。

429:login:Penguin
05/07/06 17:06:53 665Lc0RY
>>426
ハッシュは、128bitあれば十分か？

共通鍵は乱数で決めるとしても、衝突の危険性がない訳ではない。
キーファイルには、暗号化していないファイルのハッシュと共通鍵を
書いておき。暗号化ファイルのファイル名には、元ハッシュ値と共通鍵を
文字連結させて、決められた回数分だけ再びハッシュをかけたものを使う。

衝突の危険性は、低くなるだろう

あと、1000秒ってのは長すぎるだろ？
どうにかして、10秒程度に抑える必要あり。

こうしては、どうだろうか？

例えば、アプリ起動時にパスワード(英数字4文字で十分)を要求するようにする。
そのパスワードが書かれたファイルは、キーが保管されるパーミッションに保管される。
別に暗号化する必要はなく、昔のUNIXのpasswdファイルのように平分のままでもいい。
起動のパスワードを忘れたら、そのファイルを見ればいい。
アプリの隅っこに、「闇」ボタンがあり「闇」ボタンを押すと、

　　　　　　起動時パスワードをメモリに保存。

　　　　　　キーが保管されるパーミッションをフォーマット。

　　　　　　暗号化ファイルのファイル名を起動時パスワードで暗号化。

　　　　　　すべての設定をデフォルトにする。

430:login:Penguin
05/07/06 17:10:19 665Lc0RY
このときの暗号化強度は強いものである必要はないが、暗号化したかどうか
分からないようにすることが必要。つまり、ファイル名が16文字だった場合、
16文字のままでないといけない。誰かが、暗号化ファイルからデータを複合
しようとしても、ファイル名が暗号化されているかどうかは、本人しか知らない。

暗号化されていると分かって、シラミツブシにファイル名を復号して、ファイルを復号しようとしても、

　　　　　　500万のキーファイル

　　　　　　キーファイルから暗号化ファイルの連想に10秒かかる。

　　　　　　起動時パスワードは、数字だけ使っても10000通り。

辞書攻撃を受けても、3000～2000年以上かかる計算になる。

ほとぼりが冷めた所で、暗号化ファイルのファイル名を復号すればいい。
起動時に毎回要求されているパスワードなので忘れることもないだろう。
起動時に要求するパスワードは、パスワードを覚えさせることを目的としているため
変えないほうがよいと考えられる。

さらに、中継ノードは暗号化ファイルはキャッシュするが、キーファイルはキャッシュしないとなどの
仕様をつけ足せば、無闇にキャッシュを消す事もなくなるだろう。自分のクラスタが特化されている場合、
暗号化ファイルの中に自分が欲しているファイルがある可能性がある。キーファイルは、1KB以下のファイル
だが、暗号化ファイルは、それよりも遥かに大きい。よって、無闇にキャッシュを消すと、逆に欲しい
ファイルを手に入れるのに時間がかかってしまう。

431:login:Penguin
05/07/07 01:25:37 Wgy7DjVN
キーファイルがある->キャッシュを消せる。
キーファイルがない->クラスタ化できない。

432:login:Penguin
05/07/07 05:31:46 4ekhGbja
>>428
キャッシュから直接に鍵が検索できない、っていう仕様であってる？
中継ノードが復号できない仕様は、中継でたまったキャッシュを消される危険性が高いと思うんだが。

433:425
05/07/07 23:38:38 SQnN0+8k
たぶん、>>426 >>428と同一人物です。
Linuxは使ってますが、プログラマじゃないです(SEでもないです

だから、半ば「妄想」です。

ネットワークは、多少分かるので、オープンにしてもFreenet以上の匿名性が保て、
Winnyの70%ぐらいの使い心地のプロトコル「LINNY」を提案したいと思います。

間違えがあれば、どんどん指摘してください。
間違えがなくても、どんどん指摘してください。

錆び付いたこのスレを、皆で、暇つぶしに復活させましょう(w

434:425
05/07/07 23:39:34 SQnN0+8k
>>431

基本的に、キーファイルのクラスタは、「自然言語」によってクラスタが特化されて行き、
暗号化ファイルのクラスタは、キーファイルから連想できる値（これを「連想鍵」と呼ぶ
ことにする）によって、クラスタが特化されて行くので、まったく『独立』しています。

ですが、キーファイルを持っているノードは、高い確率で暗号化ファイルを持っているので
探索経路は、高い相関関係はあります。

つまり、キーファイルだけを見るとWinnyっぽいけど、暗号化ファイルの検索はFreenet的になる。

>>429-430

言ってることは、全体的に面白いし参考になります。
やはり、10秒ぐらいが妥当ですね。（「闇」ボタンは実装必須?

しかし、キーファイルをキャッシュさせないってのは、意味が分かりません。

キーファイルを途中経路、暗号化するなりしてキャッシュさせない場合、
匿名性は向上するが、使い勝手は非情に悪い。

キーファイルの探索経路上に自分のノードがある場合、高い確率で暗号化ファイルの
探索経路上にもあるので、キーファイルをキャッシュさせた方が、無闇にキャッシュを
消される事もないと思います。

>>432

>中継でたまったキャッシュを消される危険性が高いと思うんだが。

その通りです。こればっかりは仕方がありません。70%ですから・・・
しかし、キャッシュされたキーファイルに対応する暗号化ファイルは、
高い確率で、キャッシュされているはずです。

435:425
05/07/07 23:41:59 SQnN0+8k
今後の課題

いちいち、キーファイル用のパーティションなんか用意しないで、FDとかの
別の外部記憶に保存した方が良さそうですね。

さらに言えば、暗号化ファイル以外、メモリースティックにアプリ自体を含め全ての
データを保存した方がさらに良さそう(Linuxじゃメモリースティックは使えねーな

匿名性については、暗号化ファイルの受け渡しのみを見るとFreenetを超えていると思っています。
暗号化することで、ファイル自体に匿名性(何のファイルかわからない)があるからです。
上位ノードも、そのファイルが何かは、復号していない限りわからない。
下位ノードは、中継なのか、希望している「本人」なのか、上位ノードからは分からない。

しかし、普通にTCP使って、キーファイルの受け渡しを行った場合、匿名性はWinMX並になる。

ノード間の通信を暗号化しても、「外部」からの盗聴を阻止するだけで、内部の
「悪意あるノード」に対しては、簡単に盗聴を許してしまうからです。

そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が
提案しているような、ネットワークレベルで実現する方法を考えています。

問題点は、まだありそうな気もしますが、大枠は見えてきたので、また明日にでも書きます。

あと、「悪意あるノード」の定義や「外部からの攻撃」の定義もしていかないといけない

436:login:Penguin
05/07/08 01:49:08 kxCjllha
>425
＞中継キャッシュを消される
これを心配したのは、中継動作を理由にしらばっくれるつもりの仕様であれば、
ある程度の確率の中継キャッシュが残ることが必要だと思ったから。
今言われている仕様だと、中継ノードがキャッシュを持つ理由がなく
(暗号化をキャッシュから直接復号できないので、直接メリットがユーザにみえない)
キャッシュを持っているのが、放流主とリクエストした人だけという状況にならないかなと。

＞内部の情報収集ノード対策
ある程度は諦めた方がいいと思う。
あるノードがファイルを要求するときに、あるクラスタ内で情報が閉鎖的になりすぎていると
検索ができないことになる。オープンソースでやるのなら、キー情報を溜めておいて
ダウンを有利に進めようとする改良ノードが出てもおかしくない。
これらの正規の情報収集ノードと、悪意の情報収集ノードとが、システムからは
区別できないと思う。

437:login:Penguin
05/07/08 23:32:43 +d41giv6
「鍵」から「ファイル」を「連想」するってあたりが、面白そうですね。
うまくいけば、本当に枠組み作れるかもしれませんよ。

>>436

>放流主とリクエストした人だけという状況にならないかなと。

勝手にレスさせてもらいますが、私はキャッシュされることは匿名性とは
無関係だと思います。

「中継」は、「誰」が「誰」に送っているか分からなくする為だけであり、
「キャッシュ」は、中継局の回線資源を有効に使うためだけに存在します。

最終的に、提供者と、もらった人だけがファイルを持ったとしても、
大事なのは、そのことが『誰にも分からない』ということです。

>>435

>キャッシュされたキーファイルに対応する暗号化ファイルは、
>高い確率で、キャッシュされているはずです。

???? そんなはずはないと思いますよ。

私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で
「まったく違う」経路をたどると思います。

理由は、暗号化ファイルのクラスタは、連想鍵が似ている方向に探索クエリを
送信し、キーファイルのクラスタは、自然言語が似ている方向に探索クエリを
送信してするからです。

438:login:Penguin
05/07/08 23:34:26 +d41giv6
たとえば、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
05/07/08 23:36:27 +d41giv6
つまり、暗号化ファイルの探索経路からキーファイルの探索経路が予測でいないので、
ファイル提供者『X』の匿名性は、Freenetぐらい高いと思います。

しかし、中継局は意味の分からないファイルをキャッシュさせられるので、使い勝手は、
Freenetに毛が生えた程度です。

特に、暗号化ファイルは中継局からすれば、わけの分からない「ごみ」です。

でも、分からないだけで、自分が落としたいファイルも暗号化ファイルのキャッシュの中にあるかも知れません。

キーファイルを落としてきて、暗号化ファイル検索したら自分の中にあったら、なんとなく得した気分にになり、
暗号化ファイルが「宝の山」に見えるような心掛けよう。

でも、そりゃ無理ですね。

>>436の言う通り、直接的なメリットは何もないので、「中継局に為らないやつは吊るし上げろ！」
(最終的に、親になってくれるノードがいなくなり孤立する)ってカンジのシステムを作るれば、
中継することを義務付けれます。そうすると、キャッシュを消してしまうと、同じ検索クエリが来たとき、
再度、回線資源を食われてしまいます。つまり、ディスク資源か、回線資源のどちらかを提供しないといけません。

ふつう、回線資源のほうが貴重(ダウンロードが遅くなるのはイヤ)だから、結果的にキャッシュを消すことも少なくなるでしょう。

>>430は、そういうことを言いたかったのではないでしょうか？

>そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が
>提案しているような、ネットワークレベルで実現する方法を考えています。

ソフトイーサを利用したIP偽装とか聞いたことはありますが、管理が面倒だし、
逆にセキュリティホールになってしまいそうな気味します。

第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは?

440:login:Penguin
05/07/09 00:05:42 wPON5jd/
あかん・・・パラドックスや・・・

オープンソースでセキュアなP2Pなんてやっぱ無理やで

441:login:Penguin
05/07/09 06:46:08 c1VczgQE
>>440
どのあたりが矛盾しているかを書くのがいいと思われ。
人はいるみたいだし、何か知恵が出るかも。

442:425
05/07/09 08:28:10 yQGfiko3
>>437

>私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で
>「まったく違う」経路をたどると思います。

仰る通りです。私が勘違いしていました。

クラスタの独立は、匿名性の向上には繋がりますが、中継ホストに残った
暗号化ファイルは、ホストにとってはタダのゴミ。

中継を嫌がるホストが増えるので、システム全体として中継を拒むホストを
孤立させていくような仕組みが必要になりますね。

>第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは?

一応、内部からも分かりにくい方法を考えてみたのですが、逆に攻撃の対象にされてしまうかも知れませんし、
ネットワークに負荷がかかるので止めます。

ネットワーク偽造は、また問題があったときに考え直します。

しかも、上記のような、クラスタの独立による途中経路不一致から、
十分に、匿名性はありそうですし。

443:425
05/07/09 08:47:29 Aqub9gDD
>>440

最終的に、内部ノードが通信相手のIPをかき集めれば、ネットワークに参加しているものが
見えてしまっても(これはしょうがないので諦めます)、「誰」が「何処」へ「何」を送って
いるのか分からなくしてしまえば、まったく問題ありません。

>>238が説明してくれているように、ファイル提供者『X』の匿名性は十分守られています。
現実世界で目を付けられるような行動をしてない限り、この匿名性が破られる事はありません。

目星を付けられていても、ファイル提供者『X』は、ローカルにあるキーファイルを消しまえば
良いだけだと思うのだが、どうだろう?(w

落とすだけの輩も、中継ホストになって貰えば、システム上十分な役目を果たしてくれる。キャッシュされなくても、そのホストさえ通ってくれれば、
良い訳ですし、キャッシュしなかった場合、回線資源が喰われて、ダウンロードが遅くなります。

他に、情報が漏れてしまうような箇所はあるでしょうか？

444:425
05/07/09 08:48:16 Aqub9gDD
あとは、「クラッカー」対策

このシステム最大の弱点は、情報が書き換えられたキーファイルや、悪意あるノードが
初めから暗号化ファイルをが存在しないキーファイルを大量にネットワーク内に生成し、
大量に出回ると、対応する暗号化ファイルに辿り着けないキーファイルが出て来て、
結果ネットワークが機能しないと言う恐ろしい自体が起こります。

逆に、暗号化ファイルを書き換えられたりしても、キーファイルからは辿り着けない。

この問題を解決するには、2042bit公開鍵を使った署名システムが1番確実で安直でしょう。

キーファイルには、電子署名と公開鍵が付属し、途中で書き換えが起これば、
即座に分かります。

電子署名と公開鍵が双方とも書き換えられている場合は、連想した暗号化ファイルに問題、
または、ファイルが見つからないと言う事が続くようであれば、

その公開鍵が付属する、キーファイルを一切信用しないで捨てる。

このように、公開鍵を一種のIDとしても扱えます。

これは、公開鍵の設計に時間がかかる性質を利用したシステムです。

ファイルアップ用の公開鍵は、インストール時に作成し､その後、変える必要もありません。

445:login:Penguin
05/07/09 11:50:32 3O2EbHgy
ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。
この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。
かといって、毎回違う鍵を使えば、署名の意味が全くない。

446:425
05/07/09 22:44:19 7r68v9eE
>>444の続きです

急用が出来たので、書いている途中で飛び出してしまいました。

公開鍵の暗号方式は、RSAです。

2042bitなのは、暗号の強度を上げるためではなく、公開鍵の設計を難しくするためです。

クラッカーが、大量に粗悪なキーファイル(暗号化ファイルを持たないキーファイル)を
アップしたとしても公開鍵が同じであれば、全て無視できます。

よって、クラッカーは大量に公開鍵を設計する必要があります。

2042bitの鍵を生成するには、恐らく、最低十数秒はかかるので、
クラッカーに大きな負担となります。

一方、ユーザのは悪質な公開鍵を信用しなければいいし、逆に、常に
暗号化ファイルが存在する良い公開鍵を信用すればいいわけです。

ここで、ポイントとなるのは良い公開鍵になるためには、その公開鍵の秘密鍵を知らなければ不可能である事です。
これによって、良い公開鍵の成り済ましを防げます。

この公開鍵は、変えるのも自由ですが出来るだけ変えないほうが良いでしょう。

447:425
05/07/09 22:54:49 7r68v9eE
さらに、キーファイルに信用性の無い公開鍵が載っていたとしても、そのキーファイル自体は良質(暗号化ファイル)が
あれば、そのキーファイルを、別の人間が電子署名と公開鍵を上書き(公開鍵と電子署名を消して書き直)します。

ただし、その別の人間の公開鍵は分かっても、その人間が誰かは、本人しか知りえません。

その公開鍵が、信用性が高い公開鍵であれば信用できます。この動作を「信用性公開鍵の上書き認証」と呼ぶ事にします。
この「認証」は誰でも出来るようにします。と言うより、理論的に誰でも出来てしまいます。

ここで重要になってくるのは、「キーファイルに載っている公開鍵 = ファイル提供者の公開鍵」の公式が
必ずしも、一致しないと言う点です。逆にいえば、ファイル提供者の公開鍵である必要性はないと言うことです。

つまり、公開鍵は「このキーファイルの内容は私(誰か分からないが公開鍵は分かる)が保障する」程度の意味しかありません。

次に問題になってくる攻撃は、信用のある公開鍵が既に上書き認証しているキーファイルを、さらに悪質な公開鍵が認証を
上書きすると言うものです。

そこで、公開鍵を検索ワードに入れることを許す仕様にします。つまり、
「ある公開鍵」と「検索ワード」を含む検索を可能にすると言うコトです。

(念のため、言っておきますが、ここで言う「信用」は、基本的に、そのノードの「経験」によるものです。
つまり、ノードは公開鍵に関する経験をデータベース化しておく必要があります)

運用しだすと、認証を専門に行う「認証屋」が出てくると思います。
つまり、これの狙いは「認証局の分散処理」です。

448:425
05/07/09 22:59:22 7r68v9eE
>>445

> ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。
> この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。

「ファイルアップ用」の公開鍵と別に、「ノード間経路暗号用」の公開鍵も実装させ、

これにより、外部からの参照を不可能になり、出来るのは内部ノードの情報収集のみになります。

内部のノードが可能な情報収集手段は極々限られている上、上位ノードから流れてきたキーファイルが、
中継なのかどうなのかも分かりません、トラフィックを分析した所で、キーファイルは小さすぎて、
別のトラフィックで埋もれてしまいます。

現実世界で、ボロを出さない限りまったく問題はありません。

「ノード間経路暗号用」の公開鍵は、ECC40bitあたりでどうかなと思っています。
これも、インストールした時点で決めます。(変えるのは、完全に自由です)

449:425
05/07/10 16:44:13 m7iyk48S
クラッカー対策に、いろいろ考えていると、かなり大掛りなものになってしまった。
とりあえず、暫定的に考えている事を、全てまとめてみる。

ノード間通信

　検索、キーファイルの受け渡し　⇒　暗号化（SSLモドキ）
　暗号化ファイルの受け渡し　　　⇒　暗号化なし(元々してある)　　　

基本構成

　「元ファイル」から、「キーファイル」と「暗号化ファイル」を生成し、
　この2つを、「共有」する。

　「キーファイル」は、データを元に「連想鍵」を生成し、
　「連想鍵」を元に、「暗号化ファイル」を検索する。

　終端ノードで「連想鍵」から「暗号化ファイル」が発見されると、そのノードは、
　「暗号化ファイル」から「暗号化チェックサム・キー」を返す。

　「暗号化チェックサム・キー」のキャッシュは起こりません。
　 (キャッシュした所で、共有できない無意味なデータになる)

　「暗号化チェックサム・キー」から、「絶対連想鍵」を生成し、
　「絶対連想鍵」を元に、再び「暗号化ファイル」を検索する。

　つまり、

　「キーファイル」(自然言語)のクラスタ
　「連想鍵」(暗号化ファイル)のクラスタ
　「絶対連想鍵」(信用性情報)のクラスタ

　の３つのクラスタが形成され、やや煩雑なものになる。

450:425
05/07/10 16:46:00 m7iyk48S
キーファイルが持っている情報

　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
05/07/10 16:50:15 m7iyk48S
連想鍵

　暫定的には、1-2),1-3)を文字連結させ、それを数千回(何回にするかは検討中)
ハッシュにかけた値。ここで使うハッシュは衝突対策で、MD5を想定している。

　冗長性などの問題から、計算方法は変わる可能性あり。

絶対連想鍵

　絶対連想鍵は、ノードにキャッシュされる度、毎回計算され上書きされる。2-3)をMD4で
　ハッシュにかけた値を、連想鍵と文字連結させ、さらにMD5でハッシュにかけた値。

　『最終的』に、この値によってダウンロードするファイルを決定する。

452:425
05/07/10 16:51:40 m7iyk48S
暗号化チェックサム・キー

　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)が無ければ、「暗号化チェックサム」は復号できない。
　そして、「キーファイル」単体では、意味を成さないフィールド。

様々な、情報があるが、これらを美味く使えば、悪質なノードを排除したり、
壊れた暗号化ファイルを、出回らなくするように出来るでしょう。

例外処理は、今日はしんどいので、また今度書きます。

次ページ