03/10/09 06:26 7IcEZTef
こっちへどぞ。
URLﾘﾝｸ(jbbs.shitaraba.com)
176:login:Penguin
03/10/09 23:58 9Vc8GI09
>>175
どうもありがとう。
177:login:Penguin
03/10/11 13:59 c7ghlcpD
このスレは今からUnny開発プロジェクトに変わりますた。
178:login:Penguin
03/10/13 20:06 9a90mJZ3
なんかさ・・・ 47氏の中の人がマジ大変なことになってるようで・・・
Linuxどころじゃねーんだろな。
こりゃますます47氏に依存しないLinnyの確立が期待されるところだが・・・
179:login:Penguin
03/10/13 21:51 rVbJnK2o
名前はLinnyでも何でもいいから新しいfreenetフロントエンド作ってよ。
180:login:Penguin
03/10/13 21:54 xbG29dg3
>>178
どこかのスレに載っているの？
生存してるよね？
181:login:Penguin
03/10/13 21:56 xbG29dg3
あったあった。
URLﾘﾝｸ(www.geocities.co.jp)
182:login:Penguin
03/10/13 22:20 xbG29dg3
デジタル証券によるコンテンツ流通システム
URLﾘﾝｸ(www.geocities.co.jp)
これについて討論できる場所ってどこ？
漏れの感想は、コンテンツを配信する権利、コンテンツ製作元にものを言う権利
を得るためにデジタル証券を購入するとは思えないから、うまく動かないと思う。
183:login:Penguin
03/10/13 23:17 j0aKmbqi
Winny作者が語る将来展望とデジタル証券システム
URLﾘﾝｸ(slashdot.jp)
184:login:Penguin
03/10/14 00:01 lHY+UrIP
>>183
サンクス！
185:login:Penguin
03/10/14 00:02 lHY+UrIP
コピーフリーでも成り立つ集金モデル２
ｽﾚﾘﾝｸ(eco板)l50 [2ch.net]
【通信】Winnyの将来展望について ★2 （2003/10/10）
ｽﾚﾘﾝｸ(bizplus板)l50 [2ch.net]
コピーフリーでも成り立つコンテンツ製作者側の（略
ｽﾚﾘﾝｸ(stock板)l50 [2ch.net]
186:login:Penguin
03/10/14 16:51 kBAx32UI
無理だな
187:login:Penguin
03/10/21 02:28 sIXV7OYa
P2P型ネットワーク対戦ゲームってある？
FinalFantasy XIみたいなネットワークゲームを、中央サーバなしで
OpenSource Communityでやるのは面白そうじゃない？
商用顔負けのゲームつくれないかな。
188:login:Penguin
03/10/21 02:51 owDTMc8X
検索してみろ。
あと野良サーバーで商用ゲームやっている奴もちらほら
189:login:Penguin
03/10/21 08:21 ePZNdgoq
>>187
とりあえず、普通のゲームでも商用顔負けってのは少ないんだから
ネットワークゲームを、それも中央鯖無しで面白くってのはかなり難しいかと
でも通信の部分だけでもできたらすごいよね
190:login:Penguin
03/10/21 13:46 DHWtZaYW
>>189
1年後にPenguin版もできるらしいよ
URLﾘﾝｸ(gamdev.org)
191:login:Penguin
03/10/24 03:10 MeLvsMjG
本家が開発終了な感じだが、こちらも(ry
192:login:Penguin
03/10/24 08:39 IBNvuHP/
こちらは開発にすらたどり着けなかったんだがな
193:login:Penguin
03/10/24 08:54 8ugQWh1J
つーことで、Winny の逆汗して互換品を作るスレにしようぜ。
194:login:Penguin
03/10/24 12:41 dLXppHIo
>193
そんなことできるのか！？
195:login:Dayomon
03/10/24 15:52 8QNGqh+r
お前らGNUnetがいけてるんですが一緒に遊びませんか？
196:login:Penguin
03/10/25 02:56 fT86YYhN
>>193
通信部の解析はめんどいからやる気にもならん。
そんなことするくらいなら新しくつくったほうが速い
197:login:Penguin
03/10/25 22:56 mByoNVQw
Linux使いには、47氏並みの能力を持つプログラマーはいないのか！？
198:login:Penguin
03/10/25 23:02 rBEfoTH3
>>197
見当違いの証券システムとかを発案する能力のこと？
199:login:Penguin
03/10/25 23:20 mByoNVQw
いや、この場合、プログラミング能力+厨のバージョン催促に耐える能力のこと。
200:login:Penguin
03/10/25 23:30 rBEfoTH3
マジレスさんくす。
crack 耐性が高い通信方法を生み出す能力も欲しいよね。
201:login:Penguin
03/10/28 14:36 4Vx0oMC6
>>197
結構いるよ。
あと、OS,プログラム板にはそれ以上の御方も。
202:login:Penguin
03/10/28 23:33 7BAsFMT8
>201
それらの神々は、世俗なことには干渉しないのでつか？
203:login:Penguin
03/10/29 00:42 3W9h7fEu
ライセンスを重んじていたりするからじゃないの？
匿名通信ができるアプリは、結局割れ物の取り引きにしか使われないんだし。
204:login:Penguin
03/10/29 00:57 BnJyeKO1
リスクもあるしね。
もし自分が作っているとバレたら…？とか。
205:login:Penguin
03/10/29 00:58 3W9h7fEu
Freenet 内なり Winny 内なりで公開すれば、かなりリスクが低くなる？
206:login:Penguin
03/10/29 00:58 LVWXyaex
作ってみたいけどなぁ
Windowsでの開発知識しか無い
207:login:Penguin
03/10/29 01:13 3W9h7fEu
と、そんな嘘でごまかせると思っている人がいるので、注意が必要ですね。
208:login:Dayomon
03/10/29 03:14 sFHSNqVn
ナイス連携。
209:login:Penguin
03/11/05 01:17 Vb1P/sn/
ぺったんぺったん
210:login:Penguin
03/11/09 19:49 GbnINMgp
びっくりするほどＰ２Ｐ！
211:login:Penguin
03/11/10 12:58 vLbAgvq1
>>195
最近更新されてないみたいだけど、
いけてるんですか?
212:login:Penguin
03/11/18 21:11 bEG7ksJ8
漏れら極悪非道のageブラザーズ！
今日もネタもないのにageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ∧＿∧ age
（ 'A`∩） （∩´∀｀） age
（つ 丿 （ ⊂） age
（ ヽノ ヽ/ ） age
し（＿） （＿）Ｊ
213:login:Dayomon
03/11/19 01:21 NUnV2Rmg
ﾉｼ
214:login:Dayomon
03/11/23 01:44 w0hNbOKT
ヽ(ﾟ∀ﾟ)ﾉ ｱｯﾋｬｯﾋｬ
215:login:Penguin
03/11/28 00:07 DF914n14
nyが無くなる今、このスレをageなくてどうする？
216:login:Penguin
03/11/28 00:29 ttKXuPtv
まだあったんだ、このスレ。
家宅捜査か、、何で匿名が破られたんだ？
217:login:Penguin
03/11/28 01:21 WQa0DvCQ
geocitiesへのftpアクセスログじゃないの?
そのために色々と法案通していたし。
218:login:Penguin
03/11/28 03:31 SiJSR2Jo
完全に匿名なわけじゃないからねぇ。
今回は47も家宅捜索されたみたいだから、
47が暗号化解除とかで協力したんじゃないの。
219:login:Penguin
03/11/28 03:33 4aVtXQnt
家宅捜索でＫはnyのソースを得た事になるな
220:login:Penguin
03/11/28 05:04 icFsr3aB
>>217
やっぱその線かのぅ ４７も迂闊だったな
あと2chのログか
221:login:Penguin
03/11/28 16:31 DF914n14
さぁプロジェクト再始動だ
222:login:Penguin
03/11/28 17:08 qG5hbGfy
金にならないP2Pなだけに、職業プログラマは無視を
決め込んでるみたいだけど、プログラミングテーマとしては
P2P特に匿名ファイルシェアリングソフトは熱いな～
223:login:Penguin
03/11/28 17:58 f/j5dBc6
さて、今回の問題でWinnyのどこに問題があったかが示されたわけだが。
現状、Winnyシステムの根本がこけたわけではないと思うが、1人に頼りすぎたのが
敗因だと思う。
次はどうするよ。Winny式でオープンソースでFA？
224:login:Penguin
03/11/28 18:58 QvTe2a/1
次世代は、公開しても安全で不正の極めてやりにくい「プロトコル」を
実体とするべきだとおもう。
極論、実装は誰がやってもいい。
225:login:Penguin
03/11/28 20:02 GoFNDi8X
実際、仲間ウチで小さく
P2P転がすような事をやらないと今回みたいな事になる。
プロトコルや実装の問題より運用の問題が大きい。
226:login:Penguin
03/11/28 20:25 96YzfNpY
馬鹿はいつでもどこにでもいるからな
227:login:Penguin
03/11/28 20:25 n2B30HKa
>>225
んで実際問題ソフトは出来たの？
228:login:Penguin
03/11/29 00:29 Xr1K3nva
ｵｰﾌﾟﾝｿｰｽ(･A･)ｲｸﾅｲ！
229:login:Penguin
03/11/29 00:56 oiytMlVm
理論的に匿名性が保証できるプロトコルにして、さらに回線帯域をガンガン使
うような仕様にしてユーザを光に限定してしまえば、Winny がオープンソース
にできなかった最大の原因であるところの FreeRider 問題はある程度解決でき
るような気がするのだけれど、甘いかな？
230:login:Penguin
03/11/29 03:29 IymQcMSr
【神】UNIXにWinnyを移植【降臨】
ｽﾚﾘﾝｸ(unix板)l50
次期P2Pの仕様 part2
ｽﾚﾘﾝｸ(download板)l50
231:某所管
03/11/29 03:45 x77e14sf
一応、記録的価値としてLinnyWiki復活させておいたので張っておきまつ。
URLﾘﾝｸ(linny.winny.info)
232:login:Penguin
03/11/29 08:38 jErzhRBe
>>221-
この緊急時に相変わらずｸﾞﾀﾞｸﾞﾀﾞなループ繰り返してるのにはﾜﾛﾀ
233:login:Penguin
03/11/29 14:24 uU3sSM8j
このスレまだあったのか。ny逮捕でﾀﾞｳｿのﾔｼらが
ム板とか犬板をあさっているのかな。
234:login:Penguin
03/11/29 17:41 UGXkZjJ0
初期のLinnyのことも考えてまともな頼れるリーダを2人くらい作ったほうがいい気がする。
235:login:Penguin
03/11/29 17:44 iLpA4HcV
P2P Projects supporting Anonymity
URLﾘﾝｸ(knet.sourceforge.net)
236:login:Penguin
03/11/29 19:17 3iYswX3r
>>234
／￣￣￣￣￣￣＼
／ ＼
/ ヽ
l:::::::::. |
|:::::::::: （●） （●） | 呼んだ？
|::::::::::::::::: ＼＿＿_／ |
ヽ:::::::::::::::::::. ＼／ ノ
237:231
03/11/30 12:31 w2iVfBfH
>>234
／￣￣￣￣￣￣＼
／ ＼
/ ヽ
l:::::::::. |
|:::::::::: （●） （●） | 呼んだ？
|::::::::::::::::: ＼＿＿_／ |
ヽ:::::::::::::::::::. ＼／ ノ
238:login:Penguin
03/11/30 17:17 u/aqrZK8
次期P2Pの仕様 part5
ｽﾚﾘﾝｸ(download板)
P2Pもいろいろとソフト変更があるみたい。ここを除くことお勧め
239:login:Penguin
03/12/01 01:37 HcdZ6tlc
P2Pなんか危いよ
もうnntpしかないよ
240:login:Penguin
03/12/01 22:27 8ZXVF3BM
結局このスレは頓挫してたのか・・・
やっぱ烏合の衆だけじゃだめだな。
一人の実行力をもってる人がいなきゃだめだ
241:login:Penguin
03/12/01 22:41 WiuZNPkX
>>240
／￣￣￣￣￣￣＼
／ ＼
/ ヽ
l:::::::::. |
|:::::::::: （●） （●） | 呼んだ？
|::::::::::::::::: ＼＿＿_／ |
ヽ:::::::::::::::::::. ＼／ ノ
242:make world
03/12/02 19:31 aKXy48Gr
openで開発したら収拾つかないだろうな
243:login:Penguin
03/12/03 02:38 rPc4FgbH
>>242
収拾する必要は無い
244:login:Penguin
03/12/04 02:10 0dWBPS/h
ソフト開発出来る人、参加して下さい。オープンソースでの開発を目標にしています。
次期P2Pの仕様 part5
ｽﾚﾘﾝｸ(download板)
245:login:Penguin
03/12/04 02:10 0dWBPS/h
age忘れました。
246:login:Penguin
03/12/04 05:04 AK3fWQow
>>244
コードは書けんが、テストなら協力できますよ
247:login:Penguin
03/12/04 08:15 LZsdqusC
>>244
アップはできんが、ダウンなら協力できますよ
248:login:Penguin
03/12/06 16:41 ASv9zxaf
典型的なプロジェクト失敗例を見せてくれたスレ
249:login:Penguin
03/12/07 00:28 1ZK45BnP
プロジェクトにすらなってないけどな
250:login:Penguin
03/12/20 19:45 uF39G1i3
URLﾘﾝｸ(mute-net.sourceforge.net)
> MUTE File Sharing is a new peer-to-peer network
> that provides easy search-and-download functionality while also protecting your privacy.
> MUTE protects your privacy by avoiding direct connections with
> your sharing partners in the network.
だそうです。
251:login:Penguin
03/12/20 20:17 orBV6cTG
ｽﾚﾘﾝｸ(prog板)l50
252:login:Penguin
03/12/21 00:53 Tnk+ergb
>>250
これ、期待できそうです。
253:login:Penguin
03/12/21 01:21 7KaUReeK
で、251のスレでWinny2のソースらしきものが張られているわけだが・・・。
254:login:Penguin
03/12/21 01:42 UW66JoV+
>>253
ところで、パスワードは割りましたか？
255:login:Penguin
03/12/22 05:22 Fx01jsVP
>>254
ﾀﾞｳｿすらできてないわけだが・・・。
どのプロキシ使えば落とせるのやら。
256:login:Penguin
03/12/22 17:21 C9mRSYV4
>>250 /.本家より
MUTE: Simple, Private File Sharing
URLﾘﾝｸ(slashdot.org)
だそうだ
257:login:Penguin
03/12/23 20:17 UofXNrH/
蟻が食べ物を見付ける方法からインスピレーションを得たってなんか凄いな・・・
258:login:Penguin
03/12/24 09:19 p5RJmfHH
>>256
で、どうよ。使えそうか？
俺の環境(RedHat9)では固まりまくるが。
259:login:Penguin
04/01/08 12:45 91Mu2rfW
Mute Ver.0.2
URLﾘﾝｸ(mute-net.sourceforge.net)
Known issues with version 0.2:
Linux:
--Strange system-wide freeze on LinuxPPC. Happens when receiving
a series of connections (shows up in log). Freezes happen with both
text and GUI. Must be triggering a kernel crash (bug in kernel).
LinuxPPC kernel v2.2.15-2.9.0
--No crashes seen in Linux.
260:login:Penguin
04/01/12 19:03 H2XKicfm
age
がんばれ
261:login:Penguin
04/01/14 00:07 Qid/c1ot
俺もRedHat9ですが接続先を追加できないっぽいです
262:login:Penguin
04/01/29 21:39 gWkVseHH
ほしゅ
263:login:Penguin
04/01/31 00:08 PjoeMZsH
んでいつできるんだ？
264:login:Penguin
04/02/04 10:13 3zoKxviV
MUTEを日本語使えるようにすりゃいいじゃん。
265:login:Penguin
04/02/11 23:48 2/PKzn50
俺、linuxというかUnix版のWinny作ってるんだけど、
やっぱ公開すると、家宅捜索とかされちゃうのかな？
266:login:Penguin
04/02/12 02:55 gusrgYRS
そもそも君の場合は、コードが手元にない狂言なので、大丈夫かと。
267:Seisei_Yamaguchi
04/02/15 02:29 NKg64qLe
警察の中の人はソースが欲しかったから
ジオシティー日本から辿ったんとちゃう ?
268:login:Penguin
04/02/17 20:23 l3npdv3O
Winnyパケットをブロックするソフトが出たみたいだね。
age
269:login:Penguin
04/02/18 11:15 9aTdwy7Y
>>268
これのことだろ。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
モニタしてるキャプ画像があるんだが、暗号は完全に解読された模様。
もうwineでwinny動かしてる場合じゃないぞ、おまいら。
270:login:Penguin
04/02/18 12:14 gem58jl9
これって暗号が解読されてるのかな…
あれだけだと、 winny network に偽の node として参加してるようにも見えるけど。
参加できれば、検索とかの query 読んで、その関連する packet 落とす…とかもできるだろうし。
271:login:Penguin
04/02/18 13:47 INzA8wD0
ふつーに、どこかの板に、不完全なソースコードが転がってます。
ソースコードの中には埋め込まれた暗号鍵も付いてます。
272:login:Penguin
04/02/18 18:34 ysm3TANi
Winny は相互接続する時に相手で本当に Winny が動作しているかどうかの確認
と、回線速度情報、クラスタワード を交換します。どうもその時の情報をデコー
ドするのに成功したようですね。通信内容は無理っぽい。
Netagent で公開されてる資料の13ページ見ると手がかりがありますな。
273:login:Penguin
04/02/19 21:44 YUXcILLr
どっちにしてもKとACCSは完全なソースを持っている。
274:login:Penguin
04/02/27 19:11 OzDpoA/F
もまいら、winnyはいよいよ駄目だぞ。
URLﾘﾝｸ(www.itmedia.co.jp)
暗号さえもっと強固なものだったら良かったのかね?
275:login:Penguin
04/02/27 21:00 WZTEm3ZQ
だから暗号と匿名性は無関係だとなんど言えば。
276:login:Penguin
04/02/28 22:34 S72mqHhA
>>275
>杉浦氏は、1個のパケットを見て、どこから来たものか解析することはある程度可能だと話す。
>「たどっていけば、1次配布先も分かるだろう」（杉浦氏）。
と言ってるからだと思われ。
ただ、
>「ソースコードを見たり、パケットを解析したりしながら、試行錯誤してデータを逆アセンブルしていった」（同氏）
最初は、ソースは入手していないメモリ解析と書かれていたと思うのだが
この辺の供述が曖昧な辺りが、この記事で発言している人物の信憑性に疑問を持たせる。
277:login:Penguin
04/02/28 23:51 WXc+IhON
>>276
まぁ、本人はその筋では結構有名な人だから、技術者としてはどっかの
ネットアークと較べればかなりまともな筈。
逆アセしたソースを見たと言ってたんじゃないかなぁ。データを逆アセ
するってのもなんか表現が変。この記者の信頼性もいまいちなので...
URLﾘﾝｸ(aki.nekoruri.jp)
278: ◆HO0OFh2RXI
04/02/29 06:48 lTwPvcXw
原案
Winnyのオープンソース化を考えるスレ
URLﾘﾝｸ(winny.info)
ｽﾚﾘﾝｸ(linux板:354-番)
354案にいろいろと混ぜてみたものです。
細かいチャンクにする、通信にはコストがかかるとする、というのが基本です。
自分のUp/Downしたいものは隣のノードが欲しがっている/持っているとみなして行動。
Winnyの転送の多い時期で転送リンクブチブチ状態のイメージ。
やればやるほどFreenet…効率がとても悪そうです。
とりあえず置いておくんで好きにしてください。
279:login:Penguin
04/02/29 06:49 lTwPvcXw
☆ネットワークを流れる情報は、すべてにIDが振られた小さなチャンクに分割される。
このIDは、内容により決められネットワーク上一意とする。
☆チャンクは2種類あり、書き換え可能なチャンクと内容が保護されたチャンクである。
書き換え可能なチャンクを回覧板、内容が保護されたチャンクを小包と呼称する。
★回覧板チャンクのIDは、内容のテーマにより決められ、内容に関知しない。
★小包チャンクの内容は公開鍵暗号を使用し、暗号化する。
そのIDは、暗号化済みの内容(鍵を含む)ともともとの内容の両方のハッシュに依存し、
それぞれ確かめ得るようにする。
☆すべてのチャンクのやり取りにコストを設定する。
正のコストのチャンクを受信すると、送信ノードに対し、送信債務が発生する。
要するにUpしてもらえる権ということです。
コストは、取引開始側が設定し、取引了承側が認証する。負のコストも許される。
言い値で決まるが、不満であれば取引が成立しない。
虚偽の取引を行った場合は直ちにリンクを切断し、以降の取引は行われない。
すべてのノードは、送信債務という借金状態を解消しようとすることが要請される。
つまり基本的にはDownすればUpすることが要請されます。
あるノードが借り逃げを行った場合、または著しい債務超過に陥った場合、
悪質ノードとして切断し、以降の接続を一定期間禁止する。
大きい値のコストの取引は、取引実績ができるまで行われない。
☆ファイルを流す際は、適当なサイズに分割しそれぞれを小包チャンクとする。
それぞれの小包のIDとその鍵のリスト、及び元のファイルの識別情報（ファイル名、元ハッシュなど）を
まとめて小包チャンクとし、フックチャンクとする。
このフックチャンクはWinnyでいうところの仮想キーに相当するヘッダ部分である。
★フックチャンクは、自ノードでは特別に処理が行われ、元ファイルの識別情報と対応がつけられている。
外部に対しては、直接指定された場合は単なる小包チャンクとして振る舞う
280:login:Penguin
04/02/29 06:49 lTwPvcXw
☆チャンク情報の拡散
検索ワードを指定した回覧板チャンクをつくり、これを検索チャンクとする。
検索チャンクには、指定ワードと関連するファイルの、元ファイル識別識別情報とフックチャンクIDのセットが
リストになって入れてある。
受け取ったノードは、リストをフックチャンクプールに格納し、自分の情報を混ぜた上で再び検索チャンクを形成し
隣接ノードに転送する
☆チャンクの予約
タグワードを指定した回覧板チャンクをつくり、これをオークションチャンクとする。
オークションチャンクには、要求チャンクIDと取引成立時の予定コストとUp/Downのリストが入れてある。
受け取ったノードは、リストを来たノードをマークした上でオークションチャンクプールに格納する。
自らのダウン予約の都合を考えて、オークションチャンクを入れ替え、隣接ノードに転送する。
☆チャンクの取引
オークションチャンクの情報を元に、Up/Downの要求が一致すれば、送ってきた隣接ノードに取引要求する。
要求内容は、対象チャンクID･Up/Downの別･成立時の支払いコストとする。
要求を受け取ったノードは、以下の3つから行動を選ぶ
★要求を受諾し、チャンクを移動し、完了後コストが移動される。
★要求を拒絶する。
★要求は拒否するが、他のノードを紹介する。
検索チャンク、オークションチャンクも同様に扱う。
281:login:Penguin
04/02/29 06:50 lTwPvcXw
＜データ入手までの流れ＞
ファイル名 →フックチャンクプールから検索(なければ検索チャンクで底引き)
→フックチャンクをオークションチャンクで予約→取引成立すればDown→展開
→内容チャンクを順次オークションチャンクで予約→取引成立チャンクからDown
→すべて揃い次第元に戻す
＜オークションチャンクと取引コスト＞
☆あるチャンクが欲しい時、大きいコストを設定してDown予約をかけると、
成立の可能性が高くなる。
所持ノードがUpしたときの利益が大きいので応じることが予想されるからである。
しかし、あまり大きいと新参者小取引の原則により無視される。
また、中間ノードが中継して(もっと小さいコストで元ノードから入手し)利益を得ようと
するので効率が悪くなる。
☆あるチャンクのDown予約が隣から流れてきた時、そのノードに対して債務がある場合、
自ら率先してそのチャンクを入手することが望まれる。
先に手に入れることができれば、そのノードに対しUpを行い借りを返すことができるからである。
☆オークションチャンクの転送時に予定コストを書き換えることで、転送利益を得ることができる。
☆あるチャンクが欲しい場合、Downで正のコストを設定する。
誰かが欲しがっているチャンクをUpする場合、Upで正のコストを設定する。
オークションチャンク、検索チャンクなどのどうしても受け取って欲しいチャンクを
Upする場合、Upで負のコストを設定する。
☆負のコストのUpを利用して、仮想アドレスタグをつけた小包チャンクを投げることで
IMのようなノード間通信が可能かも。
このとき、間のノードはコストの絶対値を少しずつ減じていくことで、利益を得ることが
できるのでコストに対し十分近ければ届く。
★所持チャンクのコスト評価値
Upする時のコスト目標値。有用だと自らが判断するチャンクに対しては高くつけておく。
需要が多ければ上げ、なければ下げる(でないとDownする人がいない)。
282:login:Penguin
04/02/29 06:51 lTwPvcXw
＜検索およびオークションチャンクの転送経路＞
☆タグまたは検索ワードと、クラスタ化キーワードとの優先度比較で大きいノードに転送されやすくする。
☆送ってきたノードに直接返してはいけない。(取引の不正を防ぐため)
☆チャンク転送利益を得られないほどコストの絶対値の下がった、自分に不要なチャンクは破棄してよい。
＜ノードの接続条件、切断条件＞
(考え中)
☆クラスタワード制により、意図的に移動できるようなネットワーク距離を導入し、
近いノードに優先接続する
☆取引実績のあるノードは優先する
☆取引に嘘ついたノードは即切断、(覚えていられる限り)二度と許さない。(周りに伝達するかも)
☆取引がこちらの赤字の場合できるだけ切断しない
☆(主観基準の)大規模な借り逃げは、以降の接続を蹴る。(周りに伝達するかも)
☆ある程度の借りっぱは、次に接続した時に払ってもらう。動的IPの誤爆は気にしない。
☆小規模な貸し借りは、水に流す。
☆貸している側はいつでも切断できる。
283:login:Penguin
04/02/29 06:51 lTwPvcXw
＜利点＞
☆2者間の通信のみで、不正ノードを判定できる。
☆部分キャッシュであるチャンクに価値をもたせられる。
☆チャンクそれ自体は、単独で意味を持たない。
☆チャンクの取引コストを、信頼度、優先度として準用できる。
☆チャンクを所持していることは、内容を知って公開していることを意味しない。
(中の人の判断基準は取引に有用であるかどうかのみ)
＜問題点＞
★大きいファイルの時チャンクが揃わない可能性。
★ネットワーク上の自分とその周りのノードが興味を持つチャンクすべてを把握する必要がある。
★膨大な数のチャンクの取引の必要があり、ネットワークが飽和する危険がある。
★検索がかけにくい。
★同一ファイル複数キャッシュ問題。暗号化キーが異なるチャンクは互換でない。
284:補足考察
04/02/29 06:52 lTwPvcXw
★ネットワーク的に価値をもたないチャンクの排除
フックチャンクの場合(ファイル名詐称など)は、無視リストを使用して所持しない、転送しない。
優良フックチャンクを高く評価し(取引コストを上げる)、相対的に排除。
平チャンクの場合、内容の評価は不可能。高値で取引できるのなら、中身については関知しない。
ゴミチャンクは意図的にDownをかける香具師がいない限り、コスト値が高いまま取引されることはない。
ローカルでチャンクの保持基準をコスト評価値と最終アクセス時を元に決めればそのうち消える。
★高い評価のゴミチャンクの可能性
自作自演によって可能。たとえ自分が騙されても、他に騙されるやつがいる限り
被害はない。平チャンクがどこのファイルの所属なのかをたどる方法は存在しないので、
アクセスがある限り消えることがない。
消える可能性は、Winnyでいうところの完全キャッシュのみにする操作をノードが
行うであろうこと。
HDDに余裕があるのならどうぞ飼ってやってください。
★優先度の詐称
高値のチャンクをUpすることが一番効率のよい方法。
★接続ノード限界
Upするノードの不足がもたらす。落としたいファイルを持つノードの優先接続条件に
適合するようにすれば回避できる。つまり熱心に奉仕汁
285:login:Penguin
04/02/29 06:53 lTwPvcXw
★初期開放ノードの隠蔽、その必要性
フックチャンクが出回らない限り、平チャンクのアクセスは困難。
そのため、どうしても身元を隠蔽したいデータをUpする際は、自作自演をかけ
周りにチャンク単独での価値を知らしめ、拡散した後、フックチャンクを公開する。
自作自演にはコストがかかるので、どうしてもの時だけに。
Down要求を蹴って他のノードに回して、かつ、その他ノードに対しUp要求をかけると
隠蔽できるかも。
★Port0(外部からの接続不可)の取り扱い
未定
★大量のファイルの保持者の負荷
チャンクの要求があったとき、所持チャンクから検索しなければならない。
ファイルをネットワークに投入する際、ハッシュ計算で時間がかかる。
★IPをさらした上での匿名性
隣接ノードがUp要求をかけた際に、所持チャンクが確定できる。
ただし、これはファイルの所持に直結しない。
286:login:Penguin
04/02/29 06:53 lTwPvcXw
★IPの変わる常時Up優良ノードの取り扱い
あまり長時間同一ノードと取引することは推奨されない、ノードの評価の保持は
一定期間であるということから、固定IPと比べ不利益はない
★繋ぎなおしでマイナス評価が消える
ネットワークへの接続はかなり厳しいものとなっているので、取引に必要な
評価を得ることへの手間がペナルティとなる
★途中の中継ノードによる、検索キーの捏造/改竄
IDは内容のハッシュを元にするので、破損として処理する。
破損チャンクは取引成立ではないのでリトライが強制される。
★ファイル名の詐称
フックチャンクの評価値により排除をする
★クラスタ位置を変えることによる評価の消滅
クラスタにとって有用でないノードはいらないと考える。
たとえ別クラスタで有用であったとしても、それはそれこれはこれ。
★流通するキーの一覧を作成することによる危険
目安になることは確かであるが、実際に完成するまで本当に存在するかは確定できない。
287:login:Penguin
04/02/29 07:46 KT/zUJUZ
おお！？ Linnyプロジェクト再起動か！？
288:login:Penguin
04/03/01 21:27 rhb6VIeO
すでにバッテリーもへたってるから、腐った燃料では動きもしない･･･と。
289:login:Penguin
04/03/02 00:45 9lmYd62z
>>278-286 まで読んで見たものの、言葉だけではボンヤリとコンセプトだけで
具体的な手続きの順序とか、階層とかそういったものが共有できない…
それぞれ得意な分野を分担して実装すれば、ソース公開の意味があって
いいと思うんだけど、誰が何から実装するのかという、
最初の取っ掛かりがあればねえ。
俺も含めて他力本願なんだろうけど。
290:login:Penguin
04/03/02 02:33 9lmYd62z
次期P2Pの仕様 part9
ｽﾚﾘﾝｸ(download板)
需要として参考になるのかな。
291:login:Penguin
04/03/02 23:46 j+7Rtc66
freenetのNGRが良い感じ。
292:login:Penguin
04/03/09 02:54 lz/xxrRp
>>290
ちょうど今、これ>>278-286と似たようなことが話題になってるな。
サーバを置くのが効率的には絶対にいいと思うんだけど、いろいろと問題ありそう。
eDonkeyが価値評価を導入してるらしい。参考になるかな
293:login:Penguin
04/03/13 02:35 it57ICZi
せっかく>>290のスレで課金可能性について論じられていたので278案での実現可能性について書いておきます。
ネットワーク内で使用している取引コストとして、現実世界のお金を使用することで課金できると思います。
ただしこの場合、信頼できる通貨サーバが必要ですが。
内容は暗号化し、ネットワークに流しておきます。
フックチャンクを2種類用意し、1つは集めることはできるが復号はできないもの(不完全フックチャンク)、
もう1つは復号できるもの(完全フックチャンク)とします。
不完全フックチャンクは通常と同じに流通させますが、完全フックチャンクは特殊な取引によってのみ流通させます。
内容が欲しいノードは、通常の手順で不完全フックチャンクを元に、パーツをそろえます。
次に、完全フックチャンクを持っているノードと、通貨サーバと通信できる状態にします。
チャンクの取引には、通常だと取引コストとしてDown権を渡すわけですが、完全フックチャンクの取引には
通貨サーバによる支払い証明を取引コストとして渡すことになります。
この取引において、完全フックチャンクを所持しているノードが正規の手続きなしに流してしまうと
そのファイルに対する課金が崩壊してしまいます。
転送報奨としていくらか分け前を与えるとか、完全フックチャンクに所持ノードIDを書いておくとかしか
思いつかないんで、他にもっといい方法があるかも。
294:login:Penguin
04/03/31 06:32 HoAkMBXl
winny3を作ろうよ
ｽﾚﾘﾝｸ(download板)
295:login:Penguin
04/04/02 00:21 WpkuJ3NS
とりあえず厨が入ってこれないようにしたい。
296:login:Penguin
04/04/02 09:14 WTKLrf8O
winnyの英語版が欲しいです。
私はあなたの支援を必要とします。
297:login:Penguin
04/04/02 09:41 j4zdC+mr
>>296
板違い
298:login:Penguin
04/04/17 01:58 JW5Fbu01
sage
299:login:Penguin
04/04/30 03:21 1Mr+A9gw
age of Linny
300:login:Penguin
04/04/30 07:37 F2pqcMu3
>>297
韓国人にそれは通じないだろう
301:login:Penguin
04/04/30 07:42 MoJY09XL
>>300
韓国ってのもいいかげん飽きたなぁ。
302:login:Penguin
04/05/01 00:01 rQWDA2uP
>>301 三国人で無問題
303:login:Penguin
04/05/10 14:12 gOkOLaIk
４７氏の釈放を訴えるＯＦＦ
ｽﾚﾘﾝｸ(offmatrix板)
４７氏の釈放を訴えるＯＦＦ
ｽﾚﾘﾝｸ(offmatrix板)
304:login:Penguin
04/05/10 18:11 zyDxrivK
結局、535氏の途中断念が正しかったのか？
作ったらﾀｲｰﾎだろ？
305:login:Penguin
04/05/10 19:28 1n9r+xb3
違法逮捕だとは思うが、nyには興味ないので無視。
306:login:Penguin
04/05/10 19:31 1n9r+xb3
EFFに通報すれば取り上げてくれるだろうけど、誰も英文メールが書けない。
307:login:Penguin
04/05/10 19:33 1n9r+xb3
海外に情報が漏れないように英語の記事を載せないようメディア統制済。
308:login:Penguin
04/05/10 19:34 1n9r+xb3
でも本家/.にタレコまれててアウト。
309:login:Penguin
04/05/11 02:44 B6Rf6hGv
>>305-308
これ作ってる人が本家/.タレコミ者だな
URLﾘﾝｸ(exe.adam.ne.jp)
URLﾘﾝｸ(yro.slashdot.org)
310:login:Penguin
04/05/11 12:48 Al0YeF99
これが本当のオープンにしなかった理由だしょ。
URLﾘﾝｸ(headlines.yahoo.co.jp)
311:login:Penguin
04/05/11 15:01 Hq1OSHfm
というか、Winny-DOMを使っていないと考えるほうが不自然
312:login:Penguin
04/05/12 03:19 q0cG20qw
別に数千から数万のノードがいる中で、百以下のノードが不正しても問題はない設計だろう。
不正ノードがいることではなく、多数を占めることを恐れてオープンにできなかった。
313:login:Penguin
04/05/12 21:24 dBKDTYWN
とりあえずさ、リリーススタイルを考えた方がいいと思う。
俺としては、tar.bz2にソースをまとめて海外の匿名串経由でuuencodeしたものを
2chに書き込む。これで完璧。
314:login:Penguin
04/05/14 03:25 b19TtUOi
最初からFreenet上で開発宣言してリリースも全部そっちでやった方が良いよ。
315:login:Penguin
04/05/14 17:50 7U9iS7RX
開発元を秘匿するのは、最初からやましいことやってるという表明にしかならん
と思うのだが。
316:login:Penguin
04/05/14 18:17 uTjxhWEO
>>315
今回のような、万が一の為の回避策ですよ
317:login:Penguin
04/05/14 19:09 J6S3sDkg
今回の件って、しかるべき結果なのでは？
ﾀﾞｳｿ板というグレーなものを扱う場所で動作確認をしているわけで。
318:login:Penguin
04/05/14 19:55 H+W+NZc7
仕様用途を「LinuxのISO共有」にしとけばとりあえずOK
319:login:Penguin
04/05/14 21:28 uTjxhWEO
>>318
ISOファイルの共有は是非やりたいよね。
320:318
04/05/14 23:42 ncaoYmUz
そういいつつFTPインストールをしていたりするｗ
FedoraもFTP+GUIでインストールできるようになってたし。
321:login:Penguin
04/05/15 11:22 RVJL99XP
>>318
なら匿名性は必要ないから BitTorrent で十分。
322:login:Penguin
04/05/17 20:36 HO4EIYRj
ついにWinnyのソース公開！＠プログラマー
ｽﾚﾘﾝｸ(prog板)l50
323:login:Penguin
04/05/17 21:12 +ZgvpoAo
>>321
その通りだが、
日本発のものが欲しい。
Winnyの使いごごちが捨てがたい。
署名性はおれも要らないと思う。
発信元がみえれば違法ファイルは流せなくなるからな。
324:login:Penguin
04/05/17 21:12 KQNT3jUC
署名性?
325:login:Penguin
04/05/17 21:20 +ZgvpoAo
ゴメソ
->匿名性
326:login:Penguin
04/05/18 14:19 lZIh8sQE
今さらだが作者がneko氏だった事にびっくり。
327:login:Penguin
04/05/18 19:32 5c9Ys/Tj
Linnyも535氏が本気だったなら結構楽しめるものに仕上がっていたと思うが。
328:login:Penguin
04/05/22 17:22 nqTAVPpu
URLﾘﾝｸ(linny.winny.info)
329:へりくつ星人
04/06/27 16:41 o/ZzpKCM
表現の自由を守るため、
匿名性はぜひ必要です。
330:login:Penguin
04/06/27 19:56 TW8O336t
匿名にすると荒れるからね…
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)が無ければ、「暗号化チェックサム」は復号できない。
そして、「キーファイル」単体では、意味を成さないフィールド。
様々な、情報があるが、これらを美味く使えば、悪質なノードを排除したり、
壊れた暗号化ファイルを、出回らなくするように出来るでしょう。
例外処理は、今日はしんどいので、また今度書きます。
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です。ならば、信用性のある公開鍵の「なりかわり」の心配はないか?
それは、公開鍵に対する秘密鍵が分からない限り、不可能です。