Linny開発プロジェクト Part2

Linny開発プロジェク� ..

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

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

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

453:425
05/07/10 17:00:37 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
05/07/10 17:39:23 m7iyk48S
>425

ソンナメンドクサソウナモンダレガツカウ？

って言いたい所だが、オープンソースってのに既に問題があるんじゃないの？

プロトコル名に「LINNY」ってのも、どうなんだ？

オープン仕様、オープンソースならば、Windowsでもいいわけだが・・・

プロトコル名は、「Anonymous Winny」をもじって、「ANONY」に一票。

455:login:Penguin
05/07/10 18:24:15 hZ/9wEx5
「ONANY」

456:login:Penguin
05/07/10 23:06:13 pnHySe/b
まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。

457:login:Penguin
05/07/10 23:14:38 kOFHOXTv
鍵の長さって、現時点で論じるべきことなのかと思うがね。

458:login:Penguin
05/07/10 23:22:09 SZNYDAl1
最初は無暗号で徐々に暗号化を実装とかは？

459:login:Penguin
05/07/10 23:23:12 rhhJYpWd
で、コード書くやつはいるのか

460:login:Penguin
05/07/10 23:31:36 kOFHOXTv
リスクを背負う事無く安全に流通させる経路さえあれば誰か書くんじゃない？

461:425
05/07/11 01:33:11 MZK+5YtJ
>>456
>まともなファイルすら取得できなさそう。もしかしたらfreenet以下かもね。

やっぱり、そう思います？

やはり、「匿名性」と「セキュリティ」と言う相反するものを同居させるには
かなりムリがでてきますね。

この世界、あまりにOSIモデルのように、厳密で繁雑なシステムは
嫌われるので、もう少し簡略化したプロトコルが必要。

簡略化をする方法の1つは、連想鍵と言う概念を無くす方法です。つまり、
キーファイルに暗号化ファイルのハッシュ値を直接貼り付けておき、
そのハッシュ値を元に、暗号化ファイルを探す方法

詳細は抜きにして、メリット・デメリットについて。

メリット
　
　検索は高速。仕組みは簡単なので、暗号化ファイルの改ざん対策が容易

デメリット

　「暗号化ファイル」から「キーファイル」が、解かってしまう。

つまり、キーファイルがなくても、ハードディスクを没収されると、P2Pネット内から
キーファイルを落として、復号されてしまう危険性がある

「キーファイル」検索条件に制限をかけるなどの対策を取れば、ある程度OK?

プロトコル名は、>>454にあやかって「Simple ANonymous winNY」を
もじって「SANNY」なんてのを考えてみる。

462:login:Penguin
05/07/11 16:32:40 /TB8jfv9
階層がわかりにくい…だれか図示してくれ…

何に対しての匿名性を確保して、何に対しての改変耐性を確保する予定なのかを
示してもらえると、もう少しわかりやすくなるかも。

連想鍵で１階層噛ましているの理由がよくわからん。
正規の検索かければ誰でも復号できるんでしょ？
攻撃側に対する耐性になってないと思う。

463:425
05/07/11 22:29:31 iaGb8hb0
>>462
>何に対しての匿名性を確保して

「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、
「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。

「暗号化ファイル」単体では、何のファイルで何がかかれているか、
まったく不明にするコトで、完全な匿名性を実現しようとしたもの。

要は､国が本気で動いても、よく言われる「匿名の度合い」での、
「疑いの域を出ない」(Level 5)を実現しようとしたもの。

勿論、「言論の自由」のために(w

>何に対しての改変耐性を確保する予定なのか

運用しだすと、よくありそうなのは、「暗号化ファイル」を落としてみると
どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延

キーファイルだけ作りまくる輩・・・など

464:425
05/07/11 22:33:50 iaGb8hb0
>連想鍵で１階層噛ましているの理由がよくわからん。
何故こんなに煩雑なものになったのかと言うと、

キーファイル　 ⇒　暗号化ファイル　は、分かっても、
暗号化ファイル ⇒　キーファイル　は、絶対に分からなくする。

つまり、「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってはいけない。
という、前提条件があるからです。

具体的に言うと、壊れていたり、改ざんされている暗号化ファイルをネットワーク内で、蔓延させないためには、
暗号化ファイルをキャッシュしたノードは、毎回、暗号化ファイルのハッシュを行い、その値を公開する。

そして、検索者はそのハッシュ値を元に暗号化ファイルを検索し、
落とすと、壊れたり、改ざんされている暗号化ファイルは、
それ以上、蔓延することは無く消えていく。

これは、Freenetで実装されている技術です(ただし、暗号化はされていない)。

じゃあ、キーファイルに、「暗号化ファイルのハッシュ」を
直接貼り付けると、どう言う事が起こるでしょうか?

暗号化ファイルのハッシュ値は、暗号化ファイルから直ぐに分かってしまい、結果、
「キーファイル」と「暗号化ファイル」は、「同じデータ」を持ってしまっている。

で、こんなのになったワケ。

よく見ていただくと分かると思うが、「キーファイル」と「暗号化ファイル」は「同じデータ」を
一つも持っていません。(持っていますが、暗号化されていて分かりません)

ま、はっきり言って、私も､まともに動くとは思えない。（システム全体が重過ぎる
もう少し、使い勝手のいい、安易なものの方がいい。

465:login:Penguin
05/07/11 22:53:31 /qz9fPP7
URLﾘﾝｸ(s2net.s41.xrea.com)
アイデアだけはいっぱい出ているし、国内外問わず研究論文もたくさんある。
問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと
いうこともあるし
いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない
だったら誰も使わないだろう

466:login:Penguin
05/07/11 23:20:09 wBE6vaKT
> いくら理論が優れていても導入がめんどくさいとかUIがコマンドラインしか使えない
> だったら誰も使わないだろう

そこはオープンソースなんだから、UI は誰かが作ってくれるだろう。
通信部分は Winny の時に散々ループしてた dll なり so なりにすればいいじゃん。

467:425
05/07/12 02:03:25 cTi5k0J7
>>465
>問題なのは規模が大きくなったときに(検索,転送効率等が)破綻せずに動くかと

確かにいえる。ノードは、全て信用できるものであれば、簡単でしょうけど
規模が大きくなれば、なるほど信用性は薄くなる。

Winnyでも、ウイルス流れたしね。

468:login:Penguin
05/07/12 11:11:49 nQBkc+7e
> Winnyでも、ウイルス流れたしね。

どんなウィルス？

469:login:Penguin
05/07/12 13:43:43 nQBkc+7e
ん？

> ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・

なんだこれ。

470:login:Penguin
05/07/12 14:16:23 5JN9Gt1s
>>463
＞「誰」が「何のファイル」を、落としているかを「誰」にも分からなくし、
＞「誰」が「何のファイル」を、上げているのかを「誰」にも分からなくする。

「意図してダウンロードを開始した、末端ノード」に対しては、
「あるファイル(の暗号化されたもの)」であることはわかるのでは。
「意図して最初にシステムに投入した、末端ノード」に対しても
同様ではないか。

その情報がどこまで伝播してしまうか、で。
隣から見た場合、意図してダウンロードを始めたか否かで
「知っているかどうか」を知ることができるのは危険かなと。

＞どこぞの会社の宣伝だったとか、と言う「騙し」ファイルの蔓延
「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは
実際にファイルを展開できたノードにしか判定できない。
その情報を伝播させて大丈夫かな。

それとは別に、システムで検知できる改変(チェックサムが違うとか)は
これだと弾けそうだけど。

471:425
05/07/13 00:34:25 dIg+n2Qr
>「意図してダウンロードを開始した、末端ノード」に対しては、
>～中略～「知っているかどうか」を知ることができるのは危険かなと。

言っている意味が、分かりにくいので、良ければ、具体例を上げて
その危険性を、教えて欲しえてくれませんか?。

>「人間の認識するファイルの情報」と、「データそれ自体」が一致しているかどうかは
>実際にファイルを展開できたノードにしか判定できない。

キーファイルが、「信用」出来る場合を考えてみますと、

ハッシュ値、つまり「メッセージダイジェスト」は、データ情報の特徴を圧縮したもので、同じデータを
ハッシュにかければ、同じ値になるが、1バイトでも違うと、まったく違う値になります。

要は、ハッシュ値が一緒であればファイル内容も同じ(厳密に言うと、非常に低い確率で違う場合もあり)
であると言うことです。

つまり、ハッシュ値を元に検索を行えば、改ざんや破壊が起こっていないファイルを
探す事がで来ます。

そして、改ざんや破壊が起こったファイルは、参照される事無くいつしか消えていきます。

472:470
05/07/13 03:23:59 MNJFxM92
>>471
ちゃんと理解できてないんで、誤解してると思うけど。

例えば、このスレの過去ログをネットワークに投入したいとする。
投入する1次upノードは、当然内容を知っているはず。
ネットワークから、このスレの過去ログをダウンロードしようとしたノードは、
(その情報が確かなら)そのデータは過去ログであることを知っているはず。
隣接ノードに、1次upノードであること、またはダウン要求ノードであることが
(ダウン要求の内容(この場合は過去ログであること)も含めて)ばれてしまうことは、
例えどんな暗号化がされていようとも、内容を知った上で送受信しているという事になる。
これは、このスレの過去ログが発禁扱いになっていて、政府が監視中であるなら
危険なことだと思う。言論の自由を目指すんだしw

ダウン要求の内容がばれてしまうことは、ある要求をシステムでの要求に変えることと等価である。
あるファイルが落とせるってことは、投入側と取得側でなんらかの同意がいるってことでしょ。
取得するのと同じやり方で、取得方法だけ持っておいて、ネットワークを流れる要求を
監視されたらやばいんでないの、という意味。

当然中継ノードなら、内容は知らずに、P2Pネットワークとしての責務として
ただ踏み台にされただけだから、(現時点の世界では)こういう心配はしなくていいのでは、と。

473:470
05/07/13 03:32:35 MNJFxM92
＞後段
キーファイルが信頼できるかどうかがそもそもやばいんで内科医ということ。
プロトコル的に、データが改変損傷してないのは保障するとして、
例でいうところの、このスレの過去ログではなく、Winny本スレの過去ログがおちてくる場合
そのキーファイルやら暗号化データはどうするのってこと。
そういうことする香具師はたくさんいるし、ミスってそうなることもあるよ。

内容知っている人にしかネットワークの暗号データは評価できないんだけど、どうやって排除すべきか。
内容が合ってるかどうかを流すことのできるノードも、情報を知っていることになって監視対象入りかも。

そういうことも含めて、誰が何の情報を知っていて、何の情報を知っていることになっていて
隠すべきものは何かな、と考えてたらよくわからなくなってしまって聞いたんだけど。

474:425
05/07/13 15:46:02 OdrjvaIG
このシステムは、Winnyと言うより、Freenet的だったので、
さまざまな部分で、効率が悪い。

今度は、Winnyベースの高速な匿名性ファイル共有で、特にファイル提供者の
匿名性が非常に高い物を思いついたので、まとまり次第うｐします。

(キーファイルと暗号化ファイルに分けるという点は変わりません。)

>>472
　このシステムにおいて、Freenetのような、アップデートの概念はありません。
　あるのは、「検索」と「ダウンロード」だけです。

　まず、「あるファイル」を自分の公開領域に置き、その存在をネットワークに知らせます、
　知らせる、といっても、「ここにあるよ」と言ったら、匿名性もへったくれもないので、
　ネットワークに、そのファイルの「検索クエリ」を送信します。

　そして、その検索クエリは、高い確率で自分のノードに戻ってきます。
　その時、自分自身で返事を返してやれば、誰にも悟られずに、そのファイルを
　ネットワークのクラスタに追加できます。

　しかし、キーファイルのような軽いファイルであれば問題ないが、重いファイルの場合、
　Freenet同様問題がでてくるので、根本的な見直しが必要

475:425
05/07/13 15:54:48 OdrjvaIG
>>473
　まぁ、人間ミスするのでそれは、大した問題ではないと思う(笑
　そう言うのは、排除する必要もないんじゃ?

　問題になってくるのは、例えば『ダイエット本』で検索した時、『ダイエット本』に
　関係するキーファイルが落とされます。

　しかし、『ダイエット本』と書きながら、暗号化ファイルを落として復号してみたら、
　何故か『サラ金の広告』だった場合は問題です。

　このための公開鍵です。要は、公開鍵はIDです。信用できないIDは、信用しなければいいだけです。
　（その公開鍵であれば、無条件で消す）

　そして、このような信用できない公開鍵があれば、信用できる公開鍵も存在するはずです。

　公開鍵は、一種のIDです。ならば、信用性のある公開鍵の「なりかわり」の心配はないか?

　それは、公開鍵に対する秘密鍵が分からない限り、不可能です。

476:login:Penguin
05/07/13 18:17:25 4rsiUBe0
で、いつごろまで屁理屈こねくりまわすの？

477:login:Penguin
05/07/13 18:28:32 +oLOISW/
おまえがしびれを切らして愚痴るまで。
つまりあともう少しだな。

478:login:Penguin
05/07/13 20:32:46 MNJFxM92
>>474
Freenetよか遅いのは考える意味がないw
この案はこの辺りが潮時か…

＞｢検索クエリ｣
この送受信を傍受されたらどうするのって言ってるんだが。

＞公開鍵
信用できる鍵にあたるまでがんばれってか。
攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。
>>445　で指摘されてるように、固定は危険だし。

479:login:Penguin
05/07/13 20:59:14 4rsiUBe0
>>477
すでに愚痴ってるわけだが。

480:425
05/07/14 16:51:28 5jVfH12S
>>478
>Freenetよか遅いのは考える意味がないw
　私もそう思います。ですが、キーファイルの通信は非常に軽いので
　そのあたりで使えると思っています。

>この案はこの辺りが潮時か…
　一応、暗号化ファイルの通信を独立させた、次の案があるので、
　もう、暫く付き合っていただけませんか?

>この送受信を傍受されたらどうするのって言ってるんだが。
　通信を暗号化したレイヤでトンネリング(SSLっぽいの)すれば、外部からのチャプチャリングは、
　シャットアウトできます。

　内部ノードは、自分の上位ノードと下位ノードのことしか、分からないので、
　どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。

481:425
05/07/14 16:52:55 5jVfH12S
・・・続き

>信用できる鍵にあたるまでがんばれってか。

　むしろ、信用できる鍵の方が多くなると私は考えています。

　RSA2048bit公開鍵の鍵セットを作るには、どんなに強力なマシンでも
　かなり時間を喰らうのにくらべ、「除外(一切受け付けない)」のは一瞬で終わる。

　「攻撃者」が、鍵セットを作り続けたとしても、どっちが不利かといえば、
　圧倒的に「攻撃者」が不利。

　かといって、「攻撃者」は、「他の公開鍵」に成り代わろうとしても、
　相手の「秘密鍵」を、知らなければいけない。

　その「攻撃者」が、RSA2048bitをクラックできるとしたら、ネットバンキングは
　とっくの昔に破綻しています。

　ならば、そんな馬鹿な事を実際にする香具師は、殆ど現れないはずです。

482:425
05/07/14 16:54:57 5jVfH12S
>攻撃側は信用できない鍵をばら撒くんだから、どうやって区別するんだと。

　上記の理由で、「なりかわり」は、理論上できません。
　となれば、「同じ鍵」であれば「同一人物」です。

　要は、「あなたは、何を基準に『人』を信用しますか？」ということです。

　　少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は
　　「信用できない」

　　5回連続で、きちんとした暗号化ファイルが存在するキーファイルの鍵は、ある程度は、
　　「信用できる」

　って、ことです。

　上記のような簡単な判断は、アプリ側に任せていいと思います。
　あと、公開鍵の情報を保存しておく必要もあります。

>>445　で指摘されてるように、固定は危険だし。

外部からの、キャブチャリングは暗号化してしまえば、不可能です。
内部ノードは、上位ノードと下位ノードの事しか知りません。

その状況で、「公開鍵」の発信元を調べるのは、非常に困難を極めます。

「公開鍵」の発信元を調べるスピードよりも、ファイルが拡がるスピードの方が
圧倒的に速いからです。

一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。

483:login:Penguin
05/07/14 17:31:19 D9NFH06e
で、何%までできた？。机上の空論もいいけど、コード書いて実装できなきゃ
意味ないぞｗ

484:login:Penguin
05/07/14 17:39:02 TU8gjza9
よし、使用言語はObj-Cで決まり。

485:login:Penguin
05/07/14 18:27:54 +fLeQjmb
>>482
> 　　少なくとも、3回連続で、暗号化ファイルが存在しない悪質なキーファイルの鍵は
> 　　「信用できない」

これだと単純すぎると思う。
暗号化ファイルはちゃんと存在するけど、内容が期待したのと違うっていうような攻撃が来るんじゃないかな。

こういう攻撃だと、除外する側は暗号化ファイルを受信して、内容を調べて判断しなきゃいけない。
鍵を作る手間に比べて、受信した内容を確認・判断する手間って、むしろ大きいんじゃないかな。
期待通りのファイルかどうかを判断するのは、自動化が難しい問題だろうし。

486:login:Penguin
05/07/14 20:11:14 PKmLnshm
実際にコード書いて検証すればいいだけだのに、
どうして机上の空論を書くのに精を出しているのだろう。

487:login:Penguin
05/07/14 21:13:19 E+/HEPIn
しびれを切らして愚痴りだした香具師がいるなｗ
机上の空論、大いに結構。

488:login:Penguin
05/07/14 21:20:30 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
05/07/14 21:35:52 ey7oBSjc
425は机上の空論の妄想野郎。

>>433で本人が認めてるし。こいつ自身は実装やる能力がない。
そんな、脳ナシに標準化なんか出来るか。Freenetに任せとけ。

490:login:Penguin
05/07/14 23:14:16 HLeFWI2x
わからんかなぁ

ほら、あれと同じ雰囲気を楽しむスレなんだよここは。
居酒屋や串焼き屋でだ、仲間内で出来もしない事を熱く議論することがあるだろ。
そういう空気が好きなんだよ俺等

491:login:Penguin
05/07/14 23:26:53 PKmLnshm
釣り堀スレか。

492:きたろう
05/07/14 23:38:17 3X5YI5cJ
常に欲求不満でイライラしている。
自分の能力に劣等感を持っている。
出る杭は徹底的に叩かないと気が済まない。

そんなネガティブな感情に流されてる暇人の存在を感じます、父さん！

493:login:Penguin
05/07/16 03:35:55 qxGyOozH
>>486
実際に手を動かせるくらいできてればこんなところで考える前に
ダウソで"ちょっとまちなー"ができるって。
システムが中途半端だとコーディングする意味ないし。

>>480
＞通信の傍受
外部からの、ではなく、内部からのってこと。
つまり(正規の動作をある程度行う)スパイノードの存在は大丈夫かなと思って。
＞どのような経路を辿って「検索クエリ」が来たのかは、一切分かりません。
検索システムがどのように予定されてるのかはわからないけど。
例えばクエリが帰ってくるようにリターンアドレスを入れておくような実装だと、
「誰が」リクエストを出したのかがばれてしまう、というような情報漏れを心配している。

＞一旦ファイルが拡がってしまえば、誰が発信元かなんて、絶対に分かりません。
1次Upノードが特に危険だと思うんだが。
Shareとかは強制拡散してるみたいだし、Freenetとかはバッファにプッシュして
所持ノードの概念がなくなるみたいだし、いろいろ工夫してると思う。
Winnyは、何もしない、という戦略をとったが。

494:425
05/07/16 23:10:58 jAChWphq
新案をコトコト煮詰めています。

暗号化ファイルは、StaticNATを使った面白いネットワーク偽装を
考えています。

>>493
キーファイルの共有は、完全なFreenetスタイルを考えています。
つまり探索とかもいっしょ、大量のノードが協力しない限り、
要求者を求めるのは難しい。

>1次Upノードが特に危険だと思うんだが。

「自分自身」で「自分自身しか持っていないファイル」を探索するクエリを、
隣のノードに送信すると、どうなると思います？

Freenetでは、経路上に多くのループが発生します。

つまり、必ず探索クエリは、自分自身に戻ってきます。

そこで、アップロードしながらダウンロードしたらどうなるでしょうか?
自分の下位ノードは、自分がそのファイルを中継しているか、アップしている
かは分かっても、誰がその要求を出しているのか分かりません。

逆に、上位ノードは、自分がそのファイルを中継しているか、要求している
かはわかっても、そのファイルが何処から流れてきているのかわかりません。

そして、途中経路では「複製」が出来ます。

つまり、1次Upノードは、誰にも悟られる事なくネットワーク上にファイルの
複製を作れます。

つまり、これで誰が1次Upノードかは謎になる。

495:login:Penguin
05/07/17 00:28:28 iMIptb/B
ほんとにできてるの？何％くらい

496:login:Penguin
05/07/17 01:26:26 ksRYqrdf
>>495
>>489

497:login:Penguin
05/07/17 09:10:57 3e1zqbRW
>>495-496
早漏は損だよ

498:login:Penguin
05/07/17 17:36:40 hmmV4Rhb
>>494
＞1次Upノード保護
経路のループを利用して自己偽装Down要求ってことですな。

＞Freenetでは、経路上に多くのループが発生します。
＞つまり、必ず探索クエリは、自分自身に戻ってきます。
このループはある程度大きくないと効果が期待できないと思うんですが、
あまり大きいと、中継転送による速度の低下が心配されると思いますが
バランスとかはどうなるでしょうか。
確実にクエリが戻ってくることは期待して大丈夫ですかね。
繋ぎ変えがおこるネットワークならば、ループが切れたりしないかな。

＞ネットワーク偽装
期待してます。よろ。

499:425
05/07/18 18:56:18 juv970X8
「HannyNet（Hashing anonymous winny Network）」案

ちょっとは、まとまった思うので書いてみる。

「HoneyNet」(行動の一部始終を監視できるように設計されたネットワーク)の
真逆を逝っているので、何となくつけてみたくなった。

匿名性の重要度

　ファイル提供者　>> ファイル要求者

　ファイル提供者の匿名性は最優先される。

　なぜなら、「提供する者」がいなくなれば、
「共有」は存在しえないからである。

　つまり、ファイルを提供すればするほど、匿名性の保障に優位に立つことができて、逆に、
吸いとるだけの輩は、匿名性を保障しないようにシステム全体が推移するような仕組みが
望ましい。

500:425
05/07/18 18:57:13 juv970X8
ファイル構成

1.キーファイル（テキスト形式）
　
　　1-0)キーワード情報
　　　　クラスタ化に必要な自然言語パターン

　　1-1)暗号化ファイル共通鍵
　　　　読んで字の如く、暗号化ファイルの共通鍵。

　　1-2)暗号化ハッシュコード　　　　
　　　　2-1)のハッシュコードを、1-3)の秘密鍵で、暗号化したもの。
　　　　(べつに、1-1)で暗号化しても問題ない。)
　　　　意味がないように思えるが、非常に意味がある。

　　　　暗号を解かなければ、暗号化ファイルのハッシュコードは分からない。
　　　　つまり、「暗号化ファイル」から「キーファイル」は分からない。

　　1-3)IP/ポート交換ワンタイム公開鍵(RSA 128bit)
　　　　IPとポート番号を申請するときに使う。
　　　　詳しくは、後述。

501:425
05/07/18 18:58:06 juv970X8
1-4)公開鍵(RSA 2048bit)
　　　　1-5)の公開鍵。　　

　　1-5)電子署名
　　　　1)～4)の電子署名。こうした方が、たぶん都合がいい。

　　1-6)1-4)のハッシュコード
　　　　ノードにキャッシュされる度、随時上書きされる。

　　　　キーファイルの検索では、同時に公開鍵の参照も許しているが、
　　　　256バイトのデータを毎回参照していたのでは、ノードに対する
　　　　負担が大きい。

　　　　そこで、ハッシュを用いて大まかに検索して送信する。そして、
　　　　最終的な判断は、検索クエリを出したノード自体に委譲する。

　　　　ここで、使うハッシュ関数は、MD5やMD4のように厳密なものではなく
　　　　計算量が、非常に軽いものが望ましい。固定ビット長なので、上手い
　　　　方法があるはずです。

502:425
05/07/18 18:59:12 juv970X8
2.暗号化ファイル（バイナリ形式）

　　2-1)ハッシュコード
　　　　2-2),2-3)のファイルの内容をハッシュにかけた値(MD5)
　　　　要は、ファイル名。

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

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

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

503:425
05/07/18 19:00:32 juv970X8
3.通信ポート
　　
　　3-1)管理ポート(TCP)　
　　ポート番号：　インストール時に決定
　　　　
　　　　主に､キーファイルの検索/受け渡しをする。

　　　　暗号化ファイルのプロキシ要求(後述)や、NAT要求(後述)もこのポートで行う。
　　　　この通信は、暗号化される。

　　　　要は、コマンドもファイルも一緒に送り、暗号化の手間を軽減する。

　　　　処理の優先度は、

　　　　NAT要求 > 検索クエリ > キーファイルの送受信 > プロキシ要求　　　　

3-2)暗号化ファイル検索ポート(UDP)
ポート番号：　インストール時に決定

3-1)の通信でコネクションが張られていないIPからの要求は、
　　　　全て遮断することとする(応答は受け入れる)。

　　　　この通信は暗号化されない。

504:425
05/07/18 19:01:18 juv970X8
　　3-3)暗号化ファイル転送ポート(TCP)
　　　　ポート番号：随時決定

　　　　特に説明ナシ。この通信も暗号化されない。

　　3-4)ICMPエコー要求(ICMP)
　　　　イワユル、「ping」コマンドで、セキュリティ上は切っておいた方が望ましいが、
　　　　相手のマシンが、起動しているかどうかを調べるのに最も楽な方法。

　　　　TCPコネクションを確立させる前にpingを送れば、余計なSYNパケットを出さなくてすむ。

505:425
05/07/18 19:02:07 juv970X8
コマンド・パケットフォーマットなど

今の段階では適当。とりあえず、決まっている物から
　(所詮、暇人の考える程度の事ですから)

4.暗号化ファイル検索パケット(UDP通信)

　　4-1)余命(8bit)
　　　　そのパケットのが後、どれ位生きれるのかを示す。1つノードを通過すると、
　　　　年をとって余命が減るかもしれない。また、減らないかもしれないし、
　　　　一気に老けてしまうかもしれない(要は適当に決まる)。

　　　　勿論、0になった地点で死にます。

4-2)乱数(24bit)
　　　　通信を区別するために、適当な乱数を設ける。

　　4-3)ハッシュコード(128bit)　
　　　　暗号化ファイルのハッシュ値

次ページ