- 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のアカウントを取得してください。
- 369 名前：login:Penguin mailto:sage [05/03/14 05:37:26 ID:0YyTOLGz]
- >>368
47氏にでも依頼するのかい？
Linux版とかは作る気はない、とか言ってた気がするけど。
- 370 名前：login:Penguin mailto:sage [05/03/15 15:43:32 ID:fvSF73Mo]
- 厨房避けに最適なのに
- 371 名前：login:Penguin mailto:sage [2005/03/22(火) 20:38:19 ID:yam08RNP]
- wikiは見れなくなっているのだな
- 372 名前：login:Penguin mailto:sage [2005/04/10(日) 14:23:26 ID:Qg6Yp9sw]
- Winnyをソース化しよう
tmp4.2ch.net/test/read.cgi/download/1071258282/
ここか。
- 373 名前：login:Penguin mailto:sage [2005/04/19(火) 20:18:53 ID:QwGOconk]
- >>369
オープンソースで成り立てばLinux版も可能といっていた。
- 374 名前：login:Penguin mailto:sage [2005/04/19(火) 20:28:15 ID:iza5jbtz]
- 要は暗号化と匿名化するのにソース非公開の方法しか
思い浮かばなかったんでしょ？
暗号化はともかく、
匿名をオープンソースで実現することは可能なんだろうか。
- 375 名前：login:Penguin mailto:sage [2005/04/20(水) 00:08:19 ID:1AqW0Nsw]
- 暗号化も匿名化も出来る(っていうか暗号化は匿名化の手段でもある)が、
クラック避けが難しいって事じゃなかったかな>オープンソース化
- 376 名前：login:Penguin mailto:sage [2005/04/20(水) 00:42:36 ID:8LKPMmt8]
- ソース公開の匿名化はFreenetが(ry
- 377 名前：login:Penguin mailto:sage [2005/04/20(水) 10:38:18 ID:kXbvBhdm]
- ソース改変しても
相手の IP とか探ることはできないようになってるの？
- 378 名前：login:Penguin mailto:sage [2005/04/20(水) 14:52:19 ID:eT3XmLKY]
- >>377
おまいさん、通信相手のIPアドレスがわからずにどうやってTCP/IPの通信をするつもりだい
重要なことは、誰が何を公開しようとしたかがわからないことであって、
誰が何のデータを持っているかは(プロクシ動作のために)意味を持たないと思う。
- 379 名前：login:Penguin mailto:sage [2005/04/23(土) 11:56:45 ID:wBX6QwFp]
- >>377
nyの一番重要なところは、プロクシ動作であり、流れるデータが常にキャッシュされるところ、
そのためキャッシュだけを見た時に、データが単にプロクシ動作のためにキャッシュされたものなのか、
直接的にアップしたものなのかわからない。
だから、相手が何を流してきたか？、何て事は全く意味を持たなくなる。
そのデータは相手が直接流したものなのか？単なるプロクシ動作によるキャッシュなのか？
それがわからないからだ。
もし、キャッシュに違法なデータが含まれていたとしても、法的に立件することは難しい。
なぜならば、キャッシュ動作を否定することは、ネット自体を否定することになるから。
ネット自体、データを途中にあるルータや鯖にキャッシュしながら通信が成り立っている。
そのキャッシュの中には法に触れるデータも含まれるであろう。
つまり、nyの動作はインターネットそのものであり、nyの動作を否定することは、
ネットそのものを否定することになる。
だから自分のPCのキャッシュに違法なデータが含まれていたとしても、
それだけで捕まえることは無理なのだ。
47氏はただ単に通信の手段を与えたにすぎず、nyの開発をしただけでの逮捕は違法といえる。
しかしなぜ逮捕できたか？それは47氏が著作権を崩壊させるのが目的であると、
nyの開発動機を語っていたから。つまり苦し紛れの理由で無理矢理
ﾀｲ━━━━||Φ|(|ﾟ|∀|ﾟ|)|Φ||━━━━ﾎ!!
相手のIPや通信経路が分かったところで、それが無意味だって事が
わかったかい？>>377
- 380 名前：login:Penguin mailto:sage [2005/04/23(土) 14:09:15 ID:szBMljw1]
- >>379
あんた弁護士かい？
47はキャッシュ動作(Upload)の違法性を認識しており、自分用にはDownload Onlyの
クライアントを作成していたと言われているが、その件についてはどうかな？
- 381 名前：login:Penguin mailto:sage [2005/04/23(土) 14:38:53 ID:mU74wke+]
- 犯罪に使われる可能性のある道具というのはいっぱいあるよね。包丁とか銃とか。
さらにほとんど犯罪にしか使われない道具もある。ピッキングツールとか。
犯罪にしか使われないソフトウェアというとクラッキングツールが
そうだけど、そこら辺はどうなるんだろうね。
- 382 名前：login:Penguin mailto:sage [2005/04/23(土) 15:14:04 ID:wBX6QwFp]
- >>381
そう、結局はそこが曖昧なままなのが問題。
犯罪に使われる「可能性」のある道具を作るのが違法ならば
インターネット自体が違法になりうるし、携帯電話だってなんだって当てはまってしまう。
最後には何も作ることが出来なくなる。
道具は使いようだからね。
>>380
つまりはキャッシュ動作の違法性も曖昧なままだ。
DLオンリーのクライアントがあったとしても、
47氏がキャッシュ動作が違法であると認識して作成したとは言えない。
それに、DLオンリーのクライアントを作成する理由は、他にいくらでもある。
本当にそんなクライアントがあったのかは知らないが・・
そもそも47氏がそんなもの使って一生懸命DLしてたと思えない。
やりたいことありすぎて時間もないだろうしな。
どっちにしても本人に直接聞かないことには推測の域は出ないので不毛。
つうか、別に違法性がどうのこうの言うつもりはなかったんだが・・・
ただ単に377があまりnyについて理解がなさ過ぎなのでレスしてみただけ。
- 383 名前：login:Penguin mailto:sage [2005/04/24(日) 03:33:43 ID:U52lbyvj]
- >>380
意図的に1次Upノードになることは公衆送信可能化権の侵害になることは明らかだが、
意図しない中継動作による2次以上のUpノードは明確には違法とはいえないのでは。
ただし、1次Upノードを、多数の中継Upノードの中に隠してしまうと、警察の捜査が
困難になることは認識していたと思われ。その意思が違法かどうかは微妙だが。
DownOnlyのノードがあったとしても、改造によるネットワークへの影響を調べていた
という言い訳ができたりもする。
- 384 名前：login:Penguin mailto:sage [2005/04/26(火) 22:27:04 ID:b+Bgg3SS]
- っていうか中継動作が違法になるんなら、海外のエロページが見える国内のゲートウェイは全部違法だろ。
- 385 名前：login:Penguin mailto:sage [2005/05/06(金) 00:25:53 ID:fBpY2R2q]
- 中継動作をもって、それは合法ともいえないでしょ。しかも、中継動作なんて本質の部分ではないし。
「nyの否定」=[ネットの否定」ってのもぶっ飛びすぎでしょ。
47の目的は実験かもしれないけど、一般公開の実験にしては危険側によりすぎていると思うね。
- 386 名前：login:Penguin mailto:sage [2005/05/06(金) 10:42:22 ID:yIkyZYFZ]
- でも端から見てておもしろい実験だったよ。
- 387 名前：login:Penguin mailto:sage [2005/05/06(金) 20:51:18 ID:NC7j+KH8]
- >>385
つうかさ、それを言ったら、包丁作ったら逮捕。
みたいなのはどうなのよ。ぶっ飛んでませんか？
- 388 名前：login:Penguin mailto:sage [2005/05/06(金) 22:15:02 ID:+qWs8XmI]
- Winnyでネギは切れそうもないので包丁は関係無いと思う。
- 389 名前：login:Penguin mailto:sage [2005/05/06(金) 23:09:51 ID:fBpY2R2q]
- >>388
激しく同意。
- 390 名前：login:Penguin mailto:sage [2005/05/07(土) 02:06:55 ID:VV46m7bs]
- >>388-389
お前ら・・・・ほんとに頭悪いんだな・・
- 391 名前：login:Penguin mailto:sage [2005/05/07(土) 09:12:45 ID:N9jtnJjA]
- 包丁いっぱい作って無料で配りまくるのと似てるかも。
- 392 名前：login:Penguin mailto:sage [2005/05/07(土) 09:14:17 ID:wZZgaFg6]
- たとえ話は脱線しがちだからほどほどに。
- 393 名前：login:Penguin mailto:sage [2005/05/07(土) 10:07:08 ID:i/BfrLdB]
- サリンを誰にでも使えるようにして、俺は使ってないから無罪といいはるのと同様かと。
- 394 名前：login:Penguin mailto:sage [2005/05/07(土) 11:03:45 ID:T+EVrL8z]
- サリンって使い道あるの？
包丁はちゃんとした使い道あるけど。
つまりnyもちゃんと使い方があって、それをちゃんと証明できるなら…
- 395 名前：login:Penguin mailto:sage [2005/05/07(土) 13:06:54 ID:tx50SVHK]
- 自作ポエ（
- 396 名前：login:Penguin mailto:sage [2005/05/07(土) 16:32:40 ID:XnmIFUld]
- ブロードバンド時代に、プロバイダのバックボーンが耐えられるかの負荷テスト(ry
- 397 名前：login:Penguin mailto:sage [2005/05/07(土) 16:38:29 ID:hgkPuTxN]
- >>396
おまいは、厨房ともちゃでつか？
- 398 名前：login:Penguin mailto:sage [2005/05/16(月) 22:51:09 ID:HnJ5Ynpd]
- ダウソ板で開発宣言したのがまずかったのかな。
- 399 名前：login:Penguin [2005/06/22(水) 20:48:18 ID:GGpxtaXf]
- 保守
- 400 名前：login:Penguin mailto:sage [2005/06/22(水) 22:57:54 ID:rSsOc9Il]
- 包丁でサリンを切るスレはここですか
- 401 名前：login:Penguin [2005/06/23(木) 14:56:46 ID:bF+VLH9U]
- Linny マンセー
早く作れ！
- 402 名前：login:Penguin mailto:sage [2005/06/23(木) 18:40:29 ID:eVPle0x9]
- >>401
言いだしっぺ（ｒｙ
- 403 名前：login:Penguin mailto:sage [2005/06/28(火) 00:02:34 ID:/QQcXqnr]
- すごく出来が悪かろうと、公開さえしてくれれば
2ｃｈとしては反応がすごいのにな〜需要はあるだけに
どなたか挑戦してみない？
- 404 名前：login:Penguin mailto:sage [2005/06/28(火) 00:37:58 ID:sxypLrzh]
- >>403
開発したら何か得するの？
- 405 名前：login:Penguin mailto:sage [2005/06/28(火) 01:12:49 ID:Woj5she8]
- >>404
いや、別に・・
需要ってあるよね
- 406 名前：login:Penguin mailto:sage [2005/06/28(火) 01:35:17 ID:sxypLrzh]
- >>405
ちゃんと市場調査してくれよな。
- 407 名前：login:Penguin mailto:sage [2005/06/28(火) 01:39:16 ID:eyx1+LDG]
- やはりこういうソフトはプロジェクトじゃなくて、
社会的にアレなはみだしプログラマが、社会への恨みつらみを糧に
夜な夜なせっせと書き上げて、2chで無造作にバイナリのみ公開。
自分だけ吸い上げ専用バージョンを用意してｳﾏｰ、というのが収まりが良い。
- 408 名前：login:Penguin mailto:sage [2005/06/28(火) 01:40:30 ID:sxypLrzh]
- >>407
根拠きぼんぬ。
- 409 名前：login:Penguin mailto:sage [2005/06/28(火) 01:41:30 ID:n+gd5yH6]
- やっぱオープンソースだろ
- 410 名前：login:Penguin mailto:sage [2005/06/28(火) 16:33:52 ID:9XnSpYyO]
- >>407
アレな人は多いけど、技術と執念がないんだな
- 411 名前：login:Penguin mailto:sage [2005/06/28(火) 17:47:11 ID:sxypLrzh]
- >>410
ご自分のことでつか？
- 412 名前：login:Penguin mailto:sage [2005/06/28(火) 20:43:23 ID:yfr2aRZu]
- オープンソースでも完全に成り立つ仕組みを考えればそれだけでも
このスレの名は売れるだろう。
WinnyにしてもShareにしても暗号鍵をバイナリに埋め込むことで
保護している。ここの部分を何とかしないとオープンソースでは難しいだろう。
- 413 名前：login:Penguin mailto:sage [2005/06/28(火) 20:46:35 ID:n+gd5yH6]
- いっそ暗号化部分だけ切り離してしまって、バイナリだけの動的モジュールにしたら？
- 414 名前：login:Penguin mailto:sage [2005/06/28(火) 20:51:09 ID:yfr2aRZu]
- それじゃあつまらなくない？
クラスタワードを鍵にするのも考えてみたけど、あんまりよくないね。
- 415 名前：login:Penguin mailto:sage [2005/06/28(火) 23:59:23 ID:n+gd5yH6]
- ちとつまらないかもしれませんね。
とりあえず俺はアホだが色々書籍を読み漁る予定。
- 416 名前：login:Penguin mailto:sage [2005/06/29(水) 03:11:34 ID:HU+dn+SH]
- >>413
隠すことによるセキュリティーは長続きしない。
根本的に、オープンでやっても維持できるシステムを構築すべき。
今までに出ているのは、ノードごとの相互監視をプロテクトにする案。
ちゃんとデータのやり取りをしているノード以外をネットワークから弾いてしまう、と。
末端同士のデータのやり取りの内容を隠す暗号化は、気分的なものと
中間ルータでキャプチャを簡単にはできなくするためだけであって、システムに
本質的に必要なものとは思わない。
Winnyのミソは、自分の保持データは、望んだものか中継なのかがわからず
機械的なプロクシとしての免責を企んでいる点。
- 417 名前：login:Penguin mailto:sage [2005/06/29(水) 03:22:47 ID:pkrk1XKs]
- ちゅーかx86がターゲットの時点でディスアセンブラで解析されるんだから。
- 418 名前：login:Penguin mailto:sage [2005/06/30(木) 21:18:29 ID:70M3Hd0P]
- Linnyのノードは完全に平等な権利をもたない。
- 419 名前：login:Penguin mailto:sage [2005/07/03(日) 15:06:07 ID:IZCijWVL]
- プログラマーとしてはダメダメだが、思いついたことを書いてみる。
ttp://www.itmedia.co.jp/lifestyle/articles/0402/26/news078.html
とかをまとめて見ると
要は、トラフィック解析した時に分かる「Winnyパケット」の「振る舞い」が、
問題になる。その「振る舞い」によって、らしきパケットは限定されてしまう
１．無効なSYNパケットが多い
２．特定サイズの暗号化通信が連続する
そして、限定されたパケットの中から詳細に分析しているのである。
1．の原因は恐らく、通信しようとした時にPCの電源が切られていることが多いから。
２．の原因は恐らく「TCPの仕様」が原因である。と言うのも、大きなデータを
転送する際は、ネットワークを効率的に利用するためにMSSの最大レートで、
送られるパケットが大量に出るため、『不明なポート』から『不明なポート』へ
「不明なデータ」が大量に、「あるホスト」から「あるホストに」流れている事は
すぐに分かる。現在の仕様では、どんなに頑張ってもトラフィックを観察されると
ある程度,ファイルの流れはバレてしまう。(freenetでも同様)
- 420 名前：login:Penguin mailto:sage [2005/07/03(日) 15:07:28 ID:IZCijWVL]
- １．の解決方法
TCP接続前にUDPを使って、応答を待つ方法
TCP接続前にPingを使って、応答を待つ方法も考えられるが、
受信者が、Pingを切っている可能性もある。
しかし、特定のUDPパケットにICMP到達不能メッセージが多いと
結局イタチごっこになる。
そのため、ポート番号をUDP接続が成功するたびに、次回の接続を
変えてやる必要がある。
２．の解決方法
UDPで新たな、ネットワーク層を偽装するトランスポート層を作成する。
つまり、「送信元IP」を偽装するのです。
できるようになれば、freenetより外部からの匿名性は高くなるが、
資源を思いっきり喰らう、ICMPメッセージは届かなくなる、
NAPTユーザは使えないなどの欠点がある。
考えられるアルゴリズムを、書いてみる。
- 421 名前：login:Penguin mailto:sage [2005/07/03(日) 15:08:56 ID: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 mailto:sage [2005/07/03(日) 15:20:01 ID: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 mailto:sage [2005/07/03(日) 15:46:30 ID:IZCijWVL]
- 上記の理由より、外部からの匿名性は高くなるが、
内部の「悪意あるノード」に対しては、対処出来ない。
むしろ、内部からの攻撃には非常に脆いと考えられる。
「認証」を、どのようにするか？コレが問題
- 424 名前：login:Penguin mailto:sage [2005/07/03(日) 18:51:41 ID:I4l1Sle2]
- 結局、プロバイダに対して偽装をするとなると、インターネットoverインターネットを
構築することになって激しく面倒。
どっちみち、むこうさんから見れば激しいUpトラフィックを打ち落とせばいいだけだし。
確か、ノードにIDを振り、自分以外の誰にもIPアドレスとの対応を明かさないで、
バケツリレーでたまたま自分のところにきたものを黙って受け取る、とかいうルーティングしてた
P2Pソフトがあったと思われ。
muteだったはず。蟻がどうのこうののルーティング手法らしい。
- 425 名前：login:Penguin mailto:sage [2005/07/05(火) 23:27:28 ID:3m7vbi8S]
- 現在のWinnyを鍵と暗号化ファイルを別々に管理できる仕様、つまり、
暗号化ファイルだけダウンロード、鍵だけダウンロードできる仕様にする。
このとき、暗号化ファイルのファイル名などから、鍵を連想して、P2Pネット内から、検索、
鍵をダウンロード出来ないようにする。
『鍵』をハッシュにかけた値を暗号化ファイルのファイル名にするのが妥当だろうか?
つまり、意味のある「キーワード検索」で引っかかるのは、鍵だけにする。
そして、鍵を落としたら、鍵をハッシュにかけて、再び検索クエリを流す。
理論的に、暗号化ファイルから、鍵を連想して、P2Pネット内から鍵を
落とす事は不可能になる。
鍵のキャッシュ保管用ディレクトリを、ハードディスクに物理的に1MBのパーミッションを
設定する。
ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・
一瞬で終わるぞ・・・・(w
そして、暗号化ファイルは論理的に「闇」に葬られる。
その後、暗号化ファイルは、まったく意味を成さないかと言うとそうでもない。
自分自身が、再び落としてくるファイルの中にキャッシュに含まれるファイルを
落とす可能性が高いからである。
鍵を落とすだけであれば、殆ど時間は要らないだろう。
コレだけで、匿名性は十分だと思うのだが・・・どうなのだろう?
- 426 名前：login:Penguin mailto:sage [2005/07/06(水) 01:23:30 ID: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 mailto:sage [2005/07/06(水) 03:31:05 ID:Vmpb7hhF]
- Winnyの例でいうと、(といってもその時代に参加してなかったが)
暗号化キーがかけられたファイルというのがあって、暗号化キーがわからない限り
キャッシュが復号できない機能が存在してた。が、後になくなった。
消えた理由は、使われなくて不評だったから。
キャッシュですら消されてしまうのに、得体の知れない復号できないキャッシュを
残しておいてくれるお人よしな人はいなかったらしい。
簡単に復号できないキャッシュは、そういう運用をされることを考えた方がいいと思う。
なんかメリットがないか、ペナルティがないと持っててくれないと思う。
- 428 名前：login:Penguin mailto:sage [2005/07/06(水) 16:34:55 ID:pbi5Lyod]
- >>427
Winnyの暗号は、知っているもの同士が、集まって決めて、知らないものは
利用できなかったから、結果的に廃止になったのだと思う。
>>425の例では、クラスタワードに引っかかるのが、復号のための鍵の情報しか持っていない
キーファイルだけにして、キーファイルからハッシュなどの方法で連想できる値を元に、
再び検索をかけているので、暗号化ファイルは誰からも閲覧可能である。
キーファイルから暗号化ファイルは連想できるが、暗号化ファイルからキーファイルが
連想できない原理は、「1632412」から「偶数」であることを「連想」できても、
「偶数」から、「1632412」が「連想」できないのと同じこと。
- 429 名前：login:Penguin mailto:pbi5Lyod [2005/07/06(水) 17:06:53 ID:665Lc0RY]
- >>426
ハッシュは、128bitあれば十分か？
共通鍵は乱数で決めるとしても、衝突の危険性がない訳ではない。
キーファイルには、暗号化していないファイルのハッシュと共通鍵を
書いておき。暗号化ファイルのファイル名には、元ハッシュ値と共通鍵を
文字連結させて、決められた回数分だけ再びハッシュをかけたものを使う。
衝突の危険性は、低くなるだろう
あと、1000秒ってのは長すぎるだろ？
どうにかして、10秒程度に抑える必要あり。
こうしては、どうだろうか？
例えば、アプリ起動時にパスワード(英数字4文字で十分)を要求するようにする。
そのパスワードが書かれたファイルは、キーが保管されるパーミッションに保管される。
別に暗号化する必要はなく、昔のUNIXのpasswdファイルのように平分のままでもいい。
起動のパスワードを忘れたら、そのファイルを見ればいい。
アプリの隅っこに、「闇」ボタンがあり「闇」ボタンを押すと、
起動時パスワードをメモリに保存。
キーが保管されるパーミッションをフォーマット。
暗号化ファイルのファイル名を起動時パスワードで暗号化。
すべての設定をデフォルトにする。
- 430 名前：login:Penguin mailto:sage [2005/07/06(水) 17:10:19 ID:665Lc0RY]
- このときの暗号化強度は強いものである必要はないが、暗号化したかどうか
分からないようにすることが必要。つまり、ファイル名が16文字だった場合、
16文字のままでないといけない。誰かが、暗号化ファイルからデータを複合
しようとしても、ファイル名が暗号化されているかどうかは、本人しか知らない。
暗号化されていると分かって、シラミツブシにファイル名を復号して、ファイルを復号しようとしても、
500万のキーファイル
キーファイルから暗号化ファイルの連想に10秒かかる。
起動時パスワードは、数字だけ使っても10000通り。
辞書攻撃を受けても、3000〜2000年以上かかる計算になる。
ほとぼりが冷めた所で、暗号化ファイルのファイル名を復号すればいい。
起動時に毎回要求されているパスワードなので忘れることもないだろう。
起動時に要求するパスワードは、パスワードを覚えさせることを目的としているため
変えないほうがよいと考えられる。
さらに、中継ノードは暗号化ファイルはキャッシュするが、キーファイルはキャッシュしないとなどの
仕様をつけ足せば、無闇にキャッシュを消す事もなくなるだろう。自分のクラスタが特化されている場合、
暗号化ファイルの中に自分が欲しているファイルがある可能性がある。キーファイルは、1KB以下のファイル
だが、暗号化ファイルは、それよりも遥かに大きい。よって、無闇にキャッシュを消すと、逆に欲しい
ファイルを手に入れるのに時間がかかってしまう。
- 431 名前：login:Penguin mailto:sage [2005/07/07(木) 01:25:37 ID:Wgy7DjVN]
- キーファイルがある->キャッシュを消せる。
キーファイルがない->クラスタ化できない。
- 432 名前：login:Penguin mailto:sage [2005/07/07(木) 05:31:46 ID:4ekhGbja]
- >>428
キャッシュから直接に鍵が検索できない、っていう仕様であってる？
中継ノードが復号できない仕様は、中継でたまったキャッシュを消される危険性が高いと思うんだが。
- 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]
- ん？
> ヤバイと、思ったときは即座に、そのパーミッションをフォーマット・・・
なんだこれ。
|
 |
