- 1 名前：login:Penguin mailto:sage [03/06/22 19:40 ID:zhqumg4k]
- 今までのP2Pファイル共有ソフトに負けない機能、手軽さ、匿名性を備えた
全く新しいWWWベースのファイル共有ソフトを作るプロジェクトです。
-------------------- 535 ◆HO0OFh2RXI 氏による最初の発言 --------------------
03/04/30 23:19
pc.2ch.net/test/read.cgi/linux/1024473956/535
> みんなでデーモンとして動くようなLinux版Winnyつくらない？
> デーモンとして動かなくてもコンソールで使えればいいです。
> どうでしょうか？自分は、Linux C(C++)プログラマーです。
前スレ
Linny開発プロジェクト
pc.2ch.net/test/read.cgi/linux/1053087824/
Project Page
linny.sourceforge.jp/
議論用Wiki
linny.sourceforge.jp/wiki/
※プロジェクト参加希望の方は535氏<burner@users.sourceforge.jp>まで連絡してください。
また、本格的に参加する場合はSourceForge.jpのアカウントを取得してください。
- 433 名前：425 mailto:sage [2005/07/07(木) 23:38:38 ID:SQnN0+8k]
- たぶん、>>426 >>428と同一人物です。
Linuxは使ってますが、プログラマじゃないです(SEでもないです
だから、半ば「妄想」です。
ネットワークは、多少分かるので、オープンにしてもFreenet以上の匿名性が保て、
Winnyの70%ぐらいの使い心地のプロトコル「LINNY」を提案したいと思います。
間違えがあれば、どんどん指摘してください。
間違えがなくても、どんどん指摘してください。
錆び付いたこのスレを、皆で、暇つぶしに復活させましょう(w
- 434 名前：425 mailto:sage [2005/07/07(木) 23:39:34 ID:SQnN0+8k]
- >>431
基本的に、キーファイルのクラスタは、「自然言語」によってクラスタが特化されて行き、
暗号化ファイルのクラスタは、キーファイルから連想できる値（これを「連想鍵」と呼ぶ
ことにする）によって、クラスタが特化されて行くので、まったく『独立』しています。
ですが、キーファイルを持っているノードは、高い確率で暗号化ファイルを持っているので
探索経路は、高い相関関係はあります。
つまり、キーファイルだけを見るとWinnyっぽいけど、暗号化ファイルの検索はFreenet的になる。
>>429-430
言ってることは、全体的に面白いし参考になります。
やはり、10秒ぐらいが妥当ですね。（「闇」ボタンは実装必須?
しかし、キーファイルをキャッシュさせないってのは、意味が分かりません。
キーファイルを途中経路、暗号化するなりしてキャッシュさせない場合、
匿名性は向上するが、使い勝手は非情に悪い。
キーファイルの探索経路上に自分のノードがある場合、高い確率で暗号化ファイルの
探索経路上にもあるので、キーファイルをキャッシュさせた方が、無闇にキャッシュを
消される事もないと思います。
>>432
>中継でたまったキャッシュを消される危険性が高いと思うんだが。
その通りです。こればっかりは仕方がありません。70%ですから・・・
しかし、キャッシュされたキーファイルに対応する暗号化ファイルは、
高い確率で、キャッシュされているはずです。
- 435 名前：425 mailto:sage [2005/07/07(木) 23:41:59 ID:SQnN0+8k]
- 今後の課題
いちいち、キーファイル用のパーティションなんか用意しないで、FDとかの
別の外部記憶に保存した方が良さそうですね。
さらに言えば、暗号化ファイル以外、メモリースティックにアプリ自体を含め全ての
データを保存した方がさらに良さそう(Linuxじゃメモリースティックは使えねーな
匿名性については、暗号化ファイルの受け渡しのみを見るとFreenetを超えていると思っています。
暗号化することで、ファイル自体に匿名性(何のファイルかわからない)があるからです。
上位ノードも、そのファイルが何かは、復号していない限りわからない。
下位ノードは、中継なのか、希望している「本人」なのか、上位ノードからは分からない。
しかし、普通にTCP使って、キーファイルの受け渡しを行った場合、匿名性はWinMX並になる。
ノード間の通信を暗号化しても、「外部」からの盗聴を阻止するだけで、内部の
「悪意あるノード」に対しては、簡単に盗聴を許してしまうからです。
そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が
提案しているような、ネットワークレベルで実現する方法を考えています。
問題点は、まだありそうな気もしますが、大枠は見えてきたので、また明日にでも書きます。
あと、「悪意あるノード」の定義や「外部からの攻撃」の定義もしていかないといけない
- 436 名前：login:Penguin mailto:sage [2005/07/08(金) 01:49:08 ID:kxCjllha]
- >425
＞中継キャッシュを消される
これを心配したのは、中継動作を理由にしらばっくれるつもりの仕様であれば、
ある程度の確率の中継キャッシュが残ることが必要だと思ったから。
今言われている仕様だと、中継ノードがキャッシュを持つ理由がなく
(暗号化をキャッシュから直接復号できないので、直接メリットがユーザにみえない)
キャッシュを持っているのが、放流主とリクエストした人だけという状況にならないかなと。
＞内部の情報収集ノード対策
ある程度は諦めた方がいいと思う。
あるノードがファイルを要求するときに、あるクラスタ内で情報が閉鎖的になりすぎていると
検索ができないことになる。オープンソースでやるのなら、キー情報を溜めておいて
ダウンを有利に進めようとする改良ノードが出てもおかしくない。
これらの正規の情報収集ノードと、悪意の情報収集ノードとが、システムからは
区別できないと思う。
- 437 名前：login:Penguin mailto:sage [2005/07/08(金) 23:32:43 ID:+d41giv6]
- 「鍵」から「ファイル」を「連想」するってあたりが、面白そうですね。
うまくいけば、本当に枠組み作れるかもしれませんよ。
>>436
>放流主とリクエストした人だけという状況にならないかなと。
勝手にレスさせてもらいますが、私はキャッシュされることは匿名性とは
無関係だと思います。
「中継」は、「誰」が「誰」に送っているか分からなくする為だけであり、
「キャッシュ」は、中継局の回線資源を有効に使うためだけに存在します。
最終的に、提供者と、もらった人だけがファイルを持ったとしても、
大事なのは、そのことが『誰にも分からない』ということです。
>>435
>キャッシュされたキーファイルに対応する暗号化ファイルは、
>高い確率で、キャッシュされているはずです。
???? そんなはずはないと思いますよ。
私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で
「まったく違う」経路をたどると思います。
理由は、暗号化ファイルのクラスタは、連想鍵が似ている方向に探索クエリを
送信し、キーファイルのクラスタは、自然言語が似ている方向に探索クエリを
送信してするからです。
- 438 名前：login:Penguin mailto:sage [2005/07/08(金) 23:34:26 ID:+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 mailto:sage [2005/07/08(金) 23:36:27 ID:+d41giv6]
- つまり、暗号化ファイルの探索経路からキーファイルの探索経路が予測でいないので、
ファイル提供者『X』の匿名性は、Freenetぐらい高いと思います。
しかし、中継局は意味の分からないファイルをキャッシュさせられるので、使い勝手は、
Freenetに毛が生えた程度です。
特に、暗号化ファイルは中継局からすれば、わけの分からない「ごみ」です。
でも、分からないだけで、自分が落としたいファイルも暗号化ファイルのキャッシュの中にあるかも知れません。
キーファイルを落としてきて、暗号化ファイル検索したら自分の中にあったら、なんとなく得した気分にになり、
暗号化ファイルが「宝の山」に見えるような心掛けよう。
でも、そりゃ無理ですね。
>>436の言う通り、直接的なメリットは何もないので、「中継局に為らないやつは吊るし上げろ！」
(最終的に、親になってくれるノードがいなくなり孤立する)ってカンジのシステムを作るれば、
中継することを義務付けれます。そうすると、キャッシュを消してしまうと、同じ検索クエリが来たとき、
再度、回線資源を食われてしまいます。つまり、ディスク資源か、回線資源のどちらかを提供しないといけません。
ふつう、回線資源のほうが貴重(ダウンロードが遅くなるのはイヤ)だから、結果的にキャッシュを消すことも少なくなるでしょう。
>>430は、そういうことを言いたかったのではないでしょうか？
>そこで、キーファイルの検索,受け渡し専用に、内部,外部,に対する匿名性を、>>419-423 が
>提案しているような、ネットワークレベルで実現する方法を考えています。
ソフトイーサを利用したIP偽装とか聞いたことはありますが、管理が面倒だし、
逆にセキュリティホールになってしまいそうな気味します。
第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは?
- 440 名前：login:Penguin mailto:sage [2005/07/09(土) 00:05:42 ID:wPON5jd/]
- あかん・・・パラドックスや・・・
オープンソースでセキュアなP2Pなんてやっぱ無理やで
- 441 名前：login:Penguin mailto:sage [2005/07/09(土) 06:46:08 ID:c1VczgQE]
- >>440
どのあたりが矛盾しているかを書くのがいいと思われ。
人はいるみたいだし、何か知恵が出るかも。
- 442 名前：425 mailto:sage [2005/07/09(土) 08:28:10 ID:yQGfiko3]
- >>437
>私は、終端ノードが同じ可能性は高いのですが、途中経路は高い確率で
>「まったく違う」経路をたどると思います。
仰る通りです。私が勘違いしていました。
クラスタの独立は、匿名性の向上には繋がりますが、中継ホストに残った
暗号化ファイルは、ホストにとってはタダのゴミ。
中継を嫌がるホストが増えるので、システム全体として中継を拒むホストを
孤立させていくような仕組みが必要になりますね。
>第一、ネットワークを偽装して、自己ルーティングしても、内部からは分かってしまうので意味がないのでは?
一応、内部からも分かりにくい方法を考えてみたのですが、逆に攻撃の対象にされてしまうかも知れませんし、
ネットワークに負荷がかかるので止めます。
ネットワーク偽造は、また問題があったときに考え直します。
しかも、上記のような、クラスタの独立による途中経路不一致から、
十分に、匿名性はありそうですし。
- 443 名前：425 mailto:sage [2005/07/09(土) 08:47:29 ID:Aqub9gDD]
- >>440
最終的に、内部ノードが通信相手のIPをかき集めれば、ネットワークに参加しているものが
見えてしまっても(これはしょうがないので諦めます)、「誰」が「何処」へ「何」を送って
いるのか分からなくしてしまえば、まったく問題ありません。
>>238が説明してくれているように、ファイル提供者『X』の匿名性は十分守られています。
現実世界で目を付けられるような行動をしてない限り、この匿名性が破られる事はありません。
目星を付けられていても、ファイル提供者『X』は、ローカルにあるキーファイルを消しまえば
良いだけだと思うのだが、どうだろう?(w
落とすだけの輩も、中継ホストになって貰えば、システム上十分な役目を果たしてくれる。キャッシュされなくても、そのホストさえ通ってくれれば、
良い訳ですし、キャッシュしなかった場合、回線資源が喰われて、ダウンロードが遅くなります。
他に、情報が漏れてしまうような箇所はあるでしょうか？
- 444 名前：425 mailto:sage [2005/07/09(土) 08:48:16 ID:Aqub9gDD]
- あとは、「クラッカー」対策
このシステム最大の弱点は、情報が書き換えられたキーファイルや、悪意あるノードが
初めから暗号化ファイルをが存在しないキーファイルを大量にネットワーク内に生成し、
大量に出回ると、対応する暗号化ファイルに辿り着けないキーファイルが出て来て、
結果ネットワークが機能しないと言う恐ろしい自体が起こります。
逆に、暗号化ファイルを書き換えられたりしても、キーファイルからは辿り着けない。
この問題を解決するには、2042bit公開鍵を使った署名システムが1番確実で安直でしょう。
キーファイルには、電子署名と公開鍵が付属し、途中で書き換えが起これば、
即座に分かります。
電子署名と公開鍵が双方とも書き換えられている場合は、連想した暗号化ファイルに問題、
または、ファイルが見つからないと言う事が続くようであれば、
その公開鍵が付属する、キーファイルを一切信用しないで捨てる。
このように、公開鍵を一種のIDとしても扱えます。
これは、公開鍵の設計に時間がかかる性質を利用したシステムです。
ファイルアップ用の公開鍵は、インストール時に作成し､その後、変える必要もありません。
- 445 名前：login:Penguin mailto:sage [2005/07/09(土) 11:50:32 ID:3O2EbHgy]
- ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。
この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。
かといって、毎回違う鍵を使えば、署名の意味が全くない。
- 446 名前：425 mailto:sage [2005/07/09(土) 22:44:19 ID:7r68v9eE]
- >>444の続きです
急用が出来たので、書いている途中で飛び出してしまいました。
公開鍵の暗号方式は、RSAです。
2042bitなのは、暗号の強度を上げるためではなく、公開鍵の設計を難しくするためです。
クラッカーが、大量に粗悪なキーファイル(暗号化ファイルを持たないキーファイル)を
アップしたとしても公開鍵が同じであれば、全て無視できます。
よって、クラッカーは大量に公開鍵を設計する必要があります。
2042bitの鍵を生成するには、恐らく、最低十数秒はかかるので、
クラッカーに大きな負担となります。
一方、ユーザのは悪質な公開鍵を信用しなければいいし、逆に、常に
暗号化ファイルが存在する良い公開鍵を信用すればいいわけです。
ここで、ポイントとなるのは良い公開鍵になるためには、その公開鍵の秘密鍵を知らなければ不可能である事です。
これによって、良い公開鍵の成り済ましを防げます。
この公開鍵は、変えるのも自由ですが出来るだけ変えないほうが良いでしょう。
- 447 名前：425 mailto:sage [2005/07/09(土) 22:54:49 ID:7r68v9eE]
- さらに、キーファイルに信用性の無い公開鍵が載っていたとしても、そのキーファイル自体は良質(暗号化ファイル)が
あれば、そのキーファイルを、別の人間が電子署名と公開鍵を上書き(公開鍵と電子署名を消して書き直)します。
ただし、その別の人間の公開鍵は分かっても、その人間が誰かは、本人しか知りえません。
その公開鍵が、信用性が高い公開鍵であれば信用できます。この動作を「信用性公開鍵の上書き認証」と呼ぶ事にします。
この「認証」は誰でも出来るようにします。と言うより、理論的に誰でも出来てしまいます。
ここで重要になってくるのは、「キーファイルに載っている公開鍵 = ファイル提供者の公開鍵」の公式が
必ずしも、一致しないと言う点です。逆にいえば、ファイル提供者の公開鍵である必要性はないと言うことです。
つまり、公開鍵は「このキーファイルの内容は私(誰か分からないが公開鍵は分かる)が保障する」程度の意味しかありません。
次に問題になってくる攻撃は、信用のある公開鍵が既に上書き認証しているキーファイルを、さらに悪質な公開鍵が認証を
上書きすると言うものです。
そこで、公開鍵を検索ワードに入れることを許す仕様にします。つまり、
「ある公開鍵」と「検索ワード」を含む検索を可能にすると言うコトです。
(念のため、言っておきますが、ここで言う「信用」は、基本的に、そのノードの「経験」によるものです。
つまり、ノードは公開鍵に関する経験をデータベース化しておく必要があります)
運用しだすと、認証を専門に行う「認証屋」が出てくると思います。
つまり、これの狙いは「認証局の分散処理」です。
- 448 名前：425 mailto:sage [2005/07/09(土) 22:59:22 ID:7r68v9eE]
- >>445
> ある特定の個人or集団が同じ秘密鍵で署名し続ければ、発信元がわかってくる可能性があるのだが。
> この公開鍵のついたキーファイルはあのプロバイダのどこどこ地域から出てくるとかね。
「ファイルアップ用」の公開鍵と別に、「ノード間経路暗号用」の公開鍵も実装させ、
これにより、外部からの参照を不可能になり、出来るのは内部ノードの情報収集のみになります。
内部のノードが可能な情報収集手段は極々限られている上、上位ノードから流れてきたキーファイルが、
中継なのかどうなのかも分かりません、トラフィックを分析した所で、キーファイルは小さすぎて、
別のトラフィックで埋もれてしまいます。
現実世界で、ボロを出さない限りまったく問題はありません。
「ノード間経路暗号用」の公開鍵は、ECC40bitあたりでどうかなと思っています。
これも、インストールした時点で決めます。(変えるのは、完全に自由です)
- 449 名前：425 mailto:sage [2005/07/10(日) 16:44:13 ID:m7iyk48S]
- クラッカー対策に、いろいろ考えていると、かなり大掛りなものになってしまった。
とりあえず、暫定的に考えている事を、全てまとめてみる。
ノード間通信
検索、キーファイルの受け渡し ⇒ 暗号化（SSLモドキ）
暗号化ファイルの受け渡し ⇒ 暗号化なし(元々してある)
基本構成
「元ファイル」から、「キーファイル」 と 「暗号化ファイル」を生成し、
この2つを、「共有」する。
「キーファイル」は、データを元に「連想鍵」を生成し、
「連想鍵」を元に、「暗号化ファイル」を検索する。
終端ノードで「連想鍵」から「暗号化ファイル」が発見されると、そのノードは、
「暗号化ファイル」から「暗号化チェックサム・キー」を返す。
「暗号化チェックサム・キー」のキャッシュは起こりません。
(キャッシュした所で、共有できない無意味なデータになる)
「暗号化チェックサム・キー」から、「絶対連想鍵」を生成し、
「絶対連想鍵」を元に、再び「暗号化ファイル」を検索する。
つまり、
「キーファイル」(自然言語)のクラスタ
「連想鍵」(暗号化ファイル)のクラスタ
「絶対連想鍵」(信用性情報)のクラスタ
の３つのクラスタが形成され、やや煩雑なものになる。
- 450 名前：425 mailto:sage [2005/07/10(日) 16:46:00 ID: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 mailto:sage [2005/07/10(日) 16:50:15 ID:m7iyk48S]
- 連想鍵
暫定的には、1-2),1-3)を文字連結させ、それを数千回(何回にするかは検討中)
ハッシュにかけた値。ここで使うハッシュは衝突対策で、MD5を想定している。
冗長性などの問題から、計算方法は変わる可能性あり。
絶対連想鍵
絶対連想鍵は、ノードにキャッシュされる度、毎回計算され上書きされる。2-3)をMD4で
ハッシュにかけた値を、連想鍵と文字連結させ、さらにMD5でハッシュにかけた値。
『最終的』に、この値によってダウンロードするファイルを決定する。
- 452 名前：425 mailto:sage [2005/07/10(日) 16:51:40 ID: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)が無ければ、「暗号化チェックサム」は復号できない。
そして、「キーファイル」単体では、意味を成さないフィールド。
様々な、情報があるが、これらを美味く使えば、悪質なノードを排除したり、
壊れた暗号化ファイルを、出回らなくするように出来るでしょう。
例外処理は、今日はしんどいので、また今度書きます。
- 453 名前：425 mailto:sage [2005/07/10(日) 17:00:37 ID:m7iyk48S]
- 訂正
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 mailto:sage [2005/07/10(日) 17:39:23 ID:m7iyk48S]
- >425
ソンナメンドクサソウナモンダレガツカウ？
って言いたい所だが、オープンソースってのに既に問題があるんじゃないの？
プロトコル名に「LINNY」ってのも、どうなんだ？
オープン仕様、オープンソースならば、Windowsでもいいわけだが・・・
プロトコル名は、「Anonymous Winny」をもじって、「ANONY」に一票。
- 455 名前：login:Penguin mailto:sage [2005/07/10(日) 18:24:15 ID:hZ/9wEx5]
- 「ONANY」
- 456 名前：login:Penguin mailto:sage [2005/07/10(日) 23:06:13 ID:pnHySe/b]
- まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。
- 457 名前：login:Penguin mailto:sage [2005/07/10(日) 23:14:38 ID:kOFHOXTv]
- 鍵の長さって、現時点で論じるべきことなのかと思うがね。
- 458 名前：login:Penguin mailto:sage [2005/07/10(日) 23:22:09 ID:SZNYDAl1]
- 最初は無暗号で徐々に暗号化を実装とかは？
- 459 名前：login:Penguin mailto:sage [2005/07/10(日) 23:23:12 ID:rhhJYpWd]
- で、コード書くやつはいるのか
- 460 名前：login:Penguin mailto:sage [2005/07/10(日) 23:31:36 ID:kOFHOXTv]
- リスクを背負う事無く安全に流通させる経路さえあれば誰か書くんじゃない？
- 461 名前：425 mailto:sage [2005/07/11(月) 01:33:11 ID:MZK+5YtJ]
- >>456
>まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。
やっぱり、そう思います？
やはり、「匿名性」と「セキュリティ」と言う相反するものを同居させるには
かなりムリがでてきますね。
この世界、あまりにOSIモデルのように、厳密で繁雑なシステムは
嫌われるので、もう少し簡略化したプロトコルが必要。
簡略化をする方法の1つは、連想鍵と言う概念を無くす方法です。 つまり、
キーファイルに暗号化ファイルのハッシュ値を直接貼り付けておき、
そのハッシュ値を元に、暗号化ファイルを探す方法
詳細は抜きにして、メリット・デメリットについて。
メリット
検索は高速。仕組みは簡単なので、暗号化ファイルの改ざん対策が容易
デメリット
「暗号化ファイル」から「キーファイル」が、解かってしまう。
つまり、キーファイルがなくても、ハードディスクを没収されると、P2Pネット内から
キーファイルを落として、復号されてしまう危険性がある
「キーファイル」検索条件に制限をかけるなどの対策を取れば、ある程度OK?
プロトコル名は、>>454にあやかって「Simple ANonymous winNY」を
もじって「SANNY」なんてのを考えてみる。
- 462 名前：login:Penguin mailto:sage [2005/07/11(月) 16:32:40 ID:/TB8jfv9]
- 階層がわかりにくい…だれか図示してくれ…
何に対しての匿名性を確保して、何に対しての改変耐性を確保する予定なのかを
示してもらえると、もう少しわかりやすくなるかも。
連想鍵で１階層噛ましているの理由がよくわからん。
正規の検索かければ誰でも復号できるんでしょ？
攻撃側に対する耐性になってないと思う。
- 463 名前：425 mailto:sage [2005/07/11(月) 22:29:31 ID:iaGb8hb0]
- >>462
>何に対しての匿名性を確保して
「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、
「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。
「暗号化ファイル」単体では、何のファイルで何がかかれているか、
まったく不明にするコトで、完全な匿名性を実現しようとしたもの。
要は､国が本気で動いても、よく言われる「匿名の度合い」での、
「疑いの域を出ない」(Level 5)を実現しようとしたもの。
勿論、「言論の自由」のために(w
>何に対しての改変耐性を確保する予定なのか
運用しだすと、よくありそうなのは、「暗号化ファイル」を落としてみると
どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延
キーファイルだけ作りまくる輩・・・など
- 464 名前：425 mailto:sage [2005/07/11(月) 22:33:50 ID:iaGb8hb0]
- >連想鍵で１階層噛ましているの理由がよくわからん。
何故こんなに煩雑なものになったのかと言うと、
キーファイル ⇒ 暗号化ファイル は、分かっても、
暗号化ファイル ⇒ キーファイル は、絶対に分からなくする。
つまり、「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってはいけない。
という、前提条件があるからです。
具体的に言うと、壊れていたり、改ざんされている暗号化ファイルを ネットワーク内で、蔓延させないためには、
暗号化ファイルを キャッシュしたノードは、毎回、暗号化ファイルのハッシュを 行い、その値を公開する。
そして、検索者はそのハッシュ値を元に暗号化ファイルを検索し、
落とすと、壊れたり、改ざんされている暗号化ファイルは、
それ以上、蔓延することは無く消えていく。
これは、Freenetで実装されている技術です(ただし、暗号化はされていない)。
じゃあ、キーファイルに、「暗号化ファイルのハッシュ」を
直接貼り付けると、どう言う事が起こるでしょうか?
暗号化ファイルのハッシュ値は、暗号化ファイルから直ぐに分かってしまい、結果、
「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってしまっている。
で、こんなのになったワケ。
よく見ていただくと分かると思うが、「キーファイル」と「暗号化ファイル」は「同じデータ」を
一つも持っていません。(持っていますが、暗号化されていて分かりません)
ま、はっきり言って、私も､まともに動くとは思えない。（システム全体が重過ぎる
もう少し、使い勝手のいい、安易なものの方がいい。
- 465 名前：login:Penguin mailto:sage [2005/07/11(月) 22:53:31 ID:/qz9fPP7]
- ttp://s2net.s41.xrea.com/
アイデアだけはいっぱい出ているし、国内外問わず研究論文もたくさんある。
問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと
いうこともあるし
いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない
だったら誰も使わないだろう
- 466 名前：login:Penguin mailto:sage [2005/07/11(月) 23:20:09 ID:wBE6vaKT]
- > いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない
> だったら誰も使わないだろう
そこはオープンソースなんだから、UI は誰かが作ってくれるだろう。
通信部分は Winny の時に散々ループしてた dll なり so なりにすればいいじゃん。
- 467 名前：425 mailto:sage [2005/07/12(火) 02:03:25 ID:cTi5k0J7]
- >>465
>問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと
確かにいえる。ノードは、全て信用できるものであれば、簡単でしょうけど
規模が大きくなれば、なるほど信用性は薄くなる。
Winnyでも、ウイルス流れたしね。
- 468 名前：login:Penguin mailto:sage [2005/07/12(火) 11:11:49 ID:nQBkc+7e]
- > Winnyでも、ウイルス流れたしね。
どんなウィルス？
- 469 名前：login:Penguin mailto:sage [2005/07/12(火) 13:43:43 ID:nQBkc+7e]
- ん？
> ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・
なんだこれ。
- 470 名前：login:Penguin mailto:sage [2005/07/12(火) 14:16:23 ID:5JN9Gt1s]
- >>463
＞「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、
＞「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。
「意図してダウンロードを開始した、末端ノード」に対しては、
「あるファイル(の暗号化されたもの)」であることはわかるのでは。
「意図して最初にシステムに投入した、末端ノード」に対しても
同様ではないか。
その情報がどこまで伝播してしまうか、で。
隣から見た場合、意図してダウンロードを始めたか否かで
「知っているかどうか」を知ることができるのは危険かなと。
＞どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延
「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは
実際にファイルを展開できたノードにしか判定できない。
その情報を伝播させて大丈夫かな。
それとは別に、システムで検知できる改変(チェックサムが違うとか)は
これだと弾けそうだけど。
- 471 名前：425 mailto:sage [2005/07/13(水) 00:34:25 ID:dIg+n2Qr]
- >「意図してダウンロードを開始した、末端ノード」に対しては、
>〜中略〜「知っているかどうか」を知ることができるのは危険かなと。
言っている意味が、分かりにくいので、良ければ、具体例を上げて
その危険性を、教えて欲しえてくれませんか?。
>「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは
>実際にファイルを展開できたノードにしか判定できない。
キーファイルが、「信用」出来る場合を考えてみますと、
ハッシュ値、つまり「メッセージダイジェスト」は、データ情報の特徴を圧縮したもので、同じデータを
ハッシュにかければ、同じ値になるが、1バイトでも違うと、まったく違う値になります。
要は、ハッシュ値が一緒であればファイル内容も同じ(厳密に言うと、非常に低い確率で違う場合もあり)
であると言うことです。
つまり、ハッシュ値を元に検索を行えば、改ざんや破壊が起こっていないファイルを
探す事がで来ます。
そして、改ざんや破壊が起こったファイルは、参照される事無くいつしか消えていきます。
- 472 名前：470 mailto:sage [2005/07/13(水) 03:23:59 ID:MNJFxM92]
- >>471
ちゃんと理解できてないんで、誤解してると思うけど。
例えば、このスレの過去ログをネットワークに投入したいとする。
投入する1次upノードは、当然内容を知っているはず。
ネットワークから、このスレの過去ログをダウンロードしようとしたノードは、
(その情報が確かなら)そのデータは過去ログであることを知っているはず。
隣接ノードに、1次upノードであること、またはダウン要求ノードであることが
(ダウン要求の内容(この場合は過去ログであること)も含めて)ばれてしまうことは、
例えどんな暗号化がされていようとも、内容を知った上で送受信しているという事になる。
これは、このスレの過去ログが発禁扱いになっていて、政府が監視中であるなら
危険なことだと思う。言論の自由を目指すんだしw
ダウン要求の内容がばれてしまうことは、ある要求をシステムでの要求に変えることと等価である。
あるファイルが落とせるってことは、投入側と取得側でなんらかの同意がいるってことでしょ。
取得するのと同じやり方で、取得方法だけ持っておいて、ネットワークを流れる要求を
監視されたらやばいんでないの、という意味。
当然中継ノードなら、内容は知らずに、P2Pネットワークとしての責務として
ただ踏み台にされただけだから、(現時点の世界では)こういう心配はしなくていいのでは、と。
- 473 名前：470 mailto:sage [2005/07/13(水) 03:32:35 ID:MNJFxM92]
- ＞後段
キーファイルが信頼できるかどうかがそもそもやばいんで内科医ということ。
プロトコル的に、データが改変損傷してないのは保障するとして、
例でいうところの、このスレの過去ログではなく、Winny本スレの過去ログがおちてくる場合
そのキーファイルやら暗号化データはどうするのってこと。
そういうことする香具師はたくさんいるし、ミスってそうなることもあるよ。
内容知っている人にしかネットワークの暗号データは評価できないんだけど、どうやって排除すべきか。
内容が合ってるかどうかを流すことのできるノードも、情報を知っていることになって監視対象入りかも。
そういうことも含めて、誰が何の情報を知っていて、何の情報を知っていることになっていて
隠すべきものは何かな、と考えてたらよくわからなくなってしまって聞いたんだけど。
- 474 名前：425 mailto:sage [2005/07/13(水) 15:46:02 ID:OdrjvaIG]
- このシステムは、Winnyと言うより、Freenet的だったので、
さまざまな部分で、効率が悪い。
今度は、Winnyベースの高速な匿名性ファイル共有で、特にファイル提供者の
匿名性が非常に高い物を思いついたので、まとまり次第うｐします。
(キーファイルと暗号化ファイルに分けるという点は変わりません。)
>>472
このシステムにおいて、Freenetのような、アップデートの概念はありません。
あるのは、「検索」と「ダウンロード」だけです。
まず、「あるファイル」を自分の公開領域に置き、その存在をネットワークに知らせます、
知らせる、といっても、「ここにあるよ」と言ったら、匿名性もへったくれもないので、
ネットワークに、そのファイルの「検索クエリ」を送信します。
そして、その検索クエリは、高い確率で自分のノードに戻ってきます。
その時、自分自身で返事を返してやれば、誰にも悟られずに、そのファイルを
ネットワークのクラスタに追加できます。
しかし、キーファイルのような軽いファイルであれば問題ないが、重いファイルの場合、
Freenet同様問題がでてくるので、根本的な見直しが必要
- 475 名前：425 mailto:sage [2005/07/13(水) 15:54:48 ID:OdrjvaIG]
- >>473
まぁ、人間ミスするのでそれは、大した問題ではないと思う(笑
そう言うのは、排除する必要もないんじゃ?
問題になってくるのは、例えば『ダイエット本』で検索した時、『ダイエット本』に
関係するキーファイルが落とされます。
しかし、『ダイエット本』と書きながら、暗号化ファイルを落として復号してみたら、
何故か『サラ金の広告』だった場合は問題です。
このための公開鍵です。要は、公開鍵はIDです。信用できないIDは、信用しなければいいだけです。
（その公開鍵であれば、無条件で消す）
そして、このような信用できない公開鍵があれば、信用できる公開鍵も存在するはずです。
公開鍵は、一種のIDです。ならば、信用性のある公開鍵の「なりかわり」の心配はないか?
それは、公開鍵に対する秘密鍵が分からない限り、不可能です。
- 476 名前：login:Penguin mailto:sage [2005/07/13(水) 18:17:25 ID:4rsiUBe0]
- で、いつごろまで屁理屈こねくりまわすの？
- 477 名前：login:Penguin mailto:sage [2005/07/13(水) 18:28:32 ID:+oLOISW/]
- おまえがしびれを切らして愚痴るまで。
つまりあともう少しだな。
- 478 名前：login:Penguin mailto:sage [2005/07/13(水) 20:32:46 ID:MNJFxM92]
- >>474
Freenetよか遅いのは考える意味がないw
この案はこの辺りが潮時か…
＞｢検索クエリ｣
この送受信を傍受されたらどうするのって言ってるんだが。
＞公開鍵
信用できる鍵にあたるまでがんばれってか。
攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。
>>445 で指摘されてるように、固定は危険だし。
- 479 名前：login:Penguin mailto:sage [2005/07/13(水) 20:59:14 ID:4rsiUBe0]
- >>477
すでに愚痴ってるわけだが。
- 480 名前：425 mailto:sage [2005/07/14(木) 16:51:28 ID:5jVfH12S]
- >>478
>Freenetよか遅いのは考える意味がないw
私もそう思います。ですが、キーファイルの通信は非常に軽いので
そのあたりで使えると思っています。
>この案はこの辺りが潮時か…
一応、暗号化ファイルの通信を独立させた、次の案があるので、
もう、暫く付き合っていただけませんか?
>この送受信を傍受されたらどうするのって言ってるんだが。
通信を暗号化したレイヤでトンネリング(SSLっぽいの)すれば、外部からのチャプチャリングは、
シャットアウトできます。
内部ノードは、自分の上位ノードと下位ノードのことしか、分からないので、
どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。
- 481 名前：425 mailto:sage [2005/07/14(木) 16:52:55 ID:5jVfH12S]
- ・・・続き
>信用できる鍵にあたるまでがんばれってか。
むしろ、信用できる鍵の方が多くなると私は考えています。
RSA2048bit公開鍵の鍵セットを作るには、どんなに強力なマシンでも
かなり時間を喰らうのにくらべ、「除外(一切受け付けない)」のは一瞬で終わる。
「攻撃者」が、鍵セットを作り続けたとしても、どっちが不利かといえば、
圧倒的に「攻撃者」が不利。
かといって、「攻撃者」は、「他の公開鍵」に成り代わろうとしても、
相手の「秘密鍵」を、知らなければいけない。
その「攻撃者」が、RSA2048bitをクラックできるとしたら、ネットバンキングは
とっくの昔に破綻しています。
ならば、そんな馬鹿な事を実際にする香具師は、殆ど現れないはずです。
- 482 名前：425 mailto:sage [2005/07/14(木) 16:54:57 ID:5jVfH12S]
- >攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。
上記の理由で、「なりかわり」は、理論上できません。
となれば、「同じ鍵」であれば「同一人物」です。
要は、「あなたは、何を基準に『人』を信用しますか？」ということです。
少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は
「信用できない」
5回連続で、きちんとした暗号化ファイルが存在するキーファイルの鍵は、ある程度は、
「信用できる」
って、ことです。
上記のような簡単な判断は、アプリ側に任せていいと思います。
あと、公開鍵の情報を保存しておく必要もあります。
>>445 で指摘されてるように、固定は危険だし。
外部からの、キャブチャリングは暗号化してしまえば、不可能です。
内部ノードは、上位ノードと下位ノードの事しか知りません。
その状況で、「公開鍵」の発信元を調べるのは、非常に困難を極めます。
「公開鍵」の発信元を調べるスピードよりも、ファイルが拡がるスピードの方が
圧倒的に速いからです。
一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。
- 483 名前：login:Penguin mailto:sage [2005/07/14(木) 17:31:19 ID:D9NFH06e]
- で、何%までできた？。机上の空論もいいけど、コード書いて実装できなきゃ
意味ないぞｗ
- 484 名前：login:Penguin mailto:sage [2005/07/14(木) 17:39:02 ID:TU8gjza9]
- よし、使用言語はObj-Cで決まり。
- 485 名前：login:Penguin mailto:sage [2005/07/14(木) 18:27:54 ID:+fLeQjmb]
- >>482
> 少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は
> 「信用できない」
これだと単純すぎると思う。
暗号化ファイルはちゃんと存在するけど、内容が期待したのと違うっていうような攻撃が来るんじゃないかな。
こういう攻撃だと、除外する側は暗号化ファイルを受信して、内容を調べて判断しなきゃいけない。
鍵を作る手間に比べて、受信した内容を確認・判断する手間って、むしろ大きいんじゃないかな。
期待通りのファイルかどうかを判断するのは、自動化が難しい問題だろうし。
- 486 名前：login:Penguin mailto:sage [2005/07/14(木) 20:11:14 ID:PKmLnshm]
- 実際にコード書いて検証すればいいだけだのに、
どうして机上の空論を書くのに精を出しているのだろう。
- 487 名前：login:Penguin mailto:sage [2005/07/14(木) 21:13:19 ID:E+/HEPIn]
- しびれを切らして愚痴りだした香具師がいるなｗ
机上の空論、大いに結構。
- 488 名前：login:Penguin mailto:sage [2005/07/14(木) 21:20:30 ID:PKmLnshm]
- はて。
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 mailto:sage [2005/07/14(木) 21:35:52 ID:ey7oBSjc]
- 425は机上の空論の妄想野郎。
>>433で本人が認めてるし。こいつ自身は実装やる能力がない。
そんな、脳ナシに標準化なんか出来るか。Freenetに任せとけ。
- 490 名前：login:Penguin mailto:sage [2005/07/14(木) 23:14:16 ID:HLeFWI2x]
- わからんかなぁ
ほら、あれと同じ雰囲気を楽しむスレなんだよここは。
居酒屋や串焼き屋でだ、仲間内で出来もしない事を熱く議論することがあるだろ。
そういう空気が好きなんだよ俺等
- 491 名前：login:Penguin mailto:sage [2005/07/14(木) 23:26:53 ID:PKmLnshm]
- 釣り堀スレか。
- 492 名前：きたろう mailto:sage [2005/07/14(木) 23:38:17 ID:3X5YI5cJ]
- 常に欲求不満でイライラしている。
自分の能力に劣等感を持っている。
出る杭は徹底的に叩かないと気が済まない。
そんなネガティブな感情に流されてる暇人の存在を感じます、父さん！
- 493 名前：login:Penguin mailto:sage [2005/07/16(土) 03:35:55 ID:qxGyOozH]
- >>486
実際に手を動かせるくらいできてればこんなところで考える前に
ダウソで"ちょっとまちなー"ができるって。
システムが中途半端だとコーディングする意味ないし。
>>480
＞通信の傍受
外部からの、ではなく、内部からのってこと。
つまり(正規の動作をある程度行う)スパイノードの存在は大丈夫かなと思って。
＞どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。
検索システムがどのように予定されてるのかはわからないけど。
例えばクエリが帰ってくるようにリターンアドレスを入れておくような実装だと、
「誰が」リクエストを出したのかがばれてしまう、というような情報漏れを心配している。
＞一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。
1次Upノードが特に危険だと思うんだが。
Shareとかは強制拡散してるみたいだし、Freenetとかはバッファにプッシュして
所持ノードの概念がなくなるみたいだし、いろいろ工夫してると思う。
Winnyは、何もしない、という戦略をとったが。
- 494 名前：425 mailto:sage [2005/07/16(土) 23:10:58 ID:jAChWphq]
- 新案をコトコト煮詰めています。
暗号化ファイルは、StaticNATを使った面白いネットワーク偽装を
考えています。
>>493
キーファイルの共有は、完全なFreenetスタイルを考えています。
つまり探索とかもいっしょ、大量のノードが協力しない限り、
要求者を求めるのは難しい。
>1次Upノードが特に危険だと思うんだが。
「自分自身」で「自分自身しか持っていないファイル」を探索するクエリを、
隣のノードに送信すると、どうなると思います？
Freenetでは、経路上に多くのループが発生します。
つまり、必ず探索クエリは、自分自身に戻ってきます。
そこで、アップロードしながらダウンロードしたらどうなるでしょうか?
自分の下位ノードは、自分がそのファイルを中継しているか、アップしている
かは分かっても、誰がその要求を出しているのか分かりません。
逆に、上位ノードは、自分がそのファイルを中継しているか、要求している
かはわかっても、そのファイルが何処から流れてきているのかわかりません。
そして、途中経路では「複製」が出来ます。
つまり、1次Upノードは、誰にも悟られる事なくネットワーク上にファイルの
複製を作れます。
つまり、これで誰が1次Upノードかは謎になる。
- 495 名前：login:Penguin mailto:sage [2005/07/17(日) 00:28:28 ID:iMIptb/B]
- ほんとにできてるの？何％くらい
- 496 名前：login:Penguin mailto:sage [2005/07/17(日) 01:26:26 ID:ksRYqrdf]
- >>495
>>489
- 497 名前：login:Penguin mailto:sage [2005/07/17(日) 09:10:57 ID:3e1zqbRW]
- >>495-496
早漏は損だよ
- 498 名前：login:Penguin mailto:sage [2005/07/17(日) 17:36:40 ID:hmmV4Rhb]
- >>494
＞1次Upノード保護
経路のループを利用して自己偽装Down要求ってことですな。
＞Freenetでは、経路上に多くのループが発生します。
＞つまり、必ず探索クエリは、自分自身に戻ってきます。
このループはある程度大きくないと効果が期待できないと思うんですが、
あまり大きいと、中継転送による速度の低下が心配されると思いますが
バランスとかはどうなるでしょうか。
確実にクエリが戻ってくることは期待して大丈夫ですかね。
繋ぎ変えがおこるネットワークならば、ループが切れたりしないかな。
＞ネットワーク偽装
期待してます。よろ。
- 499 名前：425 mailto:sage [2005/07/18(月) 18:56:18 ID:juv970X8]
- 「HannyNet（Hashing anonymous winny Network）」案
ちょっとは、まとまった思うので書いてみる。
「HoneyNet」(行動の一部始終を監視できるように設計されたネットワーク)の
真逆を逝っているので、何となくつけてみたくなった。
匿名性の重要度
ファイル提供者 >> ファイル要求者
ファイル提供者の匿名性は最優先される。
なぜなら、「提供する者」がいなくなれば、
「共有」は存在しえないからである。
つまり、ファイルを提供すればするほど、匿名性の保障に優位に立つことができて、逆に、
吸いとるだけの輩は、匿名性を保障しないようにシステム全体が推移するような仕組みが
望ましい。
- 500 名前：425 mailto:sage [2005/07/18(月) 18:57:13 ID:juv970X8]
- ファイル構成
1.キーファイル（テキスト形式）
1-0)キーワード情報
クラスタ化に必要な自然言語パターン
1-1)暗号化ファイル共通鍵
読んで字の如く、暗号化ファイルの共通鍵。
1-2)暗号化ハッシュコード
2-1)のハッシュコードを、1-3)の秘密鍵で、暗号化したもの。
(べつに、1-1)で暗号化しても問題ない。)
意味がないように思えるが、非常に意味がある。
暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
つまり、「暗号化ファイル」から「キーファイル」は分からない。
1-3)IP/ポート交換ワンタイム公開鍵(RSA 128bit)
IPとポート番号を申請するときに使う。
詳しくは、後述。
- 501 名前：425 mailto:sage [2005/07/18(月) 18:58:06 ID:juv970X8]
- 1-4)公開鍵(RSA 2048bit)
1-5)の公開鍵。
1-5)電子署名
1)〜4)の電子署名。こうした方が、たぶん都合がいい。
1-6)1-4)のハッシュコード
ノードにキャッシュされる度、随時上書きされる。
キーファイルの検索では、同時に公開鍵の参照も許しているが、
256バイトのデータを毎回参照していたのでは、ノードに対する
負担が大きい。
そこで、ハッシュを用いて大まかに検索して送信する。そして、
最終的な判断は、検索クエリを出したノード自体に委譲する。
ここで、使うハッシュ関数は、MD5やMD4のように厳密なものではなく
計算量が、非常に軽いものが望ましい。固定ビット長なので、上手い
方法があるはずです。
- 502 名前：425 mailto:sage [2005/07/18(月) 18:59:12 ID:juv970X8]
- 2.暗号化ファイル（バイナリ形式）
2-1)ハッシュコード
2-2),2-3)のファイルの内容をハッシュにかけた値(MD5)
要は、ファイル名。
ノードにキャッシュされる度、随時上書きされる。
2-2)データフィールド
暗号化された、データが入っています。
2-3)IP/ポート交換ワンタイム秘密鍵(RSA 128bit)
ファイル最後尾から、128bitが1-3)に対する秘密鍵になっている。
詳しくは、後述。
- 503 名前：425 mailto:sage [2005/07/18(月) 19:00:32 ID:juv970X8]
- 3.通信ポート
3-1)管理ポート(TCP)
ポート番号： インストール時に決定
主に､キーファイルの検索/受け渡しをする。
暗号化ファイルのプロキシ要求(後述)や、NAT要求(後述)もこのポートで行う。
この通信は、暗号化される。
要は、コマンドもファイルも一緒に送り、暗号化の手間を軽減する。
処理の優先度は、
NAT要求 > 検索クエリ > キーファイルの送受信 > プロキシ要求
3-2)暗号化ファイル検索ポート(UDP)
ポート番号： インストール時に決定
3-1)の通信でコネクションが張られていないIPからの要求は、
全て遮断することとする(応答は受け入れる)。
この通信は暗号化されない。
- 504 名前：425 mailto:sage [2005/07/18(月) 19:01:18 ID:juv970X8]
- 3-3)暗号化ファイル転送ポート(TCP)
ポート番号：随時決定
特に説明ナシ。この通信も暗号化されない。
3-4)ICMPエコー要求(ICMP)
イワユル、「ping」コマンドで、セキュリティ上は切っておいた方が望ましいが、
相手のマシンが、起動しているかどうかを調べるのに最も楽な方法。
TCPコネクションを確立させる前にpingを送れば、余計なSYNパケットを出さなくてすむ。
- 505 名前：425 mailto:sage [2005/07/18(月) 19:02:07 ID:juv970X8]
- コマンド・パケットフォーマットなど
今の段階では適当。とりあえず、決まっている物から
(所詮、暇人の考える程度の事ですから)
4.暗号化ファイル検索パケット(UDP通信)
4-1)余命(8bit)
そのパケットのが後、どれ位生きれるのかを示す。1つノードを通過すると、
年をとって余命が減るかもしれない。また、減らないかもしれないし、
一気に老けてしまうかもしれない(要は適当に決まる)。
勿論、0になった地点で死にます。
4-2)乱数(24bit)
通信を区別するために、適当な乱数を設ける。
4-3)ハッシュコード(128bit)
暗号化ファイルのハッシュ値
- 506 名前：425 mailto:sage [2005/07/18(月) 19:03:03 ID:juv970X8]
- 4-4)暗号化IP/返信ポート(128bit)
要求ノードのIPと返信ポートを1-3)で暗号化したもの。
暗号化ファイル、つまり、1-3)の秘密鍵である2-3)を所持している者だけが分かる。
暗号化ファイルを所持していたとしても、キーファイルを所持していなかった場合、
ファイルの内容は分かりません。
128bitRSA暗号なので、公開鍵が分かれば、本気になれば解ける程度の強度。
つまり、キーファイルから暗号が解けるかもしれない。
ですが、キーファイルがあればの話しですし、公開鍵も不明な状態で解けるほど
軟な暗号じゃありません。
キーファイルあっても、ハッシュコードから、直接キーファイルは分からないので
ないも同然。
勿論、所持しているキーファイルの1-2)暗号化ハッシュコードを復号していた場合なら、
公開鍵は、分かってしまいます。
しかし、匿名性の本質は、暗号化の強度では決まりません。
つまり、要求ノードが「ファイル要求者」だとは、限らないということです。
- 507 名前：425 mailto:sage [2005/07/18(月) 19:06:51 ID:sTNmNfe5]
- 5.プロキシ要求コマンド 必要引数
5-1)ハッシュコード
暗号化ファイルのハッシュ値
5-2)IP/ポート交換ワンタイム公開鍵(RSA 128bit)
キーファイルの1-3)と同じ
NAT要求コマンド
ポート貸与要求、延長要求、開放要求の3つがあるが、詳しくは後述する。
6.通信体系
6-1)留意点
仕様的に、NAPTユーザーは、使用不可能になる。
まぁ、人(会社､学校)の回線を使って、P2Pするな。
自己責任でせんかい！
って、意味もあります。(どっちにしろコイツ等、吸い取り専門ですし)
6-2)キーファイル通信
キーファイルの通信は、Freenet的で、ノード間の通信は暗号化されます。
Freenetとの違いは、検索が「自然言語」である事。
「自然言語+公開鍵(のハッシュ)」の検索も可。
Freenetは、小さいファイルを扱うには、非常に優れています。
- 508 名前：425 mailto:sage [2005/07/18(月) 19:08:34 ID:sTNmNfe5]
- 6-3)暗号化ファイル通信(基本検索､基本通信)
暗号化ファイル通信の通信は、「基本通信」､「プロキシ通信」、「NAT通信」に分かれます。
まずは、基本となる「基本通信」について説明します。
基本通信は、完全な「直接通信」です。この段階では、通信が行われる2つのノード間では
匿名性もへったくれもありません。ですが、「2つのノード」以外には、通信している事は
悟られません。勿論、「2つのノード」のどちらかに悪意がある場合は別になります。
この段階では、匿名性はないに等しいことになります。
検索は、UDPポートを使った、一斉広報による検索方式です。
トラフィックが無駄に膨れ上がる恐れがありますが、上手くいけば高速な回答が予測できます。
検索方法は、まずファイル要求ノードが、現在接続されている全てのノードに検索パケットを送信する。
検索パケットを、受け取ったノードは、自分の公開領域の中から、暗号化ファイルを探します。
暗号化ファイルが存在すれば、暗号化ファイルに埋め込まれている2-3)IP/ポート交換ワンタイム秘密鍵で復号します。
復号すれば、IPと返信ポートとが分かるので、自分のIPと接続を許すポートを付加した応答パケットを『直接』送ります。
「自分のIPと接続を許すポート」は、中間ノードを通らないので暗号化する必要性はないのですが、応答パケットと、
検索パケットの区別を外部から難しくするために、あえて2-3)IP/ポート交換ワンタイム秘密鍵で暗号化して送ります。
- 509 名前：425 mailto:sage [2005/07/18(月) 19:09:17 ID:sTNmNfe5]
- これで、要求ノードは、ファイルの存在場所を知る事ができます。匿名性はないに等しいのですが、これが基本となります。
暗号化ファイルを探しなければ、余命を更新して、現在接続されている全てのノードに検索パケットを
送信する(ただし、送信元ノードには送らない)
余命をいくつ減らすかを乱数でランダムに決めますが、余命によって重み付けが変わってきます。
(この例は、適当で極端な例です)
余命 １: 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 mailto:sage [2005/07/18(月) 19:10:02 ID:sTNmNfe5]
- 6-4)暗号化ファイル通信(プロキシ通信)
普通のプロキシ通信ですが、プロキシの選び方はまったくの「デタラメ」です。
まず、接続されているノードの中から適当に、「プロキシ要求コマンド」を送信します。
プロキシ要求コマンドには、5-1)『ハッシュコード』と、5-2)『IP/ポート交換ワンタイム公開鍵』が
含まれます。
プロキシ要求コマンドを受け取ったノードは、9割の確率で、6-3)「基本検索､基本通信」に移行し、
ファイルを中継します。
のこり、1割の確率で、そのノードは、さらに接続されているノードの中から適当に、
「プロキシ要求コマンド」を送信します。
90%以下の確率で、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
99%以下の確率で、上のパターンか、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
つまり、誰が始めに「プロキシ要求コマンド」を出したかを、分かりにくくするのが目的。
中継ノードは、中継ファイルをキャッシュするが、中間ノードの役割は要求者に対するフィルタです。
ですから、キャッシュの消去は個人の自由です。
キャッシュを消去しなっかった場合、6-3)「基本検索､基本通信」で引っかかって、提供ノードに
なってくれます。
- 511 名前：425 mailto:sage [2005/07/18(月) 19:10:51 ID:sTNmNfe5]
- 6-4)暗号化ファイル通信(プロキシ通信)
普通のプロキシ通信ですが、プロキシの選び方はまったくの「デタラメ」です。
まず、接続されているノードの中から適当に、「プロキシ要求コマンド」を送信します。
プロキシ要求コマンドには、5-1)『ハッシュコード』と、5-2)『IP/ポート交換ワンタイム公開鍵』が
含まれます。
プロキシ要求コマンドを受け取ったノードは、9割の確率で、6-3)「基本検索､基本通信」に移行し、
ファイルを中継します。
のこり、1割の確率で、そのノードは、さらに接続されているノードの中から適当に、
「プロキシ要求コマンド」を送信します。
90%以下の確率で、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
99%以下の確率で、上のパターンか、
要求ノード ＝＝＝ 中継ノード ＝＝＝ 中継ノード ＝＝＝ 提供ノード
つまり、誰が始めに「プロキシ要求コマンド」を出したかを、分かりにくくするのが目的。
中継ノードは、中継ファイルをキャッシュするが、中間ノードの役割は要求者に対するフィルタです。
ですから、キャッシュの消去は個人の自由です。
キャッシュを消去しなっかった場合、6-3)「基本検索､基本通信」で引っかかって、提供ノードに
なってくれます。
- 512 名前：425 mailto:sage [2005/07/18(月) 19:13:05 ID:NWEvQOcw]
- 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 mailto:sage [2005/07/18(月) 19:13:45 ID:NWEvQOcw]
- 貸与要求したノード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 mailto:sage [2005/07/18(月) 19:14:32 ID:NWEvQOcw]
- ノード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 mailto:sage [2005/07/18(月) 19:16:58 ID:NWEvQOcw]
- つまり、ノードA からの通信は、A→B→Cとなるが、ノードCからの通信は、C→Bとなる。
こうすると、何がいいのかと言うと
(1) 高速転送
ノードA からの通信量より、ノードCからの通信量はの方が遥かに多い。
そのため、直接通信と変わらない速度が期待できる。
(2) ファイル提供者の匿名性が高い(最重要)
ファイル提供者の匿名性について考えてみると、
＊ノードAは、『あるファイル』を、ノードＢから落としているようにしか見えない。
＊ノードBは、「ノードC」と「ノードA」が通信している事は分かるが、「ノードC」が、
「ノードA」に、『どういうファイル』を送っているかは、ノードＢを中継しないので、
『物理的』に、わからない。
しかし、ノードAが「ファイル要求者」の場合、ノードCからは、モロで見えているので、
完全な通信モデル図はこうなる。
NATノード ----------------------------------┐
↑ ｌ
ｌ ｜
ｌ ↓
要求ノード ＝＝＝ 中継ノード <---------- 仮想カード ← 提供ノード
つまり、最終的には、Winnyと同程度のスピードで、クラスタ化はされないので
少々、使い勝手は悪い物になると思われます(前ほどではないが)。
- 516 名前：425 mailto:sage [2005/07/18(月) 19:18:16 ID:NWEvQOcw]
- 新手のアラシさんみたいな量になってしまった(笑
- 517 名前：525 mailto:sage [2005/07/18(月) 20:26:26 ID:UC0vJmtQ]
- なんだかよう分からんが期待しとるよ
- 518 名前：login:Penguin mailto:sage [2005/07/18(月) 22:52:22 ID:g7t80EI+]
- >>517
>>490
- 519 名前：login:Penguin mailto:sage [2005/07/19(火) 03:08:32 ID:K55Dj3jz]
- ざっとしか読んでないんで間違ってたら訂正よろ。
重要な点をまとめると
1)キーファイルにワンタイムRSA公開鍵、暗号化本体ファイルにワンタイムRSA秘密鍵を仕込んでおく。
ある暗号化本体ファイルを要求するノードは、返答先をキーファイルの公開鍵で暗号化する。
暗号化本体ファイルを持っているノードのみが、これを復号して通信できる。返答の中の保持ノードの
アクセス先は秘密鍵で暗号化され、キーファイルを持っているノードのみ復号できる。
2)キーファイルから、暗号化本体ファイルを落としたいノードは、自分のIPアドレスとポートを
ワンタイム公開鍵で暗号化し、ブロードキャストする。この本体検索要求は、TTLを仕込んでおき
転送されているうちにある程度で破棄されるようにする。
応答があれば、復号した所持ノード情報を元に直接ダウンロードする。
3)もしくは、暗号化本体ファイルのハッシュと、ワンタイム公開鍵を、隣接ノードにプロクシ転送要求をかける。
要求されたノードは、適切な確率で再転送か、2)で示したダウンロードを実行する。
4)自分のIPアドレスとあるポートを、他のノードに貸し出すこともできる。
この場合、貸し出したポートへの通信はすべて転送される。
- 520 名前：login:Penguin mailto:sage [2005/07/19(火) 03:15:47 ID:K55Dj3jz]
- ごめん。正直NATの説明がよくわからなかった。
これって実装の手間を考えたら、効果ってそんなにあるの？
NATに応じなくてもネットワーク的にペナルティないんだったら俺なら応じてやんない。
プロクシ転送要求に応じれば、自分のHDDと帯域は使われるかもしれない。
けれども、自分の出した要求が、他の人の要求の結果だという言い訳ができるし、
ひょっとしたらお宝ファイルかもという期待がある。
転送の中身見れないなら、踏み台になる意味ないじゃん。
>>500
暗号化ファイルのハッシュがわかんないと落とせないんだったら
キーファイルに書いてないと、人間言語からの検索が不可能になるのでは。
- 521 名前：425 mailto:sage [2005/07/19(火) 21:40:31 ID:mMosH/WX]
- >>519
スマソ。大体、そんな感じです。
>>520
>ごめん。正直NATの説明がよくわからなかった。
くわしくは、「StaticNAT」か「ポートフォワーディング」でぐぐってください。
>これって実装の手間を考えたら、効果ってそんなにあるの？
私もプログラマじゃないので詳しい事は言えないが、Linuxで実装するなら、
そこまで難しくないと考えられる。
ここに書いていることは、Linuxカーネルが提供するサービスを
サーバOSならば当然持っている機能を組み合わせただけです。
つまり、適当にOS呼び出して使うだけでOK(のはず)
逆に､Windowsでは、面倒かも。
- 522 名前：425 mailto:sage [2005/07/19(火) 21:45:21 ID:mMosH/WX]
- 続き・・・
>NATに応じなくてもネットワーク的にペナルティないんだったら俺なら応じてやんない。
べつに、大して重い処理じゃないし、単に転送するだけし、主にACKパケットを
中継するだけなので、帯域を犯される心配もない。ISDNでもOK(笑
ペナルティではなく、応じてくれた相手に対して報酬になるようした方が
よいのでしょうけど、今は詳しくは考えていません。
>プロクシ転送要求に応じれば、自分のHDDと帯域は使われるかもしれない。
>けれども、自分の出した要求が、他の人の要求の結果だという言い訳ができるし、
>ひょっとしたらお宝ファイルかもという期待がある。
>転送の中身見れないなら、踏み台になる意味ないじゃん。
はっきり言って、中継ノードにされることは『踏み台』にされるだけで、
何のメリットもない
(積極的にファイル供給者になると少し変わってくるが、そのことは、また今度)
お宝ファイルがあったとしても、それに対応するキーファイルが見つかる
可能性は、この仕様では薄い。
別に、『踏み台』になるかならないかは、そのノードの自由だと考えています。
ですが、『踏み台』に成らないノードに対して、誰が『踏み台』になろうと思います？
結果、そういうノードは、孤立していきます。
別にプロキシ無しでも通信可能ですし、『言論の自由』を求めない方には丁度いいのかも(w
- 523 名前：425 mailto:sage [2005/07/19(火) 21:47:03 ID:mMosH/WX]
- 続き・・・
>>500
>暗号化ファイルのハッシュがわかんないと落とせないんだったら
>キーファイルに書いてないと、人間言語からの検索が不可能になるのでは。
1-0)キーワード情報
クラスタ化に必要な自然言語パターン
↑これのことですか?
これには、色々なキーワードを、URLエンコードされた形で入れておきます。
キーワードは、アップ時に「ジャンル」と「ファイル名」のような物を要求し、
適当にアプリ側で文法解析させて、キーワード情報として入れておきます。
これで、キーファイルを「自然言語」で検索して、キーファイルに付いている
ハッシュの暗号化を、これもまたキーファイルに付いている鍵で復号して、
そのハッシュ値で、暗号化ファイルを検索します。
- 524 名前：425 mailto:sage [2005/07/19(火) 21:50:39 ID:mMosH/WX]
- 訂正: クラスタ化 → 検索
結構、書き貯めしていたので、なぜこんな間違いを書いたのかは
まったく記憶にない。
- 525 名前：login:Penguin mailto:sage [2005/07/20(水) 00:28:12 ID:IaDxISng]
- >>523
読み間違えてました。
キーファイルから暗号化本体ファイルへのリンクとなるハッシュは、ワンタイムRSA秘密鍵で
暗号化されてるのね。キーファイルに公開鍵が含まれるから解けると。
＞暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
＞つまり、「暗号化ファイル」から「キーファイル」は分からない。
ってどういう意味？暗号化ファイルを持っていれば、公開者RSA 1-4) 1-5)を除いて
キーファイルは生成できるんじゃ。
>>521
StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、
プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね)
めんどくさそうと。
プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、
インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。
そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、
他で代替可能でないのかについて、ちょっとよくわからなかった。
- 526 名前：login:Penguin mailto:sage [2005/07/20(水) 00:30:31 ID:IaDxISng]
- ちなみに。
RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ
信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。
- 527 名前：login:Penguin mailto:sage [2005/07/20(水) 00:38:55 ID:zmMtfR5C]
- NAT は Skype とかが使ってる UDP なんちゃらで解決しないのか？
- 528 名前：425 mailto:sage [2005/07/20(水) 21:48:47 ID:d8u1kb3S]
- >>525
>＞暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
>＞つまり、「暗号化ファイル」から「キーファイル」は分からない。
>ってどういう意味？暗号化ファイルを持っていれば、公開者RSA 1-4) 1-5)を除いて
>キーファイルは生成できるんじゃ。
暗号化ファイル自体は、500>>の
1-1)暗号化ファイル共通鍵
読んで字の如く、暗号化ファイルの共通鍵。
によって暗号化されており、キーファイルがなければ解読不可能です。
>＞つまり、「暗号化ファイル」から「キーファイル」は分からない。
これについては、分かりやすいモデルで説明しますと、こう言うことです。
(実際は、ちょっと違います)
- 529 名前：425 mailto:sage [2005/07/20(水) 21:51:17 ID: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 mailto:sage [2005/07/20(水) 22:38:29 ID:X6ELMDVA]
- >StaticNATについては、PCユーザは火壁の内側なユーザがかなりの数いると思うんだけど、
>プログラムから、火壁に対して設定しなければならなくなるんだけど(で理解あってるよね)
>めんどくさそうと。
まず、P2Pやるなら市販のパーソナルFWは消しときましょう。
(つうか、linux用のパーソナルFWってあるのか？)
つまり、使ってないポートは、全部斬って置いて、使うポートは、アプリ(デーモン)自体が、
アクセス制限かけないといけません。(httpdとかsendmailとかも、全部そうなってます。)
パーソナルFWは、全自動で使ってないポートは、全部斬ってくれるだけで、
他は大した事はやってくれません(FWとウイルス対策ソフトは基本的に違うモノです)。
つまり、P2Pといっても『サーバ』なので外からの、アクセスを許すことになるので、
必ず、それ相応のリスクは必ず伴います(Winnyのウイルスとか)。
まぁ、デーモンの起動ユーザをプロセスごとに複数の一般ユーザ分ければ、
実質的な被害は、あまり出ないでしょうけど。
- 531 名前：425 mailto:sage [2005/07/20(水) 22:39:39 ID:X6ELMDVA]
- >プロトコル独自の踏み台、つまり中継転送についてはプログラムの自由だと思うけど、
>インターネットとしてのポートフォワーディングを行うとなると、セキュリティ面が心配。
>そこまでの実装上の配慮を考えても、導入しなければならない機能なのか、
>他で代替可能でないのかについて、ちょっとよくわからなかった。
結論から言うと、プロキシの方が、セキュリティ面をしっかり考えなければならない。
「ポートフォワード」で、セキュリティが懸念されるのは、ネットワークの内側(LAN内)に
ネットワークの外側（インターネット）からアクセスがあるからです。
これでは、FWを付けても、その穴から突破されれば、無防備なLAN内のPCに簡単に
アクセスされてしまいます。
一方、P2Pは、「自分」と「その他」の概念しかなく、BがCに「ポートフォワード」して、
AがCにアクセスした所で、セキュリティー的には、AがCに直接アクセスするのと変わりません。
Bは、単なるルータにすぎません。
しかし、プロキシの場合、デーモンつまり、アプリ自身が提供するサービスなので、
アプリ自体に、バグがある場合、速攻で攻撃対象になります。
- 532 名前：425 mailto:sage [2005/07/20(水) 23:16:59 ID:fW484GcX]
- >ちなみに。
>RSA公開鍵ペアを誰かがこっそり書き換えて中間者攻撃されたらどうします(･∀･)ﾆﾔﾆﾔ
「RSA公開鍵ペア」はIPを交換する鍵ですよね？
「書き換える」ためには、「キーファイル」と「暗号化ファイル」の双方を所持していかないと、
書き換えられません、さらに、書き換えた「キーファイル」と「暗号化ファイル」を流通させないと
いけません。
とても、面倒で時間がかかります。そんな事しなくても「キーファイル」と「暗号化ファイル」を
もっていれば、どこの「中間ノード」と思われるノードが、「どんな」ファイルを
欲しているかは分かります。
じゃあ、何故「中間ノード」を攻撃するのか? 単にクラックが目的であれば、中間ノードなど
関係無しに、当たりかまわず攻撃しまくればいい。
つまり、結論としては、単なる「クラッカー対策」
クラッカー対策は、全てに通じるもので、P2Pに限った問題ではありません。
(それが難しいのですけどね。)
- 533 名前：425 mailto:sage [2005/07/20(水) 23:18:49 ID:fW484GcX]
- >信用を集めてから悪さしたり、結構攻撃に弱そうな気がしたんだけど大丈夫かな。
信用を集めてから、粗悪なファイルを流すということですか？
攻撃にしては、時間がかかりすぎると考えられるし、さらに信用を集めるための
ファイルは、何処から持ってくるのかという問題がある。
さらに、匿名性自体を犯す攻撃じゃありません。
結局、得するのは信用を集めている間に、ファイルを得た人々だけです。
|
 |
