P2P型の完全匿名掲示板はまだ出来ないの？その4

前スレ：P2P型の完全匿名掲示板はまだ出来ないの？その3
http://toro.2ch.net/test/read.cgi/tech/1338720470/

wiki
http://www34.atwiki.jp/p2p-anon/

参考

新月 - P2P匿名掲示板
http://shingetsu.info/index.ja
Tor（The Onion Router）のHidden Service(onionドメイン)Onionちゃんねる
http://xiwayy2kn32bo3ko.onion/ (Tor経由でのみアクセス可能)
Syndie - distributed forums
http://syndie.i2p2.de/
Freenet - P2Pコミュニケーションフレームワーク
https://freenetproject.org/

ゴミ

乙

あと前スレで公開されたものもまとめてほしい

それから新月とFreenetとAmoeba/Lairは体験しといて欲しいね。

>>4

P2P2ch
http://p2p2ch.web.fc2.com/
ちらしの裏
http://chiraura0.web.fc2.com/

P2P2chはJDKってやつが必要なんですか？
動作用件はJREって書いてあるけど

Bitcloud developers plan to decentralise internet
http://www.bbc.co.uk/news/technology-25858629

Bitcloud: A Peer to Peer System for Sharing Bandwidth
https://github.com/wetube/bitcloud/blob/master/bitcloud.org
http://talk.bitcloudproject.org

お久しぶりです。都合によりしばらく書き込めませんでした。
前スレに登場したノード間ダイレクトメッセージ、面白そうですね。FreenetのN2NDMですね。

>>6
JDKは開発のために必要なツールですね
JREはJavaのプログラムを走らせるためのツールです。

効率の良いＰ２Ｐは匿名性能が著しく悪くなる。
効率の悪いＰ２Ｐは効率が悪いほど匿名性能が上がる。

そんなの明白である。だがマシン性能を使えば匿名度が上がるという
論点のすり替えはよくない。
効率とは応答性能やら無駄な資源の消費度合いのことである。
人を隠すなら人ごみという言葉の通りでどんなトリックを使っても
ほぼ登山者がいないエベレスト登山している１人を隠すのは簡単ではない。

>>9
まぁ"ネットワーク内"に最低3"者"いれば隠蔽は可能だよ。
"中継ノード経路"が3"者"以上で有ることを保証するのは難しいけど、
その保証がなくても確率的な隠蔽は達成できるから、ギリなんとか。

中継するノードがプロキシであり、誰に何を転送してるのかが分からなければ三者である必要性も無い

転送先がビンゴであるかもしれないし、そうでないかもしれない
内容も分からない

それで十分

>>11
でもそれやると転送量が無駄に使われるよね？
ネットワークに負荷を与えているんだけど。

初心者がP2Pやネットワークの基礎やアルゴリズムを学ぶにはどこいけばいいの？

2chの代わりになるものを作るっていう高い次元の話ではなく、
学んどけば将来就職か何かにいかせるかな？っていう学習目的なんだけど・・・。

>>11
二人しか居なかったら「俺が送ったんでなければもう一人」って確定しちゃうだろ。
「誰に何を転送してるのかが分からない」って状況になりうるのが「三人目」だよ。
>>12
隠蔽のための転送と共有のための転送の二段階があるとして、
前者はメッセージ長×隠蔽段階数の転送量(ネットワーク全体)であるのに対し、
後者はメッセージ長×(全共有人数-1)の転送量である。
隠蔽は最小で(Torの場合)3段位なんで比較にならないくらい小さい。
問題が有るとしたら遅延の方(前者がO(n)に対し後者がO(log(n)))だが…
やぼったいプロトコル/フレームワークに依存せずエラーがなければ数秒以下で済む…筈。
>>13
学校的な意味にしろコミュニティ的な意味にしろ「どこか」で学ぶってばかりではない。
ネットワークの基礎はともかく、P2Pなんかの発展途上な部分のある技術は特にそう。
既存の実装を知りその解説を探し関連する技術を知りその解説や論文を探せばいい。

サーバー、クライアント　両用の鳥でおぬぬめは？

15です。誤爆すまぬ
しかもageてしまた。。。

>>14
だれに転送するか分からない状態で、どうやって2人しか居ないと確認できる？
頭悪いなぁｗ

2人しか居ない状態で「だれに転送するか分からない状態」が作れるとでも本気で思ってんのかお前

>>18
「だれに転送するか確定しない状態」とでも

２人しか居なくても、それは短期的の問題のすり替えにすぎない

長期的に２人の外にいる外部者の接続があるのがP2Pであり、その
前提を排除するのは頭が悪い証拠である。

通信する相手が固定で２人だけであるならそれはP2Pの掲示板とはいわない。

>>17
ありがとうございます。
まだ独自研究に行けるようなレベルじゃないのです・・
とりあえずスレの話題に出てるURLに目を通してみます

>>20
今居ないノードに中継させて投稿するとか投稿完了まで何日掛かるんスカ？

間に中継する人がいるとしてさ、
その人が中継しなかったらどうなるの？
書き込みはなくなっちゃうわけ？

それと中継する人は中身を書き換えられないと
思うけどさ、（暗号化しているから）
でも中継する人がやたらめったら、中継しまくったらどうなるの？
一つの書き込み内容を一万個に倍増させるとか。

いや、倍増させなくてもいいか、中継する人が
他人のふりして、自分でどんどん自動送信するとか。

ちょっと図にしてみた。

書き込み先
　　↑
中継者
　　↑
書き込み専用の一万個の仮想マシン
　　↑
評価専用の一万個の仮想マシン

（書き込み専用のマシンの書き込みが
信頼できると評価する専用のマシン
このマシン自体は書き込みはしない）

※評価専用のマシンは、書き込み専用のマシンだけではなく
不特定多数、つまり普通の書き込みに対してもランダムに評価する

>>23
> その人が中継しなかったら
最終到達先は投げられた書き込みをブロードキャストするから、それを監視してリトライすればいい。
書き込みの内容自体にユニークID振っといて、複数経路から書き込みして同一の投稿は無視とかすると失敗率は減る。
> 中継しまくったらどうなるの？
書き込みの内容側に振ったユニークIDで重複・再送を検知すれば何の問題も無く無視される。
トラフィックは増えるからDoS/DDoS攻撃は成立するけどコレはどうしようもない。
>>24
不快な書き込みを評価してるユーザの評価を無視すればなんとかなるんじゃね？

>>26
FDDIだと一定回数巡回して消化されないパケットは自動破棄だったな
中継しなかったらというより書き込み保証をしないが正解だろう
リトライをしても有限で

>>26
> 不快な書き込みを評価してるユーザの評価を無視すればなんとかなるんじゃね？

その評価をするのが誰で、その影響力は誰に及ぶの？

たとえば、俺がある書き込みが不快だといって、
その評価情報が分散してしまったら、

もし俺が不快だといった書き込みが、実はいい書き込みだとしても
その評価がみんなに伝わるんだよね？

>>28
既知の書き込みについて不快な書き込みをNGしてる評価者達が
未知の書き込みについて共通してNGしてるかを検証すれば緩和できるが・・・
そもそも、他人のNG基準に依存するってのはそういうことだし、それに何か問題でも？

あなたとNGの傾向が似ているユーザはこの書込みもNGしています

あなた A:NG B:NG C:NG
似ているユーザー A:NG B:NG D:NG

あなたとNGの傾向が似ているユーザーは
DもNGしています。

D涙目ｗｗｗ

実用化急げ
2ch アダルトが認証しないと書き込めなくなった。
これでユーザー離れが起こる。
このとき互換の掲示板があれば人増える。

>>32
http://next2ch.net/
ここ使えないか？

シェア獲得出来て大人数でも潰れないのが大事。

bbsぴんくが画像認証付きになったとか何とか
そのくらいで離れやしないだろう

Pinkと●を運営しつつ2chに鯖を貸してたNTTechのJimが2chの鯖を乗っ取ったとか云々。
●流出騒動の関連から相当胡散臭い(専ブラ作者に行くはずの金を横領したらしいし)人だし、
2ch側の鯖で●止まった後の対応もだいぶ胡散臭かったからこの先がすげぇ不安な感じ。

マジで全部まるごと潰れるかも分からんね。

PINKはいらねえと思うが収入源になってるなら必要なのかもな

jimが資金難を理由にクーデターめいたことをやりだしたし儲かるなら潰さないだろうね

資金難で儲け口が見つからないと潰れるだろ

1月からなんの進展もないな
まだ開発続けてるの？

普及目指すなら今しかないだろうね

荒らし対策が心配だけど

荒らし対策を備えたバージョン２が完成しました！！！
とやるなら互換性を投げ捨てても大丈夫な気がする

だがいずれ薬物売買厨に占拠されてお上に目をつけられるかもしれない
bitcoinとか見てると後からどんどん規制がうるさくなりそう

やっぱり、あらし対策で詰まってるみたいだな、
キャプチャとかしかないのかね

あらし対策はどうでもいい。
頻繁にされるほどメジャーになるかが疑問。

あらし対策が一番重要だろ、それで人が集まり始めてたLairは過疎った

荒されていないのに、過疎っている掲示板のほうが多い。
荒されてて過疎っている掲示板を見つけるほうが難しい。

あらし対策ができりゃ、Lairのときみたく俺が宣伝すれば人増える
だがあらし対策出来てないうちは宣伝しないよ、俺は

いまこそここに移住しようぜ
take2ch.net

一生宣伝されることはないだろうな

そもそもそんなもん必要かとか思っちゃう常識人なんですけど……
政府の弾圧がある国あるのか……通信の秘密ってのが常識レベルで守られてないと困るね。
アメリカがどうのとか情報も出てるけど、別に犯罪なんかしないし（笑）

２ちゃんねる避難所リンク集を作りました。原発関係のスレのはちょこっとあります。

２ch避難所リンク集(･∀･)bｸﾞｯｼﾞｮﾌﾞ!!
http://jbbs.shitaraba.net/internet/18629/

しっかし、避難所立てたら最低限の管理はしよう。自分のところは管理した後荒らしは来てないみたいだけど。

>>50
運用板でも宣伝してたけど帰って
どうぞ

>>51
よく分からないけど恵まれてる人かい？

>>52
多分君よりは

>>53
そりゃ良かったね。愛情溢れる人であって欲しいってのは高望みかい？

それは望みではなく、すでに叶ってる。

Wiki追記しといたよ

荒らし対策って言うけど、荒らしはどう防ごうが発生するものとして捉えたほうがいいんじゃないかな。
機械判定で防いでも、どの道抜けられるだろうし、各人によっては基準も変わるだろう。
まず全員を受け入れて、その上で荒らしてくる人間を外すしかないと思う。人は外観では分からんよ。

>>57
ID がつくようにすれば、そして IDの付加はクライアント以外で行うようにすれば
嵐はブラウザ側で弾くしかない‥‥

それはIDの付与条件を明確にしないと、IDの生成に使う情報がID(よりも強力な個人識別情報)となって匿名から遥か彼方に吹っ飛ぶ可能性が…

利用者が自分で持つ情報を管理 (自分に必要のない情報を削除したり、必要な情報だけを取得) できることが前提として、
その人が持ってる情報の一部をランダムに要求して、すべて一致していれば同じ人とみなす

それだと、同一人物判定を避けたい荒らしは、毎回違う答えを返せばいいよね。

>>59
クライアントがオニオンネットワークに接続する最初の段階で判断、IPアドレスと日付からつくる従来方法でいい

つまり最初に接続を受けた人が情報バラせば匿名性はなくなる、と
IPと日付だけだと計算式が共有だからIP空間総当りでIP逆算できるからIP強制表示と同等っすね
IP+逆引きだと多少はマシだけどやっぱ逆算できちゃうしなぁ…

>>63
クローラの存在は考えておかねばならないが、ネットワーク全体がIPばらしクローラだけ、という想定は無理がある

＞IPと日付だけだと計算式が共有だからIP空間総当り
過去にさかのぼって日付ごとに総当りを計算とかは現実的とは思えないが

オニオンルーティングって、誰かが情報を送ってきても、その人が発信者なのか中継者なのかわからないってのがキモなんだよ。
でも中継者が発信者のIDを付与するためには、送ってきた相手が発信者なのか中継者なのかを特定しなきゃいけないよね。

起動して書き込んだら一定時間は書き込めないとか
連投できないとか、ソフト側で対処できないんだろうか

自分自身に対して制限する方式だと、荒らしは改造して無効化するよね。
でも他人が発信者に対して制限するには、発信者が誰なのかを特定しなきゃいけないし。

>>64
一度クローラに引っかかるとその日のうちは別のノードに繋いでも意味なくなるから、遭遇率は存在率よりも高くなる
書き込みに使う転送ルートを固定しないと…

そんで、総当り対象の空間が2^32なんて、全然大した計算量じゃないっていう
一回試した事があったが予想外に早くて驚いた
みっちり最適化やGPGPUすれば数分以下で1日分の全ID特定できるだろうし、IP空間を日本に絞るとかすれば一瞬だろう
ストレッチ掛けても知れてるんじゃないか？

>>65
中継時のID自体微妙だと思うけど、中継時にIDを追記してけばそこは回避できるね
書き込みに付与された複数の中継者IDのうちどれが一つが書き込んだ本人のID、的な

>>66>>67
P2Pネットワーク内でノードが書き込み・書き込み中継ノードとして認証されるまでの時間を設けるってのは出来るんでない？
有効化時間を計算するのは周囲のノード側だから、他人に対して緩くはできるが自身に対して緩くは出来ない

連投防止の場合、書き込み・書き込み中継に参加したノードは一定時間それらの権利を失う
・・・とかだと中継コスト高過ぎるか

ちょっとした論点のまとめ
・荒らしを抑えるために書き込みを(頻度的に/内容的に)制限しなくてはならない
・自己に制限を掛ける形式だとプログラムを改造して不正利用される恐れがあるため使えない
・そのため外部から制限を掛ける必要があるが、そのためにはノードと書き込み内容の一致がなければならず、匿名性を危うくする
これを解決しないといけないね

書き込みとログを分けてるみたいだが、荒らしデータはログにも混ぜられるんだよ

>>65
オニオンルーティングは、発信者を隠蔽する次の考え方でいいのかな？
A から B に何かを送りたい場合、

1)B および中継ノード X, Y .... を「最初にAが決めておく」
2)B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手
3)通信内容を公開鍵 Kb で暗号化
4) 3) の結果＋B のアドレスを公開鍵 Ky で暗号化
5) 4) の結果＋Y のアドレスを公開鍵 Kx デ暗号化
6) 5) を X に送る

こう考えると、B が A のIPアドレスを知るのはほとんど無理なわけだがそれでも B が A の ID をつけたいものだ、なにかいい手は？

IPとIDを紐付けするとそのデータが残るんだから時間を掛けれるので必ず解析される

いっそ逆に自分で自分にID振って電子署名するって手もアリなんだよね
前スレでの自己署名云々と相互評価・評価者評価って提案はソレに該当する

>>74
電子署名には認証をつかさどる第三者が必要なのでは？そうなればもうP2Pじゃない

dhtを実装してるんだったら、ログの保証が大事でしょ。ログの改竄をどう防ぐのか？

初回起動時にtime()呼んでseed確保
あとは毎日rand()してID生成でいいんじゃないの
メッセージ内にIDも混ぜておくだけで済むし

ID重複する可能性はあるが仕方ない

悪意のあるハッカーや荒らしの心配よりも。
タイムラグが少なくてレスの同一性とか、
大人数でも耐えられるとか、
幾つか接続が消えてもスレが消えないとか、
掲示板としての最低限度の機能を実現できないと。

ログは暗号化して3分割
A、B、Cとしたら
復元するためにはそれぞれ3つ以上のパーツを3つ以上集める必要がある
AならAで3つ以上、3つのうち2つ以上同じものを有効とする
BとCも同様に集めて最後に復元

この方法なら、誰か一人が捕まったら、
他の人はログを復元できないわけで
犠牲者は一人で済むだろう。

P2P2chではログはレスごとに分割される。
ログに電子署名を付加すれば完全性は担保される。ただし署名を信用するかどうかの判断は別に行う必要がある。多数決とかを使うことになるかも。

話が変わるけど、TCP/IPみたく掲示板機能、データの保持、ルーティングなど各層が分離すればIPアドレスを上層から知られる可能性は下げられる。もっとも現在掲示板とデータ保持で分離しているが。
プログラムを改造されるおそれはあるが、各層を各ノードに分離させるという手段もある。

あくまで個人的な願いだけれど、ここでの議論に書き込む時には名前をつけてくれると助かる。酉まで付けることはないけど、論議が錯綜していて流れが全くわからなくなってきた。

>>75
オレオレ証明書の存在がいい例だけど、電子署名自体には認証機関は不要だよ
電子署名とは、事前に生成した暗号鍵と復号鍵のペアを使い、
署名対象のハッシュを暗号化した値と復号鍵(と付加情報≒証明書)を添付する行為
認証機関は復号鍵と関連付けられた付加情報が正しいことを、
復号鍵と付加情報のセット(証明書)に自分の暗号鍵で署名することで保証する

復号鍵のハッシュをIDとして使う場合、付加情報自体が不要だから認証機関も不要

つまり、電子署名自体には認証機関は不要ただし改ざんした時に注意が必要になる。
改ざんすれば、署名も変わるから改ざんしたことがわかる。
オレオレ証明書の場合は、その署名は俺のもの。として俺は知っているから信用できるし、
その署名が違えば俺のものじゃないとわかる。でもこれは「俺」しか登場人物がでてこないからできること。

さてP2Pにこれを適用するとどうなるか。ファイルに署名が付いている。それ知らない人のもの。
そのファイルが改ざんされれ署名が変わる。それも知らない人のもの。

つまり、ファイルAに「匿名希望Aさん」の署名があります。信用しますか？
ファイルBに「匿名希望Bさん」の署名があります。信用しますか？
匿名希望Aさんって誰ですか？ → 匿名だからわかりません。
ファイルは、AさんとBさんのどちらが作ったのですか？ → わかりません。
ファイルAとファイルB、改ざんされたのはどちらですか？ → わかりません。
という状態になる。そもそも匿名なのだから、署名の信用もなにもあったもんじゃない。

もちろん、一人がファイルも署名も複数で大量に作り放題だから、投票とか評価であれば、
一人が多人数になりすまして行うことは可能。
結局の所、他人がある人になりすますことは出来ないが、ある人が別人になりすますことは可能。
このことから、完全な匿名P2Pによる投票・評価システムは、たとえ電子署名があったとしても成り立たない。

分かりやすく言えば、YouTubeで韓国が動画に票を入れて不正にランキングあげてるでしょ？

匿名P2Pというのは、あれが韓国のしわざであることすらもわからないということ。

完全匿名P2Pだと、大量に票が入っているが誰か全く分からないという状態になる。

ちらしの裏
ちらしの裏は完全分散型のポエム連作支援ソフトです。
ポート開け必須の P2P ソフトであり、2ちゃんねるブラウザを介してポエムの読み書きを行います。
http://chiraura0.web.fc2.com/index.html


新月 - P2P匿名掲示板
http://bbs.shingetsu.info/gateway.cgi

blogban(ω)
おとなもこどももおねーさんも
みんなで作ろう巨大掲示板
今後、ステマや薬物取引のないキレイな巨大掲示板群になり得る『blogban』へようこそ！
http://blogban.net/top.html


alias - Alliance Network - Google Project Hosting
https://code.google.com/p/alias/

Bitcoinじゃないけど、Monacoinってのがあるじゃない。それをIDの代用にできないかなあ。
有用な書き込みにはいくらか心付けをあげられる、みたいな。

有用な書き込みにはいくらか心付けをあげる人が
自作自演だったりするわけだからね。

>>83
なりすましというか自演だな、防げないのは
自演可能な仕様だと単純投票は不可能だけど、同一署名での評価傾向は偽造してもそれが内容になるからそれ使えばいい

↓今考えてる「ぼくのかんがえたとくめいのあらしえぬじーきょうゆうしすてむ」

評価署名と投稿署名を用意して、どちらも定期的に(評価用はより長くてもよいし、複数持ってよい)作り直す事で同定を避ける
評価傾向の一致で評価者や自己評価が同定できないように評価結果のいくらかはマスクする
評価署名は表示後NGした/しなかったという評価情報を公開して、評価傾向が自分とそぐわない評価署名からのは無視する
評価署名を発見してからの経過時間も評価署名の有効性の判定に使ったりすると攻撃がより面倒になる
後ろめたいことがないやつは署名を長めに使うことで署名交換後のブランク発生を抑えられる
新しい投稿署名での投稿は誰かが表示しないと評価が付かないからしばらく無視されるが
投稿者自身の評価署名がランダム時間後に評価するし、スパムメールフォルダを覗く感覚で読んだ奴も評価する
それと古い投稿署名は単純に破棄せず後継者(自分含むランダムな数人)を指名して信用を委譲して評価値を少し稼ぐ

UI的には、評価情報の更新で随時変化する評価値が閾値を超えれば表示するようにして、
(スラッシュドットのスコアシステムみたいな)一時的に閾値を下げる操作も用意しておく
レスの表示順は、表示条件を満たした順を選べるようにしとくべきかな
「表示後NGしなかった」を明確にするために出来れば専ブラ上では非NG操作とか表示時間や表示位置を計測する

この場合、平均的な住民の評価値の閾値を確実に超える量のダミー評価署名を1投稿ごとに使い潰さないと荒らし投稿が出来ない
荒らし投稿をしても実質NGが共有されるから然程経たずにその投稿はNGされて消え去るから、
荒らし投稿の表示状態を継続するには同等の(同一でない)投稿を延々と繰り返せるだけの大量のダミー評価署名が要る
そこまでいくと荒らす側も大変になってくるし、なによりここで使い潰すのは評価署名であって投稿署名ではない
評価署名であれば匿名性は然程重視されないだろうから、
IPなりメールアドレスに対して一定数以下の投稿署名だけ認証する簡易認証局(単なるWebサイト)とか設置して、
気合の入った荒らし対策が必要なスレの住民は住民が維持する簡易認証局の証明書を使って評価署名の有効性を判断する
簡易認証局は同一IPアドレスから一定期間内に一定数以下の認証しか発行できない程度の制限で十分(ダミーは相当数が要る)

>>89
でもそれ、人間がやる場合でしょ？

自演は、自動化して、署名をたくさん作るので
何千人、何万人が評価するんだよ。

しかも一回限りの評価だから
その人が他になにを評価しているかなんてわからない。

ということで、評価が一回のものを省こうとしたら
今度は、他の誰かをランダムに選んで評価することで
評価の回数を増やすことも出来る。

>>90
その手の荒らしが出現した時は簡易認証局を使えばいい
ロガー付き認証局に引っかかっても所詮は評価署名だし無害

普通は荒らし投稿1つに付き複数の評価署名が必要だけど、荒らし投稿自体寿命が短い
意味の有る広告や荒らしをするには大量のIPアドレスが必要だがIPアドレスは有限だ
同一IPアドレスからの認証要求を一定期間無視する簡易認証局を使うだけで効果がある、筈

荒らし対策、個人認証システムよりも、それなくとも2chほどに人集められる方がいい。
2chもあらしの時代を経てバージョンアップしてきたろ。

>>92
気持ちはよく分かるけれど、仕様を2chと同じにしたとして考えて管理能力や安定性、速度、安全性が低いP2Pに人が来るのだろうか……
P2Pのデメリットを出来るだけ潰してメリットを最大に伸ばせる仕様設計をするべきと思うなあ。

匿名性よりも荒らしよりも、1週間前、1ヶ月前、一年前とかの
未取得データをちゃんとP2P上に残せるのか?
あるPCが接続やめたら、取り出せなくなったら使えない。

>>94
え？ 今までの流れって
誰か一人のPCがスレ管理人になるって話でしょ？
書き込みを残すも残さないも、その人次第。

1から作ろうと思ってるんだけど一緒にやりたい人いない？

アーッ！

>>94
私が開発してるやつだと分散して保存される。予備も保存する（ここは予定）。ネットワークから抜けるときもデータの引き継ぎがあるはず。
>>95
あくまでここではつらつら議論するだけで、各実装は酔狂な開発者が好き勝手するスタイルかと。
>>96
何度もその流れになり、結局各人が好きに実装するふうになった。

私も書いてはいるものの、だれかWiki書いてくれよー
スレの流れがわからんちんになるんじゃー

ふたたび2chが止まってるが。
すぐにでも実用化して人集めたほうがいいな。
特別なソフトウェア、ポート開放なしでURL打ち込むだけでつかえるのがいい。

>>72
＞2)B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手
のときに、公開鍵を渡す側で、接続してきたIP を記録しておく（この場合は Kb と一所に接続先を記録する）。
B での復号時はあちらこちらにばら撒いた公開キーを覚えておいての総当りになるが‥‥
まあ期限をきめればいいか。

後は IP4 空間 2^32 の狭さだねえ、IP6 にしますかね

freenetを土台にしたらいい。
使ったことないが匿名なんだろ。

匿名性はいらんからサーバー不要でダウンしない掲示板がいいな

それは自分も思ったが。
少し考えると、ヤバイ、レスを保有・配信しているPCの所有者が逮捕される危険。
ヤバイ、レスを放置しても逮捕されない仕組みがいるだろう。

投稿者の匿名性は別にいらないが。
配信者の匿名性はかなり欲しい所。
どういった仕組みで実現できるのかは知らないが。
レスポンスが異常に遅くなるのはダメだろう。

ビットコインの匿名性と掲示板のの匿名性を比較論議する奴が出てこない時点でこのスレ用済み。
研究系の連中なら論文のタネになるような話だからこんなとこで話さない。

そもそもお前らの欲しい「匿名性」ってどんなものなんだよ？
いつまでたってもそういう基本的なところでｇｄｇｄやってっから何もできないんだよ。

ビットコインは特殊事例だから当てはまらない。
ビットコインのコアというのは用は
一つのデータを複製できないことにある。
コインという簡単に複製できてはいけないものが合って
それを守るためにアルゴリズムが作られている。
匿名性はおまけ。あってもなくてもいいもの。

完全匿名掲示板に求められるものが、いくらでも情報を作れる＋匿名性であるならば
ビットコインの事例は全く当てはまらない。

>>105
こういう低脳、どうにかして欲しい。
結局煽ってビットコインの知識を得たいんだろうけどｗ

まあまあ。
ある論文で読んだんだけど、IPv4（v6でも可）アドレスをハッシュ関数にかけたものと公開鍵をハッシュ関数にかけたものの論理和、つまり
H(IP) || H(PublicKey)を使えばなりすましも防げて確認も容易、みたいな話を見た。
IDからは直接はIPアドレスを知ることができない。

連スマソ。
とりあえずその元になるスライド。
http://www.ietf.org/proceedings/65/slides/plenaryt-2.pdf

もしわかるならば（論文に載っているならば）
確認方法のロジックと論理和のサンプルを示してくれないか？
要望を書き連ねるよりよほど有意義だ

>>100
vをつけろよデコ助野郎

論文にないからちょっと書いてみる

本当はSHA-1だけど簡単のためにH(x) := CRC32(x)とする。
PubKey = 0x12345678
Ipv4 = 0xC0002B0A (example.com)
ID = H(PubKey) || H(Ipv4) = 0x4A090E98 || 0xC1AC256D = 0xCBAD2FFD

nodeA「よろしく　IDは0xCBAD2FFDやで　公開鍵は0x12345678やで」
nodeB「アドレスは0xC0002B0Aか」「ハッシュも合うな」「偽造IDじゃないな」

nodeA「nodeCに手紙を出そう」（いろいろなノードを経由して届く）（ノードの確認とは別の、上の層の鍵で署名する）
nodeC「0xCBAD2FFDから手紙だ　でもアドレスはわからんな」

直接接続するノードのみがノードIDの正当性を検証する。

Q．ビットコインへの各国の対応が異なるが、ビットコイン利用におけるメリットや付随するリスクは正しく認識されているのか。
A．ビットコインは従来の金融／決済サービスに比べて、安価で迅速に資金取引が完了できるメリットがあります。
一方でリスクとして一般的に言われるのは、ビットコインの匿名性です。
匿名でアカウントを開設し取引できるため、マネーロンダリング等に不正利用されることもあります。
しかし、実際には取引そのものは一般に公開されているため追跡できますし、匿名で開設したアカウントでも、最終的にIPアドレスを調べれば利用者の特定は可能です。
http://e-public.nttdata.co.jp/topics_detail4/contents_type=12&id=1040


ビットコイン匿名ですか？
ビットコインは、暗号化メカニズムを経由して、ある程度の匿名です。 しかし、取引はこのように匿名性が大きく、あなたの本当の場所（IPアドレス）を隠すどれだけの尺度である、IPレベルで見ることができます。
あなたはBitcoin取引については、インターネットサービスプロバイダ（ISP）によってあなたに与えられたアドレスを使用している場合、十分な欲求、技術に精通し、かつリソースを持つ誰もが、おそらくあなたをトレースすることができます。
あなたはTorのか、他のサービス経由でIPを難読化した場合、あなたの匿名性が大幅に向上します。 ただし、仮想Bitcoin交換によって駆動現実世界の物理的な取引はまだあなたがオンラインに維持どんな匿名損なわれる可能性があります。
http://www.099978.com/Cracking+the+Bitcoin+Digging+Into+a+131M+USD+Virtual+Currency/article21878.htm


Bitcoin中核開発チームのメンバーのJeff Garzik氏からメールあり。氏曰く、BitcoinはSilk Road生息者が思うほど匿名でもないらしい。
なんでもBitcoinの決済はすべてパブリックログに記録が残るので、関わる人の身元は匿名になるものの、捜査当局が高度ネットワーク分析技術を駆使すれば決済フローを解析し、個々人のBitcoinユーザーを絞り込むことも可能なのだとか。
「大型の違法決済をBitcoinでやろうと思っても、捜査当局が現場で実装している既存の統計解析技術にかかったらひとたまりもありませんよ。かなり無謀な試みでしょう」（Garzik氏）
http://www.gizmodo.jp/2011/06/silk_roadbitcoin.html

オニオンルーティングの実装を考えたり、新しい匿名化技術を考案するスレじゃないと思うんだけど。

>>108>>109>>112
そのページはノードID偽装対策・検証の話らしいからIPの隠蔽は特に重視されてるわけじゃなさげ
CGA variantってのがよく分らんけど、多分、暗号学で||演算子は論理和じゃなくて連結ぽい
参考：http://ja.wikipedia.org/wiki/HMAC

論理和で撹乱しても良いけど、>>62に似てるから問題点も似てくると思う
・公開鍵が判っている場合、論理和だとするとH(Ipv4)のうちH(PubKey)が0になってる桁が公開される
・計算を行ったノードにはID-IPの対応がバレる
・>>65の問題に対応する為に例えば>>68的アプローチを取ると、単一の投稿に複数のIDが付く

オニオンルーティングを調べたが。これは通信経路を隠すやつだな。
中継してる間にレスポンス落ちそう。
暗号化でなく、細分化でいいんじゃないか?
犯罪予告のようなデータを保有しているPCが警察に狙われる可能性が出てくるが。
犯罪予告の一文を10台、100台で分担して保有してれば、警察もそういう仕組みなんだと納得してターゲットにしないだろ。
HDDの多重化のRAIDみたいにできないか。

>>116
「オニオンルーティング系統の方法で匿名化してDHTで分散する」
ってのが今の所このスレで提案されてる方法の基本だと思うが、
DHTの場合データを保持するノードが離脱する事は前提なんで、
普通は複数のノードが同一のデータを保持するよ

犯罪予告の一文が、一台のPCからは取り出すことが不可能なように分割されていれば、暗号化は不要だろ?
たとえば、10台のPCに記録するなら、10バイト飛ばしのデータずつ保管していれば、だれかが違法配信者として逮捕されることはない。
10人だと共犯にされてしまうかもしれないが。
1000人とかくらいだったら、共犯でなくそういうデータ保存方法だと納得してくれて安心かと。





RAID 5
RAID 5は、耐障害性の向上と高速化、大容量化のすべてを実現できるRAID技術である。分散データ・ガーディングとも呼ばれる。
RAID 5では、ディスクの故障時に記録データを修復するために「パリティ」と呼ばれる冗長コードを、全ディスクに分散して保存するのが特徴だ。
http://image.itmedia.co.jp/ait/articles/0102/27/pc-raid5.gif

RAID 6
RAID 6は、RAID 5の改良版といえる技術で、1つのデータ・ブロックにつき2つのパリティを生成する。
これにより、同時に2台のハードディスクが故障しても、元のデータを修復可能としている。この耐障害性の高さがRAID 6のメリットである。
http://www.atmarkit.co.jp/ait/articles/0102/27/news002_2.html

>>118
犯罪予告は投稿が罪なだけで配信は罪じゃないと思う
配信がアウトなのは個人情報とか無修正エロ動画とかだろ
あとその目的の場合、多重化じゃなくて分散化がキモなような…
つか未成熟なDHTじゃないんだしRAIDの説明は要らんだろ
有名だから大概の人は知ってるし、知らん人はググりゃいい

それはそれとして、スレ単位投稿単位より細かい粒度で分散ってのはアリかもな
算術符号的な方法で1ビット以下までバラして保持できたら情報工学的に面白そうだ

2chまとめサイトで、GIFで時間経つと犯罪予告が現れるのを
そのまま乗せて逮捕されたか事情聴取されたのが最近なかったか?
個人情報でも一つのPCから配信してたらヤバイだろ。

まだIPにこだわってんのか
NATにぶらさがってて同一IPになってるのも多いのに

学生が知識自慢したいだけに見える。現実感が全く無いな
今時、固定IPなんて殆どいないというのに

>>121
脳足りんサンｗ

Bitcoinが目指してるのは別に匿名機能じゃないからなぁ。
アルゴリズムで通貨の価値を担保するってことが目的だし。

他の何かを参考にしろ。という意見がどれだけ意味が無いか
まったく目的が違うものは参考にできんよ。

>>118
> 犯罪予告の一文が、一台のPCからは取り出すことが不可能なように分割されていれば、暗号化は不要だろ?

いや、そもそも、その暗号化されてれば万能です。
あらゆる災害から身を守れます。みたいに思ってるのなんなの？（笑）

みんなさ、暗号を万能薬みたいに思ってるでしょ？どう使うかが重要なんだが。

喩え話をするとね。わかりやすいから学校のクラスの話と思ってくれ。
俺と誰かが内緒話をする。その話は周りに誰も居ない所で耳元で
小さな声で話す（つまり暗号化） だから誰にも盗聴されない。

さてこれがほんとうに安全か？

俺は誰とでも構わずこの内緒話をする。相手が匿名だから誰々には内緒とか
制限不可能だからね。さてクラス全員と内緒話をした。暗号化して通信を行った。
さて俺の内緒話＝犯行予告は、暗号化によってなにが守られたというのだ？

>>125
DHTだとその内緒話は同じアドレスに送られるわけよ

同じアドレスに送られるから安全になるのであって
暗号化は関係ないって話だろう？

P2P完全匿名掲示板は
まとめサイトを作るのに適していますか？

書き込みをクリエイティブコモンズの営利禁止にすれば安心なんじゃなかろうか

>>128
それはライセンスの問題だから、P2P完全匿名掲示板であることは特に関係がない
>>129
ライセンス無視する奴は無視するから転載禁止にしたところで実効性が微妙、て意味では安心のしようがない

>>129
各ユーザが自分の書き込みのライセンスを自由に選択出来る仕様にしたらいいんじゃね？

>>112
今更だが乙です

>>132
乙だけど誤解っぽい(>>115)からな、それ

簡単には、
ビットコインは、 データの暗号化
TORは、経路の暗号化
だろ?
データも経路も丸出しで、データの多重化・キャッシュ目的で分散させれば十分だろ。
文書が連続するようにデータ保持しなければ。

これはどうだ?　
グーグル・クラウドサービス、グーグル・ドライブなどがあるが。
P2P上に、一台の仮想スパコンがあるかのように、見せかけるソフトウェア。
その仮想スパコンへのやり取りで、掲示板やWebサーバー機能を実現する。
P2Pだから、全員撤退しない限り、仮想スパコンは消失しない。

すでにあった

グリッド・コンピューティング - Wikipedia
グリッド・コンピューティングは、インターネットなどの広域のネットワーク上にある計算資源（CPUなどの計算能力や、ハードディスクなどの情報格納領域）を結びつけ、
ひとつの複合したコンピュータシステムとしてサービスを提供する仕組みである。
提供されるサービスは主に計算処理とデータの保存・利用に大別される。
一箇所の計算センターや、一組のスーパーコンピュータでは足りないほどの大規模な計算処理や大量のデータを保存・利用するための手段として開発されている。

情弱キモ

ども。
現在鋭意開発中のP2P2chのコア部分がかなり完成してきたので、とりあえず報告までに。近いうちにアップロードします。
とは言っても暗号化とはまだ無縁ですが、これから改良できると思います。

そういえばノード間のダイレクトメッセージを求める声がありましたよね。
簡単に実装できると思うのですが、ちょっとここで思い付いたのですが、切手みたいにダイレクトメッセージを「有料」にしてみたら面白いと思います。
データ転送を請け負うノードが、転送に伴う負荷の代償としてこれを受け取る、といった感じです。
ただbitcoinでは速度が遅すぎますね。

ツイッターが中央サーバー方式であるのが納得できん。
これこそP2Pでいいはずだ。

>>139
ブログのrssを拾えばいいだけのこと

そういえばですけど、P2P掲示板でもスレあたりのレスは1000までにするべきだと思いますか？
技術的には1000を超えたり無制限にすることは可能ですが、制限することでなにかメリットはあるでしょうか？

>>141
パートスレとかではじめて来た人がなるべく新しい >>1 （テンプレとか） を見れる とかかな

>>141
無制限だとアンカーの桁数増えるし、テンプレの確認も面倒になるし、古い話題が延々見えてるってのも鬱陶しい
1000超えたら時間経過毎にレスしづらくする(不可能である必要もない)程度だと自分は嬉しいけど、一般的にはどうなんだろう

天ぷらの更新とかもあるから1000区切りが使いやすいんじゃないの

>>142,143
無制限だとスレの新陳代謝によくなさそうですね。
じゃあ1000区切りというかんじで進めることにします。ご意見ありがとうございました。

続スレ立ての時、通し番号間違いとか防止できるようになんない？

>>146
そこは専ブラの仕事じゃないかな？
できないことは無いだろうけど掲示板に付ける機能とは思えないなあ

>>138
24時間立ててくれるモチがほしいです、電気代とかもかかるしね
ny の機能はつきませんか？

書き込みが改変される可能性も少ない確率である、ってくらいでも
匿名掲示板は成り立つのでは？
その匿名掲示板で固定ハンドルとして活動する場合はいろいろ問題もあるだろうが
匿名なら改変されても被害は少ないだろう

もっと極端な方向性として
改変が簡単に行われてしまう匿名掲示板というのでも構わないんじゃないかと

既存のp2p匿名掲示板でどういうことが起こったか知らないからそんなことが言えるんだよね

>>149 >>151
書き込み改変＝中間者攻撃、を防止するには
�@送信者の公開鍵を確認できる＝送信者特定可能
とするしかないので、匿名を追求する限り無理なのでは？

IDは >>100 でなんとかなりそうだけれども

ちなみにどういうことがあったかというと、freenet, lair, 新月 どれもスパムだらけの壊滅的な状態になったことがある

>>152
freenet, lair, perfect dark など匿名性が高いネットワークでは匿名ネット内での個人を特定できるようにしているね
新月は匿名性が前者と比べると無いようなものなのでスパム元のIPを特定できるし本気で荒らす人がいない

>>154
＞匿名ネット内での個人を特定できるようにしているね
それは公開鍵の改変をチェックできる仕組みかな？

匿名性の意味がごっちゃになってるが、
海外のやつはたいていIDまではわかるんだよ。

ユーザーに対して一つ（もしくは複数）のIDが割り当てられ
書き込みに対して、どのIDが書き込んだかがわかる。

IDから個人を特定する方法を用意していないっていうのが
匿名という意味の本質。

IDまではわかるんで、もし仮にこのIDは俺のですと発表すれば
当然、ある書き込みが俺の書き込みかどうか調べることが出来る。

IDもなにもかもわからないようにしようとするからダメで
逆に言えばIDが分かることを認めてしまえば、中間者攻撃を
防止しながら匿名性を保てる。

もっとも俺は複数のIDを持てるわけで、
AというID ＝ 俺 　　　と判明しても
BというID ＝ 俺？　　かどうかはわからないんだけどね。
つまりAとBというIDを使い分けて、自作自演は可能ということ。

>>152
署名すりゃいいじゃん。簡単なことを・・・

分散保管して多数決チックに決めてしまえばRAIDライクに解決する

ほう、自作自演すれば勝ちとな？

>>157
すまんがその署名が正しいかどうかはどうやって判断する？結構悩ましいと思うけれども

>>100 で A が B の公開鍵を get する段階で、同時に B に自分(A)の公開鍵を送り、それを ID にする。
だめか？

電子署名を使えば、署名と書き込みは対応させられる
公開鍵の改変をチェックとか正しい署名とかは特定の個人やIPと対応させたいということなのかな
それは当然、匿名性を失なうことになる

結局転送途中で内容が変わることは防げないのか‥‥
改変ものが増殖するのは仕方がないとして、オリジナルが消えない工夫はどうすればいい？

>>160
それが、レベル低いっちゅうてんねん

>>164
>>160=>>163

>>165
防げるよ。低脳

>>163
できるだけ広く拡散して、多くのノードで保持するしかないんじゃないかな。
掲示板のレスなんて容量小さいんだから、全ノードが全レス保持するくらいの勢いで。

>>149
自分自身の同一性を証明するのは簡単だよ、極端なことを言えば本文に手でPGPかなんかの署名するだけ
>>152
いくつか誤解がある
書き込みの改変は、投稿後の改変と投稿時の改変の2つがある
投稿後の改変は追記型のネットワークDBにしておけば、データ保持者全員が結託して改変・消去しない限り問題ないし、
そのうえで投稿単位のデータについて名を値のハッシュにしておけば、名の一覧以外は結託しても消去しか出来ない状態にできる
別の署名をしたコピペを逐一ポストされると区別が難しくなるけど、署名を先行して送信するとかで回避できんこともない
投稿時の改変については受信者の公開鍵を正しく入手さえ出来れば、投稿時の改変はできなくなる
中間者は投稿文を読めないので破壊や消去しかできないから、単なる不達が起きるだけで済む
送信者としての公開鍵は自分から同一性を証明するために必要なだけだから、破棄したければ破棄すればいい
あと>>100のやり方だと実質IPが全部筒抜けだからあんま意味ねぇんだよな…
>>163
単純送信なら送信先の公開鍵で暗号化して送れば変造不能
情報取得なら、自分の使い捨て公開鍵と要求情報を最終相手先の公開鍵で暗号化して送れば変造不能
不達や消滅は起こりえるけど、変造それ自体は防げるよ

>>168
ネットワークDB ですか‥‥当方には新しい概念だから少し調べてみる

後半
＞単純送信なら送信先の公開鍵で暗号化して送れば変造不能
その送信先が改変意図を持っていたら‥‥

前提として多数のノード間での単純なバケツリレー（あるいは投稿単位交換）を想定していた
投稿者の最初の送信先が悪意をもったクローラで、そこで改変して次のバケツに渡すとき、次のバケツでは改変を検出できないものかと
投稿者が秘密鍵で投稿単位(かそのハッシュ）を暗号化、それと一所にオリジナルのＩＤ＝公開鍵を渡すのであれば、バケツリレーの先でもチェックは可能かな
公開鍵すら変えると成りすましが成立しなくなるから。

>>100 は送信経路の撹乱と接続先でのIDの付与が目的だから、目的の送信先にIPが筒抜けてるのもやむを得ない。
目的の送信先が悪意を持ち、IPとID=公開鍵の紐付けを謀ったり出来る可能性が生まれるのは認める。それを他のバケツに記入改変して転送、とはいかないだろうが
となると、改変された投稿単位をどうするか、だが、悪意を含む可能性のある投稿単位消すか‥‥オリジナルは失われるな‥‥

なんか公開鍵暗号と電子署名の公開鍵がごっちゃになりそうな気がするんで一般的な暗号の概要

■暗号学的ハッシュ関数
元の文章からハッシュ値を求める関数
与えられたハッシュ値から元の文章の特定が困難
与えられたハッシュ値と同一のハッシュ値を持つ別の文章の作成が困難
同一のハッシュ値を持つ複数の文章の作成も困難(現在、MD5はこれを満たせない)
■共通鍵暗号
暗号化と平文化に使う鍵が同一、処理が早い
■公開鍵暗号または電子署名
暗号化と平文化に使う鍵が同一ではなく、暗号化鍵と平文化鍵のペアを使う
通常は処理が遅いので、ハッシュ値や使い捨ての共通鍵暗号の暗号鍵を対象文の代わりに使用することで高速化するが以下略
■公開鍵暗号
暗号化鍵から平文化鍵が求められない場合は、公開鍵暗号として使用できる
通常は、暗号化鍵を公開鍵として公開して、平文化鍵を秘密鍵として保持する
送信者は公開鍵を何らかの手段で入手・検証し、公開鍵で暗号化した文章を受信者に渡し、受信者が秘密鍵で平文化する
高速化のために実際は共通鍵暗号を使い以下略
■電子署名
平文化鍵から暗号化鍵が求められない場合は、電子署名として使用できる
通常は、平文化鍵を公開鍵として公開して、暗号化鍵を秘密鍵として保持する
送信者は秘密鍵で文章を暗号化し、受信者は何らかの手段で入手・検証した公開鍵でそれを平文化することで検証とする
なお電子署名の場合は暗号化の処理を署名と呼ぶ事が多い
高速化のために実際はハッシュ値を使い以下略
■認証局
公開鍵暗号や電子署名を補助するシステム
公開鍵に付随する何らかの情報について記した文章を認証局の電子署名秘密鍵で署名して配布する
利用者は何らかの手段で入手・検証した認証局の公開鍵を使い、証明書に記された内容が認証局に認められているかを検証できる
■証明書
何らかの内容を何らかの電子署名で署名したもの
通常は文章ではなく、何らかの署名とそれに付随する内容が記されている
検証する者にとって未知の認証局の署名しか行われていないものをオレオレ詐欺と同様にオレオレ証明書と呼ぶ

>>169
> その送信先が改変意図を持っていたら‥‥
もちろん変造されうる、けれどそれは実質消去された(不達が起きた)上で同じ時刻に送信先が直接投稿したのと同じ
投稿文の識別番号に本文ハッシュを含めれば変造された投稿を元の投稿と誤認させる事もできず不達しか起こせない
最初から複数に送ればいいし、送信先から新着取得して握りつぶしていることを確認したらその送信先は捨てればいい

> 次のバケツでは改変を検出できないものか
投稿文を識別するID(識別番号、投稿者識別のIDでは無い)の一部にハッシュを使うだけで大丈夫、暗号化は不要
成り済ましの防止は最悪GnuPGとかで本文の中に署名を打てばいいだけだから伝送のレイヤで考える必要はない

そういえば、DHTでハッシュが衝突したらどうします？

はじけ飛びます

>>172
普通のハッシュテーブルと同じく連結リストの後ろに追加で良いんじゃね
その場合キー＝ハッシュだと不都合があるからサブキーも持たせといたほうがいいかも知れん
DHTのノードID(≒ハッシュ)が衝突したら>>173ほどじゃないけど残念な事になるだろうな

>>174
スレッドを特定するのがUUIDで
UUID＋メッセージNo + MAC
を電子署名するでなんら問題ないと思うけど

なんで偽造できるMAC？

理想を言えば

H( UUID + メッセージNo + UnixTime(書き込み時間) + PrivateKey(書き込み者のRSA秘密鍵 ≠SecretKey　)　)

を署名すりゃ良い

>>176
ちみの言っているのは、
Media Access Control

俺が言っているのは
Message Authentication Code

そういえばスレのハッシュをhとしてハッシュ関数をHとしたら、レスが付くにつれてレスのIDをH(h), H(H(h))...みたくしたら自動的にスレの同期が取れるんじゃないかな
どうだろ

>>179
そういう仕組みは既にある

Message１
Message２
Message３
Message４

とあった場合、

ｈ1　＝ H( Message１ )
ｈ2　＝ H( Message２ )
ｈ3　＝ H( Message３ )
ｈ4　＝ H( Message４ )

とする

全体の完全性(I)を保障するためには

h-a = H ( h1 + h2 )
h-b = H ( h3 + h4 )

h-c = H ( h-a + h-b )


みたいな

>>170 >>171
＞電子署名
＞GnuPG
これは送信元がはっきりしており、「いつでも」送信元から公開鍵を入手できる場合に実力を出すと考えたいね
今は匿名下、または部分的に匿名な状況で、それでもバケツリレーの中で投稿単位の改変を検出して捨てることを考えている

＞投稿文の識別番号に本文ハッシュを含めれば変造された投稿を元の投稿と誤認させる事もできず
投稿文の識別番号も改変されたら結局オリジナルは失われる、

が、結局
＞投稿文の識別番号
＞最初から複数に送ればいい
まあそういうことか、「最初から複数」かな。

考えるまでもなく、匿名性と書き込みＩＤの一貫性は矛盾する。
考えるべきは、ＩＤが正当なものは低コストで済み、ＩＤの乗っ取りを企てる者には馬鹿高いコストの仕組み。

そこの現実的な解が無い状態。
というか、匿名なんだからＩＤ無しでもおｋじゃね？

>>182
SPAM は専用ブラウザ機能で、でいいから弾きたいねえ、ID を使って

>>183
それは普通にベイジアンフィルタでいいでそ

2chと違うだろ。
匿名かつ、可能な限り、IDを保持させることは可能だろ。
IPアドレス、接続名がそのままIDになったらバレてるがそれはIDではない。

ベイジアンフィルタにかからないSPAMってあるじゃない、QZの投稿とかさあ‥‥

MACアドレスを暗号化(ハッシュ化)したらIDに使えないか
荒らしもそれで弾けばいいんでは。





MACアドレスとは、個々のネットワーク機器を識別するための装置固有の物理アドレスです。
個々のネットワークアダプタに割り振られており、またこれは世界で一つしかないアドレスです。
同じマックアドレスのネットワーク機器は存在しません。IEEE（※参照1）により管理されています。
http://www2.chuo-u.ac.jp/com/support_qa/yougo/yougo3.htm

MACアドレスが届くのは最初のルーターまで

>>185
>>68 で指摘されている、つまり IP(+日付）のハッシュならレインボーテーブルで一発でIPを特定できる、と
なにかいい ID の生成方法はないものか？

送信する側が発信すればどこまでも行くだろ。書き込み+暗号化したMACアドレス。

>>187
実は MAC なんて自由に変えることができるのです
realtek RTL8019 とかはそうだし、Windows のデバドラでも変えられるように作っているものも多いし

>>190
送信側の申告は信用しない

IPだと、総当りで計算されるってことか。
日付+IP+MACくらいにしたら桁増えるが。

少なくとも毎回書き込み時に偽造してくる強者は除き、普通の荒らしは弾ける。
1割、MACかハッシュ偽装だったら9割は弾ける。

2chの忍法帳システムも自己申告制だろう。
偽装できるから使えないんだったら、これを導入し続ける意味は無いはず。

忍法帳ってクッキーを正しく送らないといけなくてクッキーはIDとパスワードがあわさったものになってるんじゃ

>>195
忍法帳システムが有効なのは、
サーバーに書き込みが行われて（つまりP2Pではない）
プロキシサーバー経由の書き込みを弾いている（つまりIPアドレスチェック）
からなんです。

特に「プロキシサーバーを弾く＝本当のIPアドレスを知ろうとしている」という機能は
IPアドレスをわからなくするという匿名と組み合わせるのは不可能なんです。

>>194
SPAM 屋さんだったら自動で MAC をコロコロ変えるプログラムを作ると思うよ‥‥
1割、というのが投稿数のことだったら、その見積もりは甘いと思う‥‥

忍法帳のクッキーはお上からの賜りものだろう？つまりサーバーの存在が前提だから P2P ではないと思うんだ

>>193
でも IPの偽装は困難だから ID の生成法としては有望なんです
ネットワークにソルトを浮遊させる、とかはどうでしょうかね

一列射撃問題、みたいなのはないかなあ

> でも IPの偽装は困難だから ID の生成法としては有望なんです

プライベートIPアドレスのことだよね？
簡単だけど？

グローバルIPアドレスは、IDを生成する側はわからない。（ルータが持っていたりする）
サーバー側でならわかるから、２ちゃんねるはプロキシサーバーを禁止して上で
アクセス元IPアドレスを取得しているんだ。

でも、匿名＝プロ機西によるIPアドレス隠蔽を使うならば、
サーバー側でさえもIPアドレスは取得不可能になってしまう。

忍法帳システムはP2Pでも可能では?
荒らしや違法な書き込みをするやつ、一般人のIPはばれてもいい、
データ保持してるやつのIPはばれては駄目というのは可能では。
初回書き込みで、ネットワーク上の少なくとも1台がIP見ながら忍法帳データのようなものを発行。

P2Pネットワークを監視し続ければ書き込みとIPが特定できたとしても、
過去レスに対してはIPがばれたり、発信しているPCがばれないようにはできるだろ?

>>201

まず、プロキシによるIP匿名化を行うのであれば、
どのマシンもIPアドレスはわからない。

> 荒らしや違法な書き込みをするやつ、一般人のIPはばれてもいい、
コンピュータが書き込み内容を違法かどうかなんて判断できないので
つまり、全員のIPアドレスはばれるということになるね。

> データ保持してるやつのIPはばれては駄目というのは可能では。
データ保持するには、適当なダミーデータを保持すればいいだけ。
データを保持しているという偽装は簡単。

匿名化をやめるという前提でIPアドレスはわかるとしよう。
（その時点でスレタイの完全匿名掲示板は無理ということだが）

> 初回書き込みで、ネットワーク上の少なくとも1台がIP見ながら忍法帳データのようなものを発行。
その1台が嵐の仲間だったらどうする？

> 過去レスに対してはIPがばれたり、発信しているPCがばれないようにはできるだろ?
過去レスのIPアドレスがわからないってこと？ ならば過去レスを監視することは出来ないってことだね。

既存の○○システムで実現できてるから
それと同じものを搭載すればいい。で
思考停止しないでくれ。

それとは別のものなんだから。

「P2P型の完全匿名掲示板」という条件があるために
既存の○○システムを取り入れるのは
不可能か困難になるんだからさ。

>>181
＞これは送信元がはっきりしており、「いつでも」送信元から公開鍵を入手できる場合に実力を出すと考えたいね
＞今は匿名下、または部分的に匿名な状況で、それでもバケツリレーの中で投稿単位の改変を検出して捨てることを考えている
勘違いしてないかい？
公開鍵を入手する経路は、たとえそれが信頼を置けないノードであっても構わないんだよ

＞投稿文の識別番号も改変されたら結局オリジナルは失われる、
>>177 をよく読め

＞まあそういうことか、「最初から複数」かな。
これも勘違いしてないかい？
保証したいのは、ノードではなく、メッセージなんだけど？

>>182
うん、
投稿者が、唯一のその投稿内容を、その時に、その人だけが作成でき、証拠がのこれば、IDを保証する意味は無い

>>191
つか、俺の知っている限り、MACを変えられないOSを知らんがなｗ
SolarisだってBeOSだってMacOS Xだって、漢字talkだって変えられる>>199

>>199
＞ IPの偽装
容易だよ

情報伝達が確実で検証可能ということは、それは完全な匿名にはなりえない。
不完全伝送こそが完全な匿名である。

なんでエラーチェックとかするの？なんで中身を復帰したあとに
確実に戻せたかチェックできるの？

>>205
そうでもないよ

>>175
DHTはノードIDとキーの2つがあって、どちらもハッシュ長でハッシュと絡めて生成する値なんだ
DHTではキーやノードIDに生の値を使うと破綻しやすくなり攻撃耐性下がるから、生値はあまり使えない
値のハッシュ値をキーにするような構成の場合値中の一部をサブキーとして持たせるとかってのが前半
後半はピュアなハッシュ値ノードIDのDHTの場合で、部分的に生IPをエンコードするとかの対策に繋がるネタ
>>177
最後の項が物凄く不穏なんだけど…署名ってことはその項は検算用に公開しちゃうんだよな？
>>181
掲示板上の投稿としての成り済ましに対しては、トリップと同じで同一性さえ示せばいいかなと
>>182
トリップ的に電子署名を使えば乗っ取りは簡単に防げる
匿名のために署名を乗り換えた時や新規参加時にどう信用を獲得するかは課題だけども…
>>187
自由に変更できるし実は結構被っている(不正なベンダIDや、古いMACの再利用が有るらしい)
ルータ境界を越えられないって制限があるからまず問題が表面化しないというだけ

>>192
現代暗号とかはわりとそういうところがあるんだが、または信用出来ない事を前提に設計するしかないね
>>194
それも当初は有効だと思うけれど、どーせそのうち不正改造版が出回るって想定した方がいい
>>199
>>91も最終手段的にそういうアイディアだし、ID生成サーバみたいなのを設置するのは有りだけど
常時それにしか頼れない仕組みではそのサーバの運営者が匿名性を保証しないと駄目なんよ…
上手く適用できる秘匿計算アルゴリズムがあればいいんだけど
>>200
ローカル計算に依存してたら只の自称でMACアドレスと同じで無意味じゃない？
IPアドレスを使う場合、外部(相手や認証局)から観測することでそれを保証するしか無いと思う
>>201
忍法帖云々とか関係なく、データ所有者を隠蔽するのは独立して実現できる
それと、その方法でIDを保証する場合「少なくともN台」ノードをエミュレーションすれば幾らでもIDを偽造できる
N台をネットワーク上のN%とかにすると、小数のクローラを設置するだけで全ID-IP対応をロギングできてしまう

>>207
＞最後の項が物凄く不穏なんだけど…
大したリスクにはならんよ。それがMD5だとしても

>>204
＞公開鍵を入手する経路は、たとえそれが信頼を置けないノードであっても構わないんだよ
今は匿名性に比重を置いているのだから、公開鍵の入手先はどうするか、という問題はどうするか？

＞＞ IPの偽装
＞容易だよ
winny にプロキシをかまして偽装する、とかは聞いたことがないんだが。
ブラウザのIP偽装は簡単だが、プロキシ対応していないアプリがごにょごにょやるとき、そいつのグローバルIP を偽装する方法はあるのか？

>>210
は〜あ・・・

＞今は匿名性に比重を置いているのだから、公開鍵の入手先はどうするか、という問題はどうするか？
別に持ってくる必要があんのか？


言っても分からんと思うけど・・・

電子署名　≠　署名

だかんね。

>>210
＞そいつのグローバルIP を偽装する方法はあるのか？
いくらでもある

一旦話を整理しましょうか。
☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
☆電子署名には幾つかの手法があるが、PGPなどの自己署名する形式の署名は幾らでも作成でき複数の投稿を複数の署名で行うことにより自演できてしまう。
☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。

☆ID（署名）でできること。

ある書き込みに署名Aと書いており、
別の書き込みにも署名Aと書いている。
どちらも署名Aだから同一人物であることはわかる。

なぜなら赤の他人が署名Aを作ることは不可能だから


☆ID（署名）でできないこと

ある書き込みに署名Aと書いており、
別の書き込みにも署名Bと書いている。
この二つの書き込みをした人が別人かどうかはわからない。

なぜなら、一人が複数の署名を持つことは可能だから。

「☆ID（署名）でできないこと 」
に関して、２ちゃんねるとの違い。

2ちゃんねるでは、このスレでもそうだが、IDがでてる。
このIDによって、２ちゃんねるでは自作自演が難しくなっている。

たとえば、俺の今のIDとは違うIDにしたければ、
回線を複数持つか、一旦回線を切ってIPアドレスを変えないといけない。

この２ちゃんねるの仕組みと同じことをP2P型完全匿名掲示板でも出来るかといえば、できない。

なぜなら、２ちゃんねるはIDを発行するのは２ちゃんねるのサーバーであり、
P2P型完全匿名掲示板では、IDを発行するものがいない。
誰かがやるとしても、その「誰か」を自分自身がやることで好きなIDを作れる。
ID発行サーバーを作るならば、それはP2Pの完全匿名掲示板にはならない。

また、２ちゃんねるのIDは、IPアドレスを元に算出しているが、
P2P型完全匿名掲示板はIPアドレスが隠蔽（別の人のIPアドレスになる）される。
ID発行サーバーへはIPアドレスを隠蔽してはならないという制約をつけると、やっぱりP2P完全匿名掲示板にはならない。

だから２ちゃんねると同じ仕組はできず、自作自演を防ぐ効果は著しく低くなる。

>>210
> winny にプロキシをかまして偽装する、とかは聞いたことがないんだが。

winny の「中継」という機能は「プロキシをかまして偽装する」行為そのもの
Winnyの匿名性というのは、プロキシ機能によるもの。

相手のグローバルIPがわかってしまえば、匿名性が無くなる
だから中継（＝プロキシ）によって匿名性を保つっていうのが
匿名技術の本質。Torも同じ仕組。

だから、相手のグローバルIPアドレスはわからない。
偽装以前に、相手のグローバルIPアドレスは、わからないんだよ。

だから２ちゃんねるは、相手のグローバルIPアドレスをなるべく確実に見つけるために
プロキシサーバーの利用を禁止して、匿名（IPを知らせない）での書き込みを禁止している。

>>215
時間同期型のトークンを無作為生成するだけで対処できると思うが
発行サーバーはいらない
問題はこのトークンが改変されない仕組みを作り出せるかどうかだけ
IP依存にする必要がなくなる

極めて低確率でトークンが同一になる可能性はあるがそれは仕方ない
おそらくトークンのジェネレータを不定期に変更する権限を開発者が持つ必要がある
そしてそれが実行されたか知られないようにしなければいけない

>>217
それはID発行システムをブラックボックスにするという発想だと思うけど、そういうのは下策だと思う
匿名だと信じていたら実は解析されていた、なんてことになると今の2ちゃんと同じ状況になる

秘密鍵をコロコロ変える行為にペナルティを課すことにすればいいんじゃないの？
たとえば新しく生成されて自分が見たことのない秘密鍵で署名された、
署名チェインのないレスを送ってきたノードへの接続を制限するとか。
他人のレスに署名チェインを追加して転送する回数が増えるにつれ信用を上げていく感じ。

>>219
そこをどうするかということを模索することになると思うけど、ベストな方法は無いと思う
複数の方法を実装できれば荒らされたときに慌てずに済むんじゃないかな

>>218
解析される可能性があるのはやむを得ない
匿名性を守ろうとすればどうしてもそのリスクは受け入れざるを得なくなる

解析されるかもしれないから却下ではなく
解析がとてつもなく厳しいものになればいい
あるいは解析されたとしてもお手上げになるように

具体的にはP2Pコネクションを行っているプロセスA
トークン管理をしているプロセスB
そして第三者のプロセスC
A-B,B-C,C-Aでプロセス間通信で監視しあい、誤った暗号ブロック（クラックされた可能性がある）が送られた場合は即時停止
リポートを流し開発者に伝える

>>213
どこが整理やねんｗ
なんもわかっとらんし

＞☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
うんにゃ
MICでもMACでも電子署名でもハッシュだけでも可能


＞☆電子署名には幾つかの手法があるが、
＞PGPなどの自己署名する形式の署名は幾らでも作成でき
＞複数の投稿を複数の署名で行うことにより自演できてしまう。
CA建てるならP2Pじゃなくなるね。

＞☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
PKIじゃなくてもOK

＞☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
うんにゃ
ネットワークに参加しているメンバーのIPが特定されても実現は可能だよ

＞☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
そうなん？？？
改ざんが検出されたものは転送せずに破棄すりゃいいじゃん
正しいデータを読み出せる必要は無い

>>217

>>177

＞＞☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
＞うんにゃ
＞MICでもMACでも電子署名でもハッシュだけでも可能

確かにそうです
至らない点がありました

＞＞☆電子署名には幾つかの手法があるが、
＞＞PGPなどの自己署名する形式の署名は幾らでも作成でき
＞＞複数の投稿を複数の署名で行うことにより自演できてしまう。
＞CA建てるならP2Pじゃなくなるね。

P2P上で、あくまで自動化された鍵の生成と認証をするのみにとどまります。

＞＞☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
＞PKIじゃなくてもOK

何かありますか？

＞＞☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
＞うんにゃ
＞ネットワークに参加しているメンバーのIPが特定されても実現は可能だよ

書き込んだ人のIPアドレスの話をしています。

＞＞☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
＞そうなん？？？
＞改ざんが検出されたものは転送せずに破棄すりゃいいじゃん
＞正しいデータを読み出せる必要は無い

可用性は出来るだけ上げるべきではありませんか。分散保存される場合は改竄を破棄するとかなりの打撃になります。

＞P2P上で、あくまで自動化された鍵の生成と認証をするのみにとどまります。
何を認証するのかが不明瞭なんだよ
話の流れでは、メッセージを認証しようとしているけど、
ここではIDを認証しようとしている

ちぐはぐ

＞何かありますか？
無理にCAを建てることもあるまい


＞書き込んだ人のIPアドレスの話をしています。
今でも十分書き込んだ人のIPアドレスかどうか分からなくなっているだろ？
なぜ、それでも、分かるんだ？
・転送した記録が各ノードに残る
・要求内容とIPアドレスに紐付けがされる
・転送内容をノードが理解できてる
・フルキャッシュを持っているノードが特定できる

だろ。
あとは良く考えろ


＞可用性は出来るだけ上げるべきではありませんか。分散保存される場合は改竄を破棄するとかなりの打撃になります。
ナンセンス
改ざんされたデータは、ゴミ以外の何者でもないので、即時破棄の方が可用性は向上する

>>219
新しく登場した署名は暫く信用しないってだけで十分だと思うというか、
そこにノードの接続性まで絡めるのはなんか違う気がしてならない
ノードの信用(及び署名+公開(暗号化)鍵)と
投稿者の信用(及び署名+公開(暗号化)鍵)は
分けて考えたほうが良くないか？
>>221
いずれ解析される前提で考えないと不味いって話でしょ
解析されるまでの間は有効に機能するとしても、
解析された後に全滅するしか無いシステムじゃ不味い
>>223>>177
ちょっと式の意味をもうちょい詳しく頼む
秘密鍵(SecretKey)≠SecretKeyとかPrivateKey関数の意味とかよく分からん

>>226

>>177で話されていた内容は、メッセージのIDをどう作るか

Secret　：　秘密情報
SecretKey　：　共通鍵方式における秘密鍵
PublicKey　：　公開鍵方式における公開鍵
PrivateKey　：　公開鍵方式における秘密鍵


秘密情報(Secret)やユニークなID　と　メッセージを関係付けるのは、良い考えかただが、
公開鍵の持ち主との関係が希薄になる。
重要なのは、

○そのとき
○そのスレで
○そのメッセージが
○その公開鍵ペアを持っている人
のみ、IDを作れられなければならない

H(　)　はハッシュ関数の意味

なんてーか、ネットワークを構成するレイヤと投稿やデータ交換を行うレイヤを区別しようぜ

>>213
> ☆1
署名が要るのは成り済まし防止(同一性の証明)の時
> ☆2
実装や認証のツリーが違うだけで仕組みは大差ない
> ☆3
署名の複数所持を認めるなら不要
>>224
> 書き込んだ人のIPアドレスの話
ネットワーク構成レイヤでの参加者IPアドレスは隠したら通信できないので不可能
参加者IPアドレスの中で投稿やデータ交換したIPアドレスを隠すのはオニオンルーティングなどで可能
投稿者IDないし署名の複数所持を認めずその為にIPアドレスを使う場合、上手く設計しないと匿名性が薄れる
> 改竄を破棄するとかなりの打撃
改竄された領域は通常本来のデータを意味しないので、そこから意味有るデータを読み取ろうとしても無駄
改竄に参加していないノードから情報を回復した方が良いし、それにはできるだけ早く破棄したほうが良い

DHTに格納するデータとしてのキー(ハッシュ値)の衝突の話(>>172>>174)から行くと、
キーを>>175の生値にするとDHTが機能不全を起こすし、>>177だと結局ハッシュが衝突しうるよね？
あと、そのキーが正しいもので有ることを検証するためには(DoS的スパム(≠投稿スパム)の排除)、
ハッシュ関数の入力をそのデータ内で公開する必要があるから検証してる場合には使えない気が
ストレージとしてのDHTは恣意的なキーを使うと容易に死ぬし、
ハッシュだから念のために衝突対策(例：リスト)が必要になる
衝突時の区別に使うサブキーは…ぶっちゃけ何でもいいけど

なんだけど、DHTに格納するキーとしてはその値を署名云々とか何の意味があるのかよく分からんのよ

>>228
> 改竄に参加していないノードから情報を回復した方が良い
すみません、そういう意味で言っていました。

>>229
値が変動すればキーも変わらなければならないのですが、たまに同じハッシュが生成されてしまう場合があるのです。
DHTではデータが多数のノードに分散されて配置される。
データを担当するノードはそのデータに手を出すこともできる。
それを検出する機構が必要になるってことですね。

>>229
コリジョンが発生するのは、同一スレッド内だけだから、
死ぬまで使ってもコリジョンしないよ。

改竄されたところでそれが重要なこととは思えないが。
同時性は大事と思うが。
あるPCには見えるものが、離れてるPCでは見えないとか。

>>232
ユーザ側の「勝手な」要望としては、そうだろうね。

ただ、P2Pの性質としては、同一スレッドを参照書き込みしている人達にはより早く
そうでない人にはそれなりに、

ってなっちまうと予測

スレを収集するフェーズで、よりプロバイダとの距離が近い者ほど早く
ってな実装にすると、パフォーマンスと要望が満たせる
んが、同時性は明らかに損なわれる


ところで、読んでさえいない2chのスレッドに同時性を求めるのかい？

読んでるスレッドを更新して、PCごと差が出て10秒以上内容がずれたり、いくら待っても内容が届かないとかは重大な問題。

>>231
それはつまりスレッドごとにDHTネットワークを構築するってこと？
それならコリジョンはまず起きないだろうけど…

>>235
スレッドのメッセージIDの話をしてんだから、それで問題ないだろ。
そもそも、だ、
自分に関係のないスレッドのメッセージを一意に特定する意味があんのか？

欲しい情報は、
このスレッドの、このメッセージ
じゃね？

スレッド一覧は、ShareやWinnyのようにハッシュで管理すりゃいいだろうし、
分散ハッシュテーブルでも構わんと思うよ。

その中のメッセージがシステムWideで一意のハッシュ値である必要性がどこにある？

>>234
無茶苦茶起こると思うよ
実装次第だけど、俺の頭ん中の実装だと、過疎スレは非常にレスポンスが悪い
逆によい傾向じゃあねぇか

>>236
DHTネットワークのモデルって単層のキーバリューストアだから、
それをスレッド数だけ多重化するとは思わなかったんだよ・・・
DHTネットワークを多重に構成する場合のコストって何十と稼働させても平気だっけ？

>>238
なんか問題ある？

「多重にうんぬん」の時点で分かってない気がするのは俺だけかな？
多重に云々 が起きる事態なら、それを捨て置けば良いんでなくて？
そうすれば、人気のあるハッシュがより拡散するんでなくて？
どうしてもレアなものをゲットしたいのなら、そのノードが頑張るんじゃないの？

>>177 のようにハッシュに秘密鍵を入れる必要もないわけだが
お前が一番わかってないから他の人の話と合わないんだろ

>>239
んん？スレッド単位でDHTに格納してく場合のスレッド内でのメッセージIDの話で、
メッセージ単位でDHTに格納してく場合のメッセージIDの話ではないって事？
読み返したら>>236でDHT前提にしない事も考えてるみたいだけど、
>>229でも書いたように元はDHT格納時の衝突の話だから、
衝突を考慮するID振り当て対象はDHT格納単位の筈なんだが…

>>240
ハッシュに秘密鍵を入れる理由が理解できないお前がアフォなんだとよくわかるレスだわ。
どうぞ、セキュ板だろうと、ネットワーク板だろうと、拡散してくださいwww

>>241
なぜにスレッド単位にしない？
UUID+メッセージIDで充分だろ？

折角分かってるなら説明してあげればいいじゃないか

むしろ、拡散されて、バカが釣れるほうがオモロいんだが

秘密鍵が元に入ってるハッシュと適当なランダム文字列と、他人がどう見わけるの？
これでそんなことをする意味がないことがわかりるだろう

ID変わってるけど>>240な

P2P上に仮想データベースを作れ。
追記とリードのみ対応。
各記録ブロックは5-10台程度で保持。
さらにおまけでP2P上にビットコイン採掘を同時に行い電気代回収。

ん…だからさ。

PKI は論外。アングラ世界で「信用の輪」を広げようったって駄目。原理的に無理。
「とりあえず○○さんを名乗る人からこの書き込みを受け付けました。責任は持てません」ということを多数決で事実確認するのが関の山。

どうせ保障も責任なんて誰も何も取りようがない。
降水確率よろしく、「この書き込みが○○さんである信頼性は××％です。なお、東アジアのノードには改竄警報が出ています」ってくらいでいいんじゃない？
クソみたいにアバウトにやった方がいい気がしてきた。

○○さんは、100人の人から信用できると言われています。


（その100人は、すべて○○さんが作ったアカウントです）


匿名である以上、一人が複数の人を演じることは防ぎようがないからね。

論外ではなくて、その「多数決で事実確認する」ということもPKIの一つの実装だろ？

>>250
そのノリでいいんじゃない？
第三者に拠り所を敢えて求めないならそのノリしか無いと思う。
ていうか、マロユキの「嘘を嘘と…」という言葉は結構名言だわ。
あいつ大嫌いだけど、匿名性を求めるなら何らかの妥協は必要だ。
「完全」「匿名」「IDの一貫性」のどこかで何かをある程度で捨てなきゃならんはずなんだが…。
何をどの程度、となるとスレで合意が得られるものでもあるまい。匿名性の限界は色んな意味でそこにある。

>>251
ねーよ。てめーこそ論外だ。
保証人のいない PKI なんか存在しない。逆に、保証人がいるからこその PKI だ。何のための公開鍵「基盤」なんだよ？
多数決制は主にアングラ面でしか発達してない。
政治的にせよ、経済的にせよ、信頼や保証を得られるものを拠り所にするのは変わらん。
久々の頭悪杉。

あ、「事実確認」は「事実認定」のミスね。意味分かる？

多数決はお前が言い出したんだろ。何だこいつ？

>>177 と同じ奴か？もっと柔軟に考えろよ。頭が硬すぎて全く理解できてないよ
多数決だからPKIと言わないとか言葉遊びがしたいだけなら別スレ立てて独りでやってろよ

分散ファイルシステムをググった結果。そのまま既成品を流用できないか。


Apache Cassandra - Wikipedia
Apache Hadoop - Wikipedia
Apache HBase - Wikipedia
BigTable - Wikipedia
ColonyFS: A Peer-to-Peer Filesystem　https://launchpad.net/colonyfs
DCE Distributed File System - Wikipedia
Global File System - Wikipedia
GNUnet - Wikipedia
Google File System - Wikipedia　PCは壊れるという前提で設計。ノードが壊れた時、データが失われないことと、自動で復旧できることに主眼を置く。
Hypertable - Wikipedia
IBM General Parallel File System - Wikipedia
OCFS2を使った共有storage　clustered file system　http://www.komoto.org/hpc/ocfs2.html
OpenAFS - Wikipedia
RAID - Wikipedia
Riakはオープンソースの分散データベース　http://basho.co.jp/riak/
Tahoe-LAFS　分散データ・ストア　http://sourceforge.jp/projects/freshmeat_tahoe-lafs/howto/install
分散ファイルシステム ttp://dic.gree.net/entry/%E5%88%86%E6%95%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0/%E4%B8%BB%E3%81%AA%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

はっきり言っといてやるよ。頭悪杉は >>177 押しのお前な。
秘密鍵のハッシュを入れたところでそれで真贋が確認できるのは本人だけ。
何の意味がある？全くねーよ。お前みたいな奴って決まって人に高圧的で暴言吐くよな。
それで結局一番バカってどのスレでもそうだよな。同じ奴かと思うわ。

>>255
おめえ、本当に頭悪いな。

たしかに、秘密鍵でなくとも、乱数で良い訳だよ。
ただな、


あとは読めば分かるよなw

>>252
「IDの一貫性」は、ユーザにコストを強いれば実現可能かもね。
だから、今しがた参戦したIDは自演を疑える仕組みさえあれば良いような気がする

>>255
いやぁ…多数決に関しては何も肯定的な意見を述べた事がないのですがね？

それと、
> 秘密鍵のハッシュを入れたところでそれで真贋が確認できるのは本人だけ。
その「本人の証言」が信用できないから裁判沙汰とかになる。

簡単な例を出しましょう。
俺「あ、俺、俺だよ >>255。俺、お前に 1000万貸してるよな？」
>>255「んなもんしらねーよ」
俺「請求書はおまえんちのポストに入ってる。借用書のコピーもあるから」
>>255「んだよそれ？証明してみろよ！！」
俺「じゃあすぐここに来て。確認するから。俺が『確認した』って言えば証明されたことになるんだよね？」

これに納得する >>255 であった…。話にならない。

要するに、匿名性とは、裏返すと
「理屈だけで誰かを信じるととんでもなく損を被る」
世界でもある。
秘密結社や裏世界の人間が「濃い」人間関係をもって信頼としてきた理由はそこにある。

「原理的に『一見さんお手軽匿名掲示板』は無理」というところで返したい。
俺のオススメは「IDの一貫性の放棄」なんだけど。それが一番実装的に楽。

>>256
お前が煽りたいだけのアホだということがよくわかるな。もちろん、ちゃんとした理由があるなら説明すればいい。
もし理由があるなら今の所誰も理解できてないし、それはプラスになる話だからな。だたまあ無いと断言するけどね。

>>257
２ちゃんの荒らしレベルしか想定できてないよね。自演とかはどうでもいい。個人が適当に判断すればいい。
問題になるのはスパムだ。例えば他の掲示板の普通の書き込みを脈絡なく大量に流されたら、
レスを一つ一つみて判断するということは不可能になる。普通の書き込みだからベイズフィルタも効かない。
こういう場合はPKIが必要になる。実際にfreenetのFMSやAmoeba/Lairにはその仕組みが実装されている。
スパムを送ってくるノードを弾けばいいと思うかも知れないけどそれは匿名性が無いことを意味する。

>>258
>>255 をどう受け取ればその返しになるのか全く理解できんが、
おれも、「多数決に関しては何も肯定的な意見を述べた事がない」よ ？

>>249 >多数決で事実確認するのが関の山
これお前のレスだろ？ID一緒だよ？

そろそろα実装が出てもいいころだね

>>260
ちゃんと書いてあるのに理解できないってことは、
説明しても理解できないってことだろw

>>243
何故にも何もメッセージ単位でDHTに入れる場合のキー値の話だったんだし、
スレッド単位でDHTに入れる場合にスレッド内メッセージのキー値の話するほうが何故に？だよ
スレッド単位でDHTに入れる場合ならまずコリジョンしないだろうから、確かにキーは適当でいい
>>254
そういうのは分散先ノードは同一の組織の管理する"管理が信用できるノード前提"な事が多いからなぁ…
参加しているノードが意図的に不正な動作をした場合の対処が可能なシステムでないとキツイ

>>256
スマンが詳しく頼む、俺以外にも何のメリットがあるのか疑問に思ってる奴が居るっぽいし
>>177はスレッド内でメッセージを区別するIDとしてそのハッシュ値を使うって用途だと思うが
「そのハッシュ関数の入力は公開するのか(秘密鍵を含むから無理だよね？)」
「入力を公開しない場合、不正なメッセージIDをどうやって検証して排除するのか」
「検証を行わない仕組みとした場合、第三者からみて乱数と何が違うのか」
「検証を行わない仕組みとした場合、意図的なコリジョンが起こせるがどうするのか」
「"署名すりゃ良い"とはメッセージのどの範囲をどの鍵で署名するのか」
「本文のハッシュなら不正な本文を差さない保証があるが、それに勝るメリットがあるのか」
など何を意図した式なのか(そもそもUnixTimeが関数ぽい表記だったり式としても謎い)よく分からんです

>>258
>>255は>>177の方法では無意味って言ってるだけで、その他何かしらの方法を肯定しているわけではないと思う

>>261
「関の山」の後が問題なんじゃないの？
「その程度が関の山だが使えんこともない」と「その程度が関の山だから使えるわけがない」では意味が全く違う

めんどくせぇなぁ・・・
＞「そのハッシュ関数の入力は公開するのか(秘密鍵を含むから無理だよね？)」
入力を公開する必要性がどこにある？ただ単なるメッセージのIDだぞ

＞「入力を公開しない場合、不正なメッセージIDをどうやって検証して排除するのか」
第三者が検証できてよいのか？その検証結果を偽装することも考えなきゃならんだろ。
不正なメッセージだと主張できるのは、本人だけじゃないのか？

P2P Replicated File Store

コンシステントハッシングと仮想ノード
http://stat.ameba.jp/user_images/20110112/09/principia-ca/c1/43/j/o0600039310978340133.jpg
http://stat.ameba.jp/user_images/20110112/10/principia-ca/7a/ee/j/o0406028710978360012.jpg
ノード追加時のデータコピーの局所性
http://stat.ameba.jp/user_images/20110112/10/principia-ca/06/45/j/o0600028610978360589.jpg
レプリケーション
http://stat.ameba.jp/user_images/20110112/10/principia-ca/f3/0d/j/o0692046710978399272.jpg
http://stat.ameba.jp/user_images/20110112/12/principia-ca/3a/e6/j/o0650046010978464438.jpg
http://ameblo.jp/principia-ca/entry-10765169542.html

＞「検証を行わない仕組みとした場合、第三者からみて乱数と何が違うのか」
第三者が作り得ないID

＞「検証を行わない仕組みとした場合、意図的なコリジョンが起こせるがどうするのか」
コリジョン起こしたら破棄するんだろうな。10万年使っても1回も発生しないよ。

＞「"署名すりゃ良い"とはメッセージのどの範囲をどの鍵で署名するのか」
H（メッセージID ＋ メッセージ）

＞「本文のハッシュなら不正な本文を差さない保証があるが、それに勝るメリットがあるのか」
メッセージIDは本人しか作り得ない。本人のみが不正なメッセージもしくはIDだと検証することができる

>>266
同じメッセージIDを偽装した偽のメッセージを投げ込まれた時にメッセージIDで判別できないじゃん
メッセージIDがハッシュ値の場合は偽のメッセージは異なるハッシュ値になるからその場で捨てれる
こういう処理が必要ないのならメッセージIDは只ユニークでありさえすれば良いから>>177である意味もない

>>268
> 第三者が作り得ないID
第三者が曖昧になるから送信者受信者攻撃者とする。送信者がいつか誰かに送ったMsgAを攻撃者が読み、
攻撃者がMsgBを作る際にそのMsgAのIDを使っても、受信者(第三者)はMsgBのIDをMsgAのものと区別できない
> コリジョン起こしたら破棄
意図的に起こせる場合は全部破棄？
> H（メッセージID ＋ メッセージ）
それは署名じゃなくてハッシュ計算してるだけでは？
> メッセージIDは本人しか作り得ない。
正しい方法で作る限りはそうだけど、MsgIDは他人が読むもので読んだ以上は幾らでも真似(偽造)できる

ここでさ、匿名システムは
多数決では決められないシステムと
定義づけて見ようか？

実際、匿名だと同じ人が多数の人のふりができちゃうから。

じゃあ、多数決で決められないものでどうやって決める？
それがネットの投票システムが時として
荒らされる原因なんだよね。

>>269
だからお前はバカだって言われるんだよ、脳足りん
メッセージIDの本人性の話をしてるのに、
なんで急にトランザクション処理の完全性や通信経路の完全性の話に飛ぶんだよ

おまえ1回それで誰かに怒られてるだろ
だから、>>258みたいなことを書かれるんだよ。
ほんと、頭悪

ROMってたけど口出すね
偽装も何も普通は送信者の同一性の証明は秘密鍵使って電子署名するんだよ
unique id生成なら全て乱数で十分だし使っても公開鍵だろう

非公開の秘密鍵使ってハッシュ化なんて第三者が検証もできない上に
ハッシュ化した情報から無駄に秘密鍵への脆弱性も増えるし何もいいこと無いよ

知らないが。公開鍵は暗号化用で、秘密鍵は復号化用で、逆の用途には使用できないだろ。

そんな制限ないよー
秘密鍵は公開しないだけで、一般にも双方向で使われてるよ
こんな初歩的な知識で議論してたら怒る人が出るのも無理ないよ

>>272
いまいち確認だが、


RSAは総当りできる( 素因数分解可能なものを排除できる )　vs レインボーテーブル


を理解できる、つーか、考慮してる？
していないんだったら、レベル低すぎなんだけど

>>274
RSAは制限ないけど、公開鍵方式だから双方向って制限もないけどね

>>275
レインボーテーブルなんてなくても鍵候補をハッシュ化して照合されちゃうよ
本当に仕組みを理解してる？

>>276
RSAじゃなくても公開鍵方式に制限なんてないよ
プロトコルで制限をつけている場合はあるけど

周辺の話に適当に突っ込んで煙にまこうとしないでさ、
秘密鍵をハッシュの入力に使う理由を先に答えてよ
そこが一番重要なのに一切答えてないじゃない

間違いが認められず暴言吐くようなのは議論の邪魔にしかならないのでNGにしてしまおう

RSAの解説見たら、暗号鍵も、復号鍵も対称的で入れ替え可能だったよ。
素数　p,qに対して、ab ≡1 mod (p-1)(q-1) を満たす、a,bが暗号、復号鍵の元。

>>277
ほれ、レベルがぜんぜんちがうやん。
128bitのレインボーテーブルってどのくらい大きさがあるんだい？
160bitならどうかね？
1000bitって君は神なのかな？

ちなみに、秘密鍵は合成数なので、素数の数よりも多くなるんだが、それも理解してる？


は〜あ

ああ、
合成数じゃないか。

でも素数じゃないからね。

>>280
結局話をすり替えることしかできないんだね

この板ID入って本当に良かったと思う

>>282
あら？

計算量を鑑みてセキュリティレベルが下がらないことを示したんだが、理解できなかった？

あ、そｗｗｗ

>>283
オーダーは変わらないけど計算コストはハッシュ関数に依存するようになるよ
秘密鍵をハッシュの入力に使う理由は？
早く答えてよ

/*
モラルを守って建設的に議論してほしいな。
相手がまちがっていたらそれを優しく諭してあげればいいじゃないか。
そうでもしないと永遠に前には進まないと思うよ。
*/
DHTのアルゴリズムとしてChordを採用する場合、ハッシュテーブルのキー空間のサイズは2^160になる。
SHA-1が十分に偏りのないハッシュを生成すると仮定すれば、秒速1000回書き込みがあるとして、それが毎日10年間続いても
gosh> (inexact (* 1000 60 60 24 365 10 (/ 1 (expt 2 80))))
2.608596779747228e-13
のように、ほぼ衝突しないと考えてよい。
※ハッシュ関数の衝突確率は2^(bits/2)になる。
したがって意図的なコリジョンは起こせないものと考えてもいい。
そういうわけでスレッド毎にDHTを分割する必要性は無い。一つのDHTで十分。

掲示板の機構とDHTは切り離したほうがいい。
自分の実装はそういう風に設計されている。掲示板からは単なるKVSとして利用する。
P2P掲示板というから面倒になるのであって、掲示板上での改竄防止とDHT上での改竄防止を同時に対策する。
さらにいうならDHTもデータ交換部やノードとの通信で分離すればいい。そこである程度の信頼性を付加すれば上のレイヤーは悩まずに済む。
OSI参照モデルみたいな事をすればいいってこと。オーバーレイネットワークをやるんだよ。

>>285



んだ



　

>>271
> メッセージIDの本人性の話をしてるのに
DHTのハッシュ衝突の話だろが、違うなら違うって言ってから話を変えろよ
> メッセージIDの本人性
書いた本人はIDで検証せずとも本文知ってるんだし、他人が検証できないなら何の意味もないだろ
> おまえ1回それで誰かに怒られてるだろ
言葉を返すようで悪いけど「〜の話」とか何度も書いてるのにアンカーも打たず斜め上に進んでるのお前だからな？
>>280
もしかして、レインボーテーブルが何か知らないで語ってるの？
ザックリ言ってしまえば入力と出力の対応表を圧縮する方法で、
圧縮率(平均探索時間)を任意に設定できるからサイズも任意だよ
>>283
秘密鍵のハッシュを公開するリスクが低いと言いたいのかも知れんが、
そもそもメリットもないのにリスク犯す意味が分からないって話だからな？

>>226
全滅はしない
クラックしようとしたノードが停止するだけ

>>285
> ほぼ衝突しないと考えてよい。
データごとにユニークで十分に偏りのないハッシュ長の値(例：KVSのVのハッシュ)
をKVSのKeyに使えばそうなんだけど、キーとして>>177みたいな値を使って
検証なしで格納するようにしちゃうと意図的に衝突起こせてしまうからやばいよね？
検証するなら検証手段がわからない…って話でなんか罵倒されてて謎いんだよ
> 分割する必要性は無い
分割の方は勘違いしてた、分割しても無駄だったから、すまないが忘れてくれ
> 掲示板からは単なるKVSとして利用する。
掲示板としてDHT実装のKVSに格納する場合、Kの値はどうするべき/どうしてる？
メッセージ等の単体データはK=H(V)で検証機能を持たせられるけれど、
メッセージ単位で格納する場合にあるスレッドへ投稿されたKの一覧なんかを保持するKとVの構造の方。
スレッドを示すVはぶら下がってるKを追記し続ける順序なしリストとかになるかと思うんだが

>>235
訂正、検証不能な値をキーにするならどうやってもコリジョンが起こせるからダメだ

>>286
283とか280とか275とか271とか266とか263とか256(だよね？)とか書いといて、どの顔で賛同してんだ君は…orz

俺がいない間に勝手に荒れるな。
俺に荒らさせろ。

>>287
＞DHTのハッシュ衝突の話だろが、違うなら違うって言ってから話を変えろよ
コリジョンしないってのが理解できたんじゃないのかよｗ
理解度ゼロなのか

＞言葉を返すようで悪いけど「〜の話」とか何度も書いてるのにアンカーも打たず斜め上に進んでるのお前だからな？
で、怒られてるだろｗ

＞もしかして
だから、128bit　バイナリ入力で10年でいいからレインボーテーブルの大きさを出してみろよ。
本丸は1000bitだかんな
RSAを使うとするなら、因数分解よりハッシュの入力を探す方が計算量が多ければ十分だろ
コリジョン探すのとは訳が違う

＞そもそもメリットもないのに
だから馬鹿って言われるんだよ、脳タリンｗｗｗ


>>289
＞検証なしで
ランダムな数字なら検証できるのかよｗ
本人だけはデータを保持していなくとも自分の作ったメッセージのIDだと検証は可能だけど？

これは無理だ、手に負えんし諦めてほっとくわ…

>>288
言い方が不味かったな…
「解析された後に匿名性が全滅(消滅)するしか無いシステムじゃ不味い」って訂正しますわ
せめて「解析されてもIDの捏造が可能になるだけで匿名性は消えない」程度に抑えておきたい

あと相互監視で停止って方は最初から静的に解析するクラッカーには余り意味が無いかと
難読化で時間稼ぎは可能だけど、解析者の制御下で実行できる以上は机上解析を防ぐことが出来ない
想定する攻撃者に対して物理的な耐タンパ性能が無いならいつかは解析される想定をしたほうが良いと思う
PS3みたいな暗号化済みプログラムの実行インフラがあれば面白いんだけどねぇ…

>>292
ny の改変UPX 程度じゃだめか？

>>291
>因数分解よりハッシュの入力を探す方が計算量が多ければ十分だろ
例え正攻法の計算量が多かろうがsha1がまだコリジョン出てなかろうが
鍵をハッシュ関数の入力に混ぜる必要はないし意味はないだろ
２通りの攻略法を与えてしまうだけでメリットがない

>>293
UPXってアンチデバッグ考慮しない圧縮用の実装でアンパックの練習に手頃な題材らしいからなぁ…
nyの改変がどの程度か分からんけどUPX本体で公式アンパックができない程度なら即抜かれるかな
nyは途中からASPackに鞍替えしたらしいしそっちの方がマシだろうけど確かコレもアンパッカー既出

アンパックというか逆アセンブル避けするなら動的に変動させたほうが嫌がらせになると思うよ
インタプリタ乗っけてその上で動かしたり、自己書き換えやJITコンパイルやJITロードしてみたり、
そういうことされると全自己書き換え点やJITモジュールを見つけての個別ダンプ等かなり面倒になる
>>221みたいな相互監視やデバッガ動作やSEHやらを組み合わせるとより効果的な嫌がらせになる
パッカーは元コードが起動時に復元されて、ダンプの逆汗で元コードに対応するコードが出てしまう

そもそもコアなコードを外部に追い出せない限りどこまで行っても嫌がらせでしかないしいずれ覚悟すべき
P2Pだのの分析で目を輝かせてるような会社もあるからねぇ…腐っても専門家だし甘く見ないほうが良さげ

でも世に存在する特定の人物への嫌がらせにはなるんだ‥‥
いや、嬉々として解析してそうな気もするけど‥‥

暗号ってかけるよりも解く方が楽しいだろ？

>>294
＞sha1がまだコリジョン
残念ｗ

で、自分が間違っていたことを少しは認める気になったか
感心感心ｗ

使う方も匿名化されているのかどうか分からないしな。
結局管理者を信用するしかないとなると2ちゃんを利用するのとあまり変わらん。

>>298
別人だよ
煽ることしか考えてないからそういう意味不明なレスになるんだよ

>>289

＞データごとにユニークで十分に偏りのないハッシュ長の値(例：KVSのVのハッシュ)
＞をKVSのKeyに使えばそうなんだけど、キーとして>>177みたいな値を使って
＞検証なしで格納するようにしちゃうと意図的に衝突起こせてしまうからやばいよね？

今の所書き込み内容(スレID+名前+メール+本文)のハッシュで実装してる。衝突には介入できない。

＞> 掲示板からは単なるKVSとして利用する。
＞掲示板としてDHT実装のKVSに格納する場合、Kの値はどうするべき/どうしてる？
＞メッセージ等の単体データはK=H(V)で検証機能を持たせられるけれど、
＞メッセージ単位で格納する場合にあるスレッドへ投稿されたKの一覧なんかを保持するKとVの構造の方。
＞スレッドを示すVはぶら下がってるKを追記し続ける順序なしリストとかになるかと思うんだが

かなり単純にやってる。詳しくはソースを見ていただくとして、先程のハッシュ値をキーにしてる。レスごとに格納していて、スレ全体のレスのポインタ的なものはDHTには流通せず、更新した旨の通知(レスID+スレID+unixtime)だけが別ルートでノード間に流通する。

今一生懸命スレで出たネタをWikiにまとめてるけど
だいたい
・電子署名の信頼性確保
・匿名性保証と同一ノード情報取得の両立
あたりで話題がループ or 頓挫してますね
いい課題です

>>302
編集乙。ありがとう。
銀の弾丸が出ることもないだろうから、どこかで妥協点を見出すことになるかもしれないね。

とりあえずここまで読んで思ったのは
UUIDって、そうそう簡単に衝突するもんじゃないと思うんですよね
なぜそこまで衝突を気にしているのかよくわからん、誰か理由を教えてほしい
それに、UUIDを使えないとしても別の乱数を使えばいいじゃない

もしかして、問題はUUIDを意図的に、任意でユーザーに使われてしまうと言ってます？

UUIDに関連するサイトとか
http://ja.wikipedia.org/wiki/%E6%B1%8E%E7%94%A8%E4%B8%80%E6%84%8F%E8%AD%98%E5%88%A5%E5%AD%90
http://d.hatena.ne.jp/dayflower/20090306/1236314881
http://jx-script.blogspot.jp/2010/03/javautiluuid.html

>>301
ハッシュをキーにするなら偽装しても即排除できるから偽装の方は問題ないんですね
スレIDに対するレスIDはDHTじゃなくて別経路だったのか…

>>304
> そうそう簡単に衝突するもんじゃない
簡単に衝突しない≠絶対に衝突しない、なので衝突した場合のことを想定したら駄目な理由もない
実装次第では衝突を武器に任意のノードをネットワークから排除する攻撃ができちゃうしな
> 意図的に、任意でユーザーに使われてしまう
それもある
メッセージ全体のハッシュをキーにするだけで簡単には使えないのに、
敢えてUUIDだのだけでキー作る意味が無い

＞実装次第では衝突を武器に任意のノードをネットワークから排除する攻撃ができちゃうしな
それは、無い

UUIDを使うとして、誰がそのUUIDを発行するの？

衝突しないというのは、普通に使ったら衝突しないのであって、
UUIDが83a56850-21e7-47e7-be5a-d544ca462044だとして、
意図的に衝突させるなら、

function fake_uuid() {
　　return "83a56850-21e7-47e7-be5a-d544ca462044";
}

という関数を作れば衝突させられる。

UUID なんてあてにならん

>>308 その物言いはないっすわｗ
普通の業務システムでもサーバー側で一意でかぶらない文字列を作るのに使われるよ

>>307 の話はクライアント側でハッシュ値や一意にしたい文字列を偽造される心配
をしている話だからね。

とは言えども既存のP2Pソフトウェアでもそのようなハッシュ値は使われているはずで
どのようにそれが偽造されることを防いでいるか調べる必要がある

ちょっと考えたら対策浮かぶね
今はUUIDをこちらから渡すものとしてしか考えてないからクライアント側の偽造が可能だと思える
そうじゃなくてP2Pネットワークに参加する際の約束事（プロトコル）に組み込んでしまえばいい
->相手から情報もらう -> 自分が情報渡す -> 一意なハッシュもらえる
とかね

P2Pと匿名P2Pは別物だからね。

->相手から情報もらう -> 自分が情報渡す -> 一意なハッシュもらえる

P2Pだと成り立つかもしれないが、

匿名P2Pだと

->相手（実は自分が用意した別PC）から情報もらう -> 自分が情報渡す -> 一意なハッシュもらえる

そう。相手が匿名だから、別に自分が自分に渡したって良くなる。

逆に、悪意がある ”相手” になることもできるね。

->相手（悪意）から情報もらう -> 自分が情報渡す -> 一意なハッシュもらえる


悪意がある相手は何の情報を返すかといえば、
他と同じUUIDを返すわけさ。
相手が信用出来ないのに、その相手から返した情報を使うとかさ。

2chがとまり易いので早目で頼む

ハッシュと本文が見えてれば、
偽造した本文と、その正しいハッシュを流せば偽装ができる

それを理解できない人が居るみたいだね

>>311 >>312
言ってることは納得できたし理解したような気がする

で、確認としては

ノードがP2Pネットワークに入った時のIDの話
→　それはもう既存技術としてある

投稿者の同一性を保証するID
→　今議論していること

で大丈夫だよね

>P2Pと匿名P2Pは別物だからね
これはどういうことだろう？
匿名P2Pってもうあるんじゃないの

> ノードがP2Pネットワークに入った時のIDの話
> →　それはもう既存技術としてある

P2P型での完全匿名掲示板では存在しない。

なにかしらの信頼できるサーバーを利用するしかない。

>>316
新月やp2p2chでは、一意のID（not 投稿者のID）が振られていますが
あれは違うと申されます？
Chordアルゴリズム使ってたらそれは保証されるきがするのですが勘違いでしょうか？

ついでに言うと >>172 あたりから議論が錯綜していて話がよくわからない
会話はできてないみたいだから話の流れはどうでもいいんだけど、言ってることの意味ぐらいはまとめたいんだよね

はい、まったく違います。
あれはハッシュでありUUIDではありません。

>>319

>あれはハッシュでありUUIDではありません。
ガクッ…それを確認したいんじゃないのよ、わかってるよそれは。激おこですよ。
違う、そうじゃない

IDがハッシュってことは、（新月はよくわからんけど）
例えばp2p2chでChordアルゴリズム使っているのならば、
ノードがP2Pネットワークに入った時に配られるID。それは既存技術だよね？
きっとそうだろう

で、匿名ってどゆこと？

匿名じゃなけりゃ、タダの掲示板

ついでにChordアルゴリズム使ってる時のIDを偽造する方法を調べてみたが
あまり目ぼしいのは見つからない。（３分ググった）
偽造が考えられてないか、性善説で作ってるか、偽造しても価値がないと考えられているか？
学生さん研究テーマにどうです？新規性ありまっせ（適当）

>>306
実装次第ではって言ってるんだが、何を根拠にありえないと？
>>314
それは新しい投稿をネットワークに追加しているだけで、既存の投稿を偽造出来てないから問題ない
偽造と呼べる状況を作るには、標的に偽のP2Pノードリストを渡して隔離でもしないと無理で非現実的

>>321
そら、本人以外はクローラも含めて全部誰だか分からない、ってことやろ

PC固有のIDを生成を頑丈にしなくていいだろ。適当でいい。
どうしても頑丈にするなら、登録時に人間認証させてログイン制でいいし。
書き込み者は、警察が操作すればばれる可能性がある程度でいい。

>>310
だから >>192

>>326
それは匿名性が無いって事では？

2chのP2P代替を目指すべき。
データを保持、配布する側の匿名性を強化したらいい。
政府や警察に監視されないためのメッセージやり取りが目的だったら、既存技術を使ったほうが安全だろう。

今のとこ2chはうまくやっていけてるわけだから2chの代替を必要としてる人はいないと思う

2chはいつ停止するか分からん。
たびたび、表示されなくなってる。

2chの運営管理の権限乗っ取ったJimは技術屋じゃないし、
技術面やってるCMは明らかにSYN Floodじゃない証拠貼った後にSYN Floodされたとか吐かすレベルの技術しか無い
攻撃されたと誤解した経緯も設定を下手に弄り回して負荷で死んだ臭い所が有るし、何時死んでも不思議じゃないよ

>>332
Syn Floodじゃない証拠ってどうやって出したんだ
ログレベルと内容からか？

>>333
正常なTCPステートのnetstat貼ってたんだよ
SYN_RCVD以外に、FIN_WAIT_1とかTIME_WAITとかCLOSE_WAITとかがゾロゾロ居る奴を
ttp://pele.bbspink.com/test/read.cgi/erobbs/1393152643/782
ttp://pele.bbspink.com/test/read.cgi/erobbs/1394106710/166
SYN FloodだとSYN_RCVDのままセッションが開始しきらないから攻撃だとしてもSYN Floodではない
そのうえSYN FloodはIP詐称がワンセットと呼んでもいいくらいだから攻撃元IPアドレスで攻撃者は判断できない

これみて「SYN Flood？バーボンで焼けないの？」って聞いてた知ったかが居たんだが、
(注：バーボンはポート80でのTCPセッション開始後に.htaccess使ってApacheがリダイレクトする仕組みなので焼けるわけがない)
当初はハッキリ答えずにコード読み→クローラ用ホワイトリストから除外→バーボン、で目出度くP2死亡
その後SYN FloodだったとCM自身が言うようになりましたとさ

アホすぎてどうしようもない

そんなんだからクレカ番号お漏らしするんだよ・・・
あれも何故かHDD初期化で対処！とか吐かしたらしい(穴塞がない限り意味ないし、もはやタダの証拠隠滅の域)

>>334
てっきりhttpdのログかと思ったらnetstatの結果を公に貼ったのかよｗ
しかもSYN_RCVD数行でsyn floodてｗ

IP Address spoofing とかいうやつによる SYN Flood だったら対応との整合性が無い訳か

なのでいつ第二の流出が起きたり、鯖落ちで機能不全になったり、
収益を確保できずに潰れたりするか・・・結構危ない気がするのさ

どうも。
P2P2chのコアが更新されます。予定では夕方。
かなりよく動くようになりました。
現在リリースに向けたドキュメントの整備中です。
よろしく。

乙です

今後高匿名でも書き込めるようにするなら荒らし対策として高匿名の書き込みを非表示に出来る設定が欲しいです
低匿名の書き込みは荒らし対策で防げても荒らし対策の難しい高匿名を利用して荒らされたら荒らされ放題でスレが潰されるので

焼けた〜。
P2P2ch v1.10
http://p2p2ch.web.fc2.com/
バグがかなり取れました。
これから匿名やノード間メッセージの機能を追加していく予定です。

>>339
thx!
>>340
検討します。

>>341
そのソフトの方向性はどうなってますか？
あなたはどういう人間ですか？

ドワンゴのようなクズ企業と関わっていますか？
あるいは今後関わる可能性はありますか？

お久しぶりです。

>>341
VMware 上の Windows XP と JDK7 で、
hostname に ttp://chiraura0.web.fc2.com/try.html に公開しているドメインを設定して、automatic-portmap を false にして、
bin\p2p2ch.bat -Dconfig.file=conf\reference.conf -Dconfig.file=conf\application.conf で起動して、
reference したんですが、
[email protected]:ポート番号
になってしまいました。
きっとこれでは駄目なんですよね？
ポートが開いていることは ttp://www.akakagemaru. info/port/tcpport.php から確認しています。
何がいけないんでしょう？

>>343
わざわざありがとうございます。
設定のロードに用いるライブラリのドキュメントが不足しているため、プログラムに不備があるようです。
一時的な解決法ですが、-Dオプションに設定を続けて記述し実行することで設定できます。
例:
> bin\p2p2ch.bat -Dp2pakka.akka.remote.netty.tcp.hostname=example.com -Dp2pakka.automatic-portmap=false

現在正しく設定をロードできるように調整しています。

コマンドプロンプトからでは引数が与えられないようだったので、結局バッチファイルを
"%_JAVACMD%" -Dp2pakka.akka.remote.netty.tcp.hostname=ドメイン -Dp2pakka.automatic-portmap=false %_JAVA_OPTS% %P2P2CH_OPTS% -cp "%APP_CLASSPATH%" %APP_MAIN_CLASS% %CMDS%
と書き換えて実行してみました。そうすると Jane View から板を取得しにいったときに、
akka.remote.RemoteTransportException: Startup failed
(akka...略)
at momijikawa.p2pscalaproto.Chord.<init>(Chord.scala:20)
at controllers.Chord2ch.<init>(Chord2ch.scala:5)
(中略)
Caused by: org.jboss.netty.channel.ChannelException: Failed to bind to: ドメイン/グローバルIP:22223
(中略)
Caused by: java.net.BindException: Cannot assign requested address: bind
(後略)
で Internal Server Error になります。
ちなみに 1.10 の zip です。

>>345
おそらくホスト名の問題です。
P2P2chは束縛されるアドレスがhostnameとして認識できなければ許容しません。
現在の実装では、グローバルに使うためにはドメインを取得してFQDNをノードのhostnameとして設定しなければなりません。
これについても改善する予定ですが、いつになるのか分かりません。

orz

>>345
連投スマソ
追記: -Dp2pakka.akka.remote.use-passive-connection=onオプションの付与で改善するかもしれない。

>>347
そのオプションでは状況は変わりませんでした。結局 hosts を編集しました。
help や reference の反応が悪く、ログの削除と取得を繰り返しました。ただ待ってた方が良いんですかね？
スレ立てと書き込みもできましたが、書き込んだあとは Jane が必ず「ここ壊れてます」と言い、
一度ログを削除しないと正しく表示できません。

reference は
3F4sMhNVWuakA9FRlf3lLCWvM3k
です。これで接続待ち出来るんですよね？

>>348
お手数かけます。ありがとう。
Referenceはホスト部も含むはずですよ……？
[email protected]:123みたいな形式になるはずです。

専ブラ対応はwin環境がないので難航しています。macのthousandなら完璧なんですけどね。
Janeは送信する文字コードが違うような事件がありまして困ってます。
Thousandで書いたものがjaneで読めないと言ったことがあったもので。
できたらでいいのですが、このままwin環境のテスターになっていただけると嬉しいです。
//2ちゃんももう少し厳密に仕様を定義して欲しい。

これは余談ですが、gnutellaのgwebcacheに似た機構で自動的にブートストラップするシステムも作りたいですね。

どうせドワンゴが関わってるんだろうな
新月もドワンゴ社員が作ってる

ドワンゴのようなクズの集まりの企業と関わりがあるなんて
最悪だ

>>349
>[email protected]:123みたいな形式になるはずです。
@以降も必要なんですか？それはちょっと意味が分からないです。
正直そのまま書きたくはないです。

>できたらでいいのですが、このままwin環境のテスターになっていただけると嬉しいです。
酔狂でやっているだけなので、あてにはしないで下さい。

ホスト名晒すのは個人PCだときついかもね
VPSでp2p2ch起動させてみた、以下のノード

yCoIM/[email protected]:22223

上で言われているようにport名指定が効いてないね
あと P2P2chの情報スレッド で、referencesコマンドがうまく叩けない
POST受け取った時の処理に抜けがあるのでは？・・・ではでは
とりあえずJDでの書き込みは問題なし

ホスト名さらすがいやなら、IPアドレスをさらせばいいじゃない？

>名前を言ったらばれるだろｗ 有名人なんだからｗ >>353 ppp

>>354っていきなりなんなんなんだ？
キチガイか？

かまっちゃだめ。
キチガイは構うと悪化する。

思い込みが激しいなwww

105 名前：デフォルトの名無しさん[sage] 投稿日：2014/03/22(土) 04:55:33.19 ID:82saBhe8 [3/5]
名前を言ったらばれるだろｗ 有名人なんだからｗ

>>349
起動し直す度にスレが全部消えます。

join
yCoIM/[email protected]:22223
とすると
[ERROR] [03/22/2014 10:00:19.092] [play-akka.actor.default-dispatcher-12] [ActorSystem(ChordCore-DHT)] Invalid node reference.
と言われます。

reference や join を二回書き込まないと正しく反応してくれません。
と言うか1回前のコマンドの結果が書き込まれます。

ノードを参照するところを実際見てみたかったんだけどな
まあゆっくりやりましょうや

バグ報告ありがとうございます。

>>351
IPアドレスをなんとか自動的に取得できたらいいんですけどね……
信頼できる（logを取る）ディレクトリサーバを用意してそこに登録するという形を取れば、少なくとも直接IPアドレスを公開するリスクは回避されます。
Torのhidden service使ったらいいかも？

>>352
POSTあたりの処理を見直して見ます。
ポートの取得の部分もよく見て見ます。

>>358
まだデータの保存はメモリにしか行わないので別途保存の処理を書くことにしています。お待ちください。
ちなみに他のノードと接続している場合はそちらにデータを転送します。
現在クライアントの専ブラとの通信を見直しています。

>>359
自動的に接続するってことでしょうか？

----
バグはgithubに送っていただいても結構です。そろそろ私もVPSを借りるべきでしょうか。

トリップに使えるんじゃないかと考えている署名のデモを作ってみた
JavaScriptによるRSA方式簡易署名 http://die4game.wkeya.com/rsa_js/

タイトル通り、RSAでの署名をJavaScriptで作成する
簡易というのは、ｎが10進100桁程度なので頑張れば素因数分解できるのではないかと

>>361
乙乙。

Stackoverflowで聞いたんだけれど、P2P2chで使ってるAkkaフレームワークではNATが越えられないことが分かった。
そういうわけでメッセージング関連を大幅に書き換えることになりそうです。
手伝ってくれる人がいると助かります。
強制するわけではないので聞き流してくれて大丈夫です。

さて>>343についてですがおおよそ解決しました。設定ファイルをマージして一つのファイルとしてロードすると通ります。

さて、別のお題を持って来ましたよ。
以前「IDは構わないがIPアドレスは晒したくない」という方がいました。どのみち接続するノードにはIPアドレスは知られてしまうのですが、ここのような不特定多数の人間が見られる場所にIPアドレスを書き込むのはセキュリティ上あまり良くないのも確かです。

ではきちんとした規約に基づいて、必要なノードに必要なノード情報だけを公開するディレクトリサーバを建てたとしても、サーバが落ちた時やクラックに会った時のダメージが増加するでしょうし、ディレクトリサーバの存在そのものがSPOFとなってしまいます。

できるだけセキュアにノード情報を公開し、ユーザの負担を減らすにはどうすれば良いのでしょうか？

他のP2Pシステムでは、直接晒している場合が少なくないようです。ひょっとしたらそれ以外に方法はないのかもしれません。

鍵となるのはキャッシュだと思うのですが、どうでしょう。

>>361
RSAに敢えてする理由が意味不明

>>364
？？

>>365
RSAはなんといっても実装が簡単。
今でも(強度を調整すれば)通用する暗号としては一番簡単なレベルじゃないかな？
自分としては、優秀な暗号化ライブラリがいくつもあるんだからもっと複雑なの使っても良いと思うけど。
元祖P2P掲示板の新月でも使われてるし、いっそ互換にするのもありかもね

>>364
IPアドレスを隠してインターネット上のサービスを使うのは原理的に無理だからねー。難しいよ。
そもそも、IPアドレスを晒した程度でセキュリティが低下しちゃいかんのだがな(´･ω･`)

例えばBitcoinは確かIRCにノード情報を書き込む方式らしいぜ。チャットならログが残らないし割といい方式かもね。

キャッシュを活用した初期ノード取得は…ちょっと想像がつかん。

海外勢も含めて、匿名性を重視したP2Pでさえ暗号化したIPアドレスだからね。(検閲のある国でも通用してるので、あまり問題はないのかも知れないけど)
何とか出来れば革新的だな。

>>365,367
まさに実装が簡単だったから。ブラウザでの閲覧で利用できるようにJavaScriptで書いてみた
こういうのは一般的なブラウザで動けば一番いいと思うんだよね

>>367
公開鍵暗号系で，RSA やデフィーへルマン以外を選ぶ，というのも難しい話が絡んでくるので勇気がいるね‥‥
楕円とかいう言葉はみるからにいやじゃないですか‥‥
単振り子を厳密にやるとか‥‥

いや、大分レベルの違う話をしてるんだけど・・・

RSAにする必要なんかないだろ
ハッシュで十分

なにゆえ可逆変換をして、あえて匿名性を下げようとしてんの？

トリップだからね。p2p(というか分散システム？)だとトリップは署名でないと意味がない

少し前に話題になっていた改変検出か、あるいは ID をつける話かと

今考えたら

（１）任意の文字列を与えると、特定の文字列に変換される（ハッシュ値）
（２）ソースコードと変換後の文字列を公開していても、もとの文字列は解読できない

この２条件が成立する関数Xがあれば、IDの問題は解決するように思う
その関数Xに与える文字列をグローバルIPにすればよいのだ
（…もっとも、ソースコード改変版のアプリを使われたら対応できないがその場合はアプリ自体に署名を行えば解決
個々のノードに署名を与えるサーバはないが、コンパイル時のアプリに署名を与えることは可能だ）

さあ、この命題を解決する方法はあるか？

>>374
>>68 で指摘されている、つまり IP(+日付）のハッシュならレインボーテーブルで一発
IP 32ビット空間は狭すぎる‥‥
でも ID はどうしてもつけたいなあ、今のム板の平穏をみても

ネットワーク上でソルトを浮遊させる、というアイディアが出ている

あと、この問題に関連すると思われる論文めっけたのでレスしとく
問題に完全一致ではないけどなんかヒントになるかね

Leveraging Identity-based Cryptography for Node
ID Assignment in Structured P2P Systems
http://www.patrickmcdaniel.org/pubs/ssnds07.pdf

>>375
それはつまりIPアドレスという元ネタが乱数の元だと、範囲が狭すぎて解読されちゃう
という理解でおｋかな？

いやまて乱数とハッシュは違うな、すまぬ
乱数　　　…　毎回違う値を出力することが目的
ハッシュ　…　元の文字列と全く異なるけど、与える文字列が同じなら同じ値を出力することが目的

解析できるかどうかよりも、偽IDを防ぐほうが困難では?
あと、IPからハッシュ計算するのはどのPCがやるんだ?
仕組みはよく分かっていないが、匿名性はTORと同じにすればいいのでは?

>>376を読んでたら
荒らし対策　◎
ID生成　　　○？
ってとこだな、最後まで読んでないからいざ実装したらクソ仕様かもしれんけど、とりあえず見てみるわ

>>379
よくわかってないなら知っておいたほうがいいよ。torの匿名性の真実について

http://wired.jp/2007/09/13/%E5%8C%BF%E5%90%8D%E5%8C%96%E3%83%84%E3%83%BC%E3%83%AB%E3%80%8Etor%E3%80%8F%E3%81%AE%E8%90%BD%E3%81%A8%E3%81%97%E7%A9%B4%E2%80%95%E2%80%95%E5%A4%A7%E4%BD%BF%E9%A4%A8%E7%AD%89%E3%81%AE%E9%80%9A/

> だがEgerstad氏によると、Torを使用する多くの人々は、それがエンド・トゥ・エンド(端から端まで、全区間)の
> 暗号化ツールだと誤解しているという。そのため、彼らは自分のウェブ上の行動を防御するために必要な予防措置を取っていないというのだ。
> こうした誤解から生まれる不備が、何者かによって悪用されている可能性が高いと、Egerstad氏は考えている。

> しかし、Torには既知の脆弱性がある。ネットワーク内でトラフィックが最後に通過する出口ノードでは、
> 最終的な目的地に送信される前にデータが復号化されなければならない。最終ノードを管理する人物は、
> このサーバーを通過するデータを見ることができるのだ。

あとtorは三種類のノードがあって、普通の人はクライアントノード。
中継する人はリレーノード。これはIPアドレスをノードリストの一欄に載せる必要がある。

そして出口ノード。出口ノードはデータを見ることは可能だが、書き込み先にIPアドレスがばれる。
俺が犯行予告したんじない！と言うが疑われる人

匿名化・暗号化は既存のソフトを使えば良くないか。
わざわざ偽装して荒らす奴は、既存の匿名化ソフトを使うか、コード自体を書き換えるだろうから対策は意味無くないか?
IPやMACは丸見えでも良いと思うが。
違法な配信者として捕まらない対策を重視したほうが良くないか。これは匿名性と重なるが。
既存のTORネットワークをそのまま使うとかはダメか。

torを使う方法はわりと簡単で、通常のp2pアプリケーションを作成したら
ノードをtorのhiddenサービスで公開し、通信はtorのsocksを通すだけでいい

Freenet　分散化された、検閲に対抗できるネットワーク。
GNUnet　GNUnet is a fully free P2P network.
I2P　「不可視のインターネット」プロジェクト。
Nightweb　Android向けの匿名I2Pネットワーク。
Syndie　分散型の匿名掲示板ソフトウェア。
Tor　previously TOR, an acronym for The Onion Router
RetroShare　自由でセキュアなP2Pコミュニケーションプラットフォーム。
diaspora　分散型のソーシャルネットワーク。
GNU social　セルフホストで、分散化されたソーシャルネットワーク。
Movim　プライベートで分散化されたソーシャルネットワークサーバ。
http://prism-break.org/ja/categories/windows/

Syndie is an open source system for operating distributed forums, offering a secure and consistent interface to various anonymous and non-anonymous content networks.
http://syndie.i2p2.de/syndie_nets.png
Related projects
I2P
Syndie is being developed in part by the I2P development team, keeping in mind both I2P's anonymity and security model so as to support trivial operation over the I2P network. I2P by itself simply transfers

Tor
As with I2P, Tor is a low latency anonymizing network, and Tor's requirements and capabilities have been kept in mind so as to allow Syndie to operate on top of Tor as well.

Freenet
Freenet is an anonymizing distributed data cache whose features complement Syndie as well. Inserting a Syndie archive into Freenet is not a problem, and syndicating off Freenet SSK or USK keys is trivial, given Freenet's HTTP interface.

Frost
Frost, one of the most popular Freenet applications, bears many similarities to Syndie. The most substantial difference is Frost's tight dependence upon Freenet, limiting the flexibility of the message boards,

OpenDHT
Another public storage medium that Syndie can be made to operate archives out of. OpenDHT runs across hundreds of geographically and politically dispersed servers, hosted by PlanetLab.
Eternity Service
http://syndie.i2p2.de/

まあ、あるんだよね。高度に匿名化された掲示板は。ただどれも、2ちゃんのようには人が集まらない

>>371
検証に必要な情報を公開するとなりすましにも利用可能になりうるからだろうな
可逆なのは確かだが、効率的な逆算関数の不在が散々検証されてるのがRSA
匿名のオーバレイネットワークを捨てて接続相手のIPという形で入力の偽造を困難にすることは可能だが、
全員が直接通信するわけじゃないから直接検証不能なエリアが出来てしまいかねないし匿名性も無くなる
>>374
ハッシュの逆算は既出なんで省略
> アプリ自体に署名
その署名の検証を行えるのは改変版を利用する本人のPCなので、
検証工程自体も改竄することで何の意味もなくなってしまう
>>377
大体合ってる

>>386
＞署名の検証を行えるのは改変版を利用する本人のPCなので、検証工程自体も改竄することで何の意味もなくなってしまう
オリジナルが複数に投稿をばら撒く仕様であれば、投稿の改変はあらたな投稿が生成されたと同じ意味でしかない。

>>364
接続相手が限定される性質のP2Pネットワークならそういう配慮する余地もあるかもしれんけど…
そうじゃないP2Pに参加してる時点で不特定多数にIPアドレス見られることを忌避してもほぼ意味が無い
ネットワークのトポロジ考えて、接続相手が半固定されるような構造になったらその時考えればいいと思う

>>387
ID生成を他人が行う場合の話だと思うけど、他人のID改竄する改造版ってほぼ意味がなくね？
あと371へのレスの後半に書いてるけど、それすると匿名性の有るオーバレイネットワークにするのが難しい
って事でグローバルIPアドレスを何らかの方法で取得して"自分で計算する"前提で考えてたんだが

そもそもその部分はアプリ自身を署名しておく事の有効性全般について述べてる訳だからそれ俺に言われてもな…

ん、ごめんごめん

ま、クローラがいずれ出現するであろうことは、ソース公開でいくのならば必然だしね
自分で計算する、というのは　>>192 スタンス(spam 阻止への観点）では受け入れがたいかもしれないね

複数の実装の間で各種スタンスをも抱合できたらおもしろいかもしれないが

>>390
アプリ自身の改竄防止が成立するなら自分で計算ってのも悪くないんだけど、
ハードウェアサポートがないとそういうのはまず無理(>>292)なんだよなぁ・・・
攻撃側にチップの研磨位の根性を想定するとそれですら突破されうるし・・・

>>391
ソフトウェアが正当なものかは、おそらくブラックボックステストのような形式を取って判断することになると思う。

定期的にノードにデータを保存したり意図的にそのノードを経由してデータを保存したりして、得られた結果からそれが正しく機能しているかを間接的に知るという手法以外に、なすすべはないと思う。
言い換えるならば、表に出ない改造はどうしても発見できない。当たり前のように思えるけど、P2Pではかなり大事になってくる。

P2P環境下では、既存のパラダイムが変質する。基本的にノードは信用できないものとして扱うことになる。それを見越して、TCPのような機構をネットワークに構築して動的にルーティングしたり故障ノードを回避したりすることが求められるのではないかな。

>>392
チューリングテスト、ですか
悪くないと思う

>>393
チューリングテストちゃうだろ

つか、コードはオープンでも実現可能じゃなきゃ「完全」匿名は実現不可能だわさ
じゃ、誰が？って話になるが、
そりゃ、シンプルだろ
ネットワークが真贋判定すりゃ良い
じゃ、何を？
そりゃ、じぶんで考えろや
散々ヒントを上げてるんだからよ

経験値かHPかレベルなんかをいれて、忍法帳みたいにしては?
改変できないよう仮想通貨と同じアルゴリズムにする。
書き込みや、忍法を使うと減って、採掘者へ配分。

「ノードの公開情報(IPアドレス等)があれば生成・検証できるID」ってのは危険すぎないか？ クローリングし放題だ。
しかもIPアドレスなんて(大抵の環境では)簡単に変えられるからな。危険な割に効果が見合わない。

>>392
ゼロ知識認証でいけるんでないの？
アプリ自体のチェックサムもどきを知識にしておくとかね。

数十年前の車輪の再開発をしてるようにしか見えないんだが

それとも天才達が既存の匿名システムを超えるものの議論をしていてオレが理解できないのかな

>>398
前者だとして何を再開発しているのか教えてくれたらもっと助かるんだけど違うか？

既存のP2P掲示板に不満があるから、みんなこんな所に居る訳で。
それに、車輪の再発明ってプログラミングの練習には結構良いんだよね。答えがいくらでも拾えるから。
P2Pも割といい題材。自分も簡単なP2Pチャットプログラムを作ってみたんだけど、基本的な知識があれば意外と作れるもんだ。
匿名性とか考えだすと死ぬんだろうけどね。

匿名ネットワークとしては何度も何度もi2pやtorがあると書かれているわけだが。

>>400
既存の匿名化技術に不満があるわけではないと思うんだが。

>>397
ゼロ知識証明では「そいつは正しいチェックサムを持ってる」ということしか確認できない。
偽物のプログラムに本物のチェックサムを覚えさせれば回避できるよ。

>>402
自分としては>>400で書いてる通り「P2P*掲示板*に不満がある」。文章がヘタで伝わらなかったならすまん。

>>403
いやいや、伝わってると思うよ
P2P掲示板に不満があるのであって既存の匿名化技術に不満はないはず
だから匿名化の部分は既存の技術を使えばいいと思うんだけどね

でも、その匿名化の技術を再開発しようとしてるように見えるんだが。それも劣化版。

大したことではないことを書くので無視してどうぞ。

既存の専ブラを使う以上、掲示板の制約から逃れることはできない。2ch互換のインターフェースを利用することになる。
いくつかの機能は投稿に自動的に付与して表示されるリンクとして提供することになるだろう。ひょっとしたら、酔狂な専ブラ開発者が機能対応してくれるかもしれないけど。

匿名性を満たすには、通信が他のノードを経由することになる。直接接続するとIPが割れることになるからだ。
すると本質的にP2Pではなくなる。だから掲示板としてはP2Pで、その下で働くレイヤーが複雑な匿名処理と暗号化を隠匿する必要がありそうだ。
まあ前にも言われた層の分離ってやつなんだけれどね。

できるだけ既存の掲示板互換のインターフェースを利用しつつ、中身を異なるものにしなければならない。

Torなんかの併用を前提としても、エンドツーエンドの暗号化をどのみち行わなければならなくなる。

ウォレット(ID)を作って書き込むと、レス数制限が拡張できて
書き込みでポイントが消費され、>>が付くと増えて、
データ保有量が多いほど、ポイントが増えるシステムは?
その他、マイニングでもポイント増える。

>>406
＞書き込みでポイントが消費され、>>が付くと増えて、
＞データ保有量が多いほど、ポイントが増えるシステムは?

同じような事を考えたことがある。
ただ自演が可能になるから、レスがつくとポイントが増えるシステムは難しい。
データ保有量に応じたボーナスが得られるのはなかなかいいと思うよ。
割と検証も容易だろうからね。
ただどういうボーナスを与えるべきなんだろう？データ保有量はデータ層の話で、掲示板はアプリケーション層の話だから、あまり連携の余地は少ないように思える。

検索エンジンのリンクファーム対策のようにほぼ無効に出来るのでは?
新規ユーザーはポイントがないか少なくて>>を付けてもほとんどポイントを送れない風にする。
書き込みと読み込みでどちらもポイントを消費して、必要なデータを保持しているPCから読み込むとき、そのPCへポイントが移るシステム。
データ保有が多いほどヒットしやすい。

ちょっと何を言ってるのか全然わからないね
ただ、既存の匿名ネットを知らないし知る気も無いのは伝わってくるわ

せめて少しは過去スレとWiki読んでくれよ…
せっかくまとめたのに語る気失せるわ、普通のP2P掲示板はあるから新規性無いです
だから、以下のような特徴を満たした掲示板あったらいいなでしょ？

・荒らし対策
・プロトコルによる制限
・ 匿名性保証と同一ノード情報取得の両立
http://www34.atwiki.jp/p2p-anon/pages/19.html

そらBitCoinとか面白いけどさ、ここは希望を述べるスレじゃねえんだ仕様を語れ

あ、でも既存の技術でP2P掲示板プログラム作りました！とかだったら大歓迎です

荒らし対策はペイズフィルタとキャプチャだけで十分だと思うけど

>>412
それはtor板みたいなp2pでない匿名掲示板の場合ね。

ベイジアンフィルタならクライアントでやるだけでも有用っぽい気がするけど、
学習型フィルタ内蔵2chブラウザが無いあたり微妙なのかな

色んな機能を一つにまとめるのは大変だろうけど、色んな機能をモジュールとして各人が開発したら、それを組み合わせる時が来たらきっと役に立つんじゃないかな。

>>404>>409
完全に匿名なネットワーク上では荒らし排除のためのID機能を成立させるのが難しいけどどうにかならんかを話してるんじゃねーの？

任意変更可能なIDをホワイトリスト的に(出来れば自動化して)運用する方法(これは既存の匿名ネットワークの上に構築可能)や、
任意変更不能なIDを何らかの方法で(出来れば匿名のまま)保証する方法が提案されている。
任意変更不能であることを保証するには保証を担保するプログラムの改竄防止が必要になるが、
その方法としてプログラム自体を難読化する方法と、他人のPCという改竄困難なハードウェアを利用する方法が提案されている。
前者はともかく後者の場合は既存の匿名ネットワークの上にそのまま構築することができなくなる。
>>412
ベイズフィルタを過信し過ぎだと思う。スクリプト以外にも荒らしはいるぞ？

>>416
>後者の場合は既存の匿名ネットワークの上にそのまま構築することができなくなる。

これはつまり匿名ではないってことだよ。

>>417
ノードの認証のためにソフトに何らかの変更を行う必要があって、それは今までの枠組みでは実現できないということではないのかな？
自分にもその文の意図する所がわからない。

>>417
そんな気がするけど、ほんとにそうか？って辺りで
「ネットワークにソルトを浮遊(>>199)」とか
「中継経路の全IDを埋める(>>68)」みたいなボンヤリしたネタが出てくるんだよ
>>418
IPアドレスを元に投稿者IDを算出しつつそれを隠蔽等する場合、
オーバレイネットワークに乗る前の段階で処理しないとって話

既にDarkNetとかで実現されてるよ

DarkNetじゃなくてStealthNetだった

StealthNetのIDは単なるノードIDだ

さて、398から議論が一巡したような気がするがｗ

で、そろそろ、分かったかね？
>>177 の有用性が


まだわからんのかねぇ

新月もそんなんだったかと思って見てみたら、本文だけ署名してるんだな。
(プロトコル上は書き込み時刻なんかも署名対象にできるが、朔はやってない)

送信側が「公開情報」(あるいはそのハッシュとか)を「秘密鍵」で暗号化したものが電子署名。これを「公開鍵」と一緒にばらまく。
受信・確認する側はその電子署名を「公開鍵」で復号化し、「公開情報」と等しいことを確認する。
……ってのが署名なんで、用語の混乱を避ける為にも>>177を署名と呼ぶべきじゃない。

まあ、自分ならこんな感じにするかな。
Hash( メッセージ固有のID + 書き込み時間 + <PublicKey> + Hash(本文) )

>>424
多分、君は署名と電子署名を混同してると思うよｗ

同一PCや同一人物を確定するにはID、PASSを求めるくらいしかないのでは?　
送信するとき偽装できる。入力なしで確定するのは諦めれば。

全データをID区別なしで放流して、見る側が弾いて付けたい人が名前・ハッシュを付ける方式か。
ビットコイン方式と忍法帳方式で、経験値次第でやれることが増える方式か。

電子署名の仕組みをいれたところで、データの一貫性は別だろ?
追記しかできないシステムであれば、それで改ざんも出来ない。
あと同時期に書き込みされた場合に、スレッドが2つ以上に分岐するのはどう回避する?

>>426
確かにそうだな、>>424のレスの「署名」は全部「電子署名」に置き換えて読んでくれ。

電子署名は一対一で認証局もあればいいが。
不特定多数で、PCも入れ替わる状況でどのように電子署名を使うのか見当つかない。
接続PCのすべての公開鍵を知る必要があるだろ?
出来たとしても、改ざんしたい奴が改ざんすれば、改ざんされたデータが通信経路では改ざんされていないことが証明出来るだけでは。
ブロックチェーンのような書き換えできない仕組みがいるがした。

>>429
いや、まだ、署名と電子署名を勘違いしてるよ

>>430
＞接続PCのすべての公開鍵を知る必要があるだろ?
無ぇ

>>431
署名と電子署名の違いは何だと思う？

電子署名ってこれだろ? 送信者のなりすまし、改ざんが防げたとしても、送信者による改ざんはどう防ぐんだ?


http://www.cyphertec.co.jp/images/t_digitalsignature.gif
http://www.cyphertec.co.jp/techno/t_digitalsignature.html


http://www.ccjc-net.or.jp/~kouza/sign/sign_0403.gif
http://www.ccjc-net.or.jp/~kouza/sign/sign04.html


http://itpro.nikkeibp.co.jp/article/COLUMN/20060704/242422/zu1.jpg
http://itpro.nikkeibp.co.jp/article/COLUMN/20060704/242422/

とりあえず自分の認識を書くので、間違っている点があったら ピンポイント で指摘してくれ。

署名は、ある情報を自分が作成したものだと何らかの方法で証明すること。
電子署名は、「自分が作成したものだと証明したい情報」と「それを自分が保持する秘密鍵によって暗号化したもの」
並びに「自分の公開鍵」を相手に見せて復号・照合してもらい、自分が対応する秘密鍵を保持していることを示す手段。

>>434
本文のハッシュなんかに署名するようにすると、署名の使い回しができなくなる。

あーーー文章に整理してみたら自分の間違いに気付いた
>>177の問題点は送信者にしか「署名そのもの」の正当性が確かめられない点だった
署名の中身(ハッシュを掛ける前)を公開できないと、たとえ送信者が本文を改変したとしても署名が通用する訳だ(そういうシステムを想定してるならアリかもだけど)。
頓珍漢な指摘をしてスマンかった>>ID:cH2/3bm6

乙乙。

偽造やすり替えを防ごう
→電子署名を付与しよう
→内容の正当性は証明できるけど署名の鍵の正当性は証明できない
→PKIをP2Pで構築するのか？
こんな流れになったね

電子署名あたりで混乱してるのは、皆が共有する前提が異なっているからだと思う。
署名うんぬんの前に、掲示板のシステムの構成について語るべきではないかな？
おそらくそこの認識が住人の中でずれてるんだよ。
ネットワーク構成から独立した身元保証システムを考えられるなら大丈夫だけれど、認証に他ノードが介在する以上それは難しい。

（それとも私が着いて来れてないのかな？）

P2Pと専ブラ一体で匿名性を保証するみたいなのだと
解析されるとつらいのか

>>435
本質的な署名の話をしてる？

だったら間違えてる
自分の作成したものだと証明する必要は必ずしも無い

IDを求める事と、過去レスの改ざん防止と、通信データの改ざんは別物だ。

電子署名ってのはどれを言ってるんだ?

新月の電子署名はトリップでしょ。2ちゃんの場合トリップはパスをサーバーに送ってサーバーがトリップに変換する
p2pだとパスを誰かに送るとか有り得ないし、かといってクライアントで自由に変換できたらそれも意味がない
だから、トリップは電子署名に取って代わる。

新月、Lair、PDその他どれでも実際に使用されているのを見ればどういう用途かはすぐにわかると思うけど

PKI基礎講座（2）：電子証明書と認証局 - ＠IT
信頼の基盤としての認証局
よくありがちな誤解が、「電子証明書を持っている＝信頼できる」というものである。
しかし、電子証明書の発行自体はパソコン1台で簡単にできてしまう。
つまり、電子証明書を発行することはだれにでもできてしまうのである。
PKIにおいて認証局とは「信頼の基盤」となるものなのだ。
http://www.atmarkit.co.jp/ait/articles/0011/21/news002.html


そんな認証局で大丈夫か？ベリサインが指摘するWebの課題
2012年02月09日
事件は認証局で起きていた！
ご存じの通り、SSLサーバー証明書は、Webブラウザから通信相手となるWebサーバーを認証するもの。
認証局（CA）と呼ばれる証明書発行機関が、独自の安全基準に基づいて証明書を作成し、サーバー管理者はこれをWebサーバーに登録。
一方、WebブラウザにはCAのルート証明書がプレインストールされており、通信時にはこのルート証明書とWebサーバーの証明書をつきあわせることで、
SSLによる安全な暗号化通信が実現するという仕組みだ。
ここで重要なのは、「そもそも認証局も証明書も、原則的には誰でも作れる」（上杉氏）という点。
そのため、本来認証局は業務全般に関するCPSやセキュリティポリシーをユーザーに掲出しつつ、物理的、人的なセキュリティ対策に関して、十分配慮されていなければならないという。
しかし、実際は2011年に偽造証明書が発行される事件が連続して発覚し、認証局に対する信頼は大きく揺らいでいる。
上杉氏は偽造証明書が発行されたコモドとデジノターの2つの事件について説明した。
まず、英コモドの場合、IA（発行局）としての同社が委託するイタリアのRA（登録局）がハッキングされてしまったことが原因。
この結果、Gmail、Skype、Mozilla、Microsoftアップデートなどの偽造証明書が発行されてしまったという。
http://ascii.jp/elem/000/000/668/668148/

信頼できる発信者(≒サーバー)であることを誰が認証するんだよ?
免許証、パスポートとかのコピーを送ってもらって、認証するのか?
認証局がなかったら、荒らしが電子署名を量産して荒らせて意味ないだろ。

だから、トリップと同じだって言ってるじゃん。トリップ知らないの？クソコテだよ？

各位、前提知識なのでご査収願います（訳：読んどけカスども）

IDベース暗号
http://ja.wikipedia.org/wiki/ID%E3%83%99%E3%83%BC%E3%82%B9%E6%9A%97%E5%8F%B7

分散ハッシュテーブル
http://ja.wikipedia.org/wiki/%E5%88%86%E6%95%A3%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB

トリップはサーバ=クライアントモデルでのみ有効だよ。

だから電子署名で代替になるし、実際に運用されてるでしょ。
いい加減に他のLairとかPDとかFreenetとか見ろって。

>>446
つか、サバクラじゃなくてもOKだろ
だから>>177が理解できていないんだよ

>>447
運用されているのはそのとおりだが、
電子署名は関係ないだろ？
なくてもいい存在。

>>448
＞>>446
＞つか、サバクラじゃなくてもOKだろ

トリップってのは、トリップのタネを鯖に送って鯖で不可逆な変換を施して鯖で表示してる。
P2P環境でどう実現しろと？まさかタネをネットワークに流せと？変換後のトリップを流したらMITM攻撃ができる以上トリップにならないだろ。そして電子署名を使うならそれはトリップとは言わないんだよ。

あと>>177にそれほど拘るならできる限りの説明をしてくれないか？明確に説明するならこちらも理解できるが、錯綜していてなにが言いたいのかわからなくなってないか？それをこちら側の責任みたいに言われてもどうしようもないんだよ。
理解されないのは理解させる努力が足りてないんじゃないのか？

>>447はもっと有用性をわかるように説明すべき
>>177はもういい座ってろ

自分からすると>>177はP2Pの匿名掲示板という仕様にとっては無益
１に単純なノードIDとしては他にアルゴリズムあるし
２に掲示板のユーザーIDとしてはハッシュ値を逆算される可能性大だからいらない
他の用途での使用をするつもりなら、当初と主張が違うので出直すべき

>>450
MITMなんてできないよ
DoS攻撃とか言うんだったら分からんでもなかったけどなぁｗ

多分この手の間違いは、
なにが認証におけるSubject で何が Objectなのかが間違えてるのが原因なんだろうなぁ


で誰が認証するのよ？
何を認証するのよ？
転送ノードが認証できるってことは匿名じゃないってことだよ

Winnyの中継機能ってあれ中間者攻撃
そのものだよね。

間に入ってデータを中継する。
その時、データを書き換えるだけ。

>>454
そだね

ちなみに、だが、
暗号は、元データの情報秘匿以外で
重要な役割を果たすことがあるもんでな

その役割をわざわざ書かないのは、
書けないからなんだろうな
って人は思うんだよｗ

>>456
書けないからなんだろうなって書く人は
どーしても教えてほしいと涙目になってる
って人は思うんだよｗ

うん、どーしても教えて欲しい（笑）
え？書くの？書かないの？
書かないんだー。悔しいなぁ（笑）

>>458
ｗｗｗ

がんばれｗ
>>454のレスで
>>455をかいているんだからね

暗号が十分分かっている人なら理解できる

よっしゃー、狙い通り書かなかった。

177を支持する理屈も説明できずに支持した挙句に罵倒し散らかす奴がいるってのは
177〜300くらいの流れで解ってるんだからその説明が無い支持はスルーしろよ

>>428
461氏の実装だとスレッドに対する投稿情報はネットワーク上にブロードキャストされるだけで(>>301)、
これは受信者から見れば順不同の追記が行われているだけになる
KVS前提として格納するなら、K=スレッドIDのVを投稿単位アトミックで追記できれば良いと思う
表示段階でレス単位にソート掛けて表示すれば、時間差でレス番がズレる程度で分岐しない
>>430
投稿文中での投稿者ID(自称)としての電子署名は認証局が有っても良いけど、オレオレ証明書でも良い
投稿の改竄については電子署名の値でなくてハッシュ値でも十分に改竄を防げるから必須ではない
ルーティングレイヤでは電子署名でも鍵交換でも構わないけど、
IPアドレスを偽装できる相手を想定するならTor同様の信用できるディレクトリサーバは要るかも？
>>437
PKIについては電子署名→条件反射でPKIって思ってる人もいるっぽいからそこは除外しとかないと
投稿内容に対する電子署名はトリップや投稿者IDにような用途で使う文には所有者の証明とか要らないし
>>438
専ブラとの一体性は直接関係なく、匿名性を匿名化方法に依存している場合は解析されると不味い
>>446>>450
> 名前の由来は『1人用（ひとりよう）キャップ』を略して『トリップ』。 --Wikipedia
電子署名の類を使って「トリップと同じ用途を満たす」ことは可能なので「ハッシュ系関数による」と頭につけたほうが良いかも
2chのトリップだってSHA1ってハッシュ関数の場合もあればDESって暗号化関数を用いたハッシュのような何かの場合もある

くっさ・・・NGしよ

ここはお前のナゾナゾスレじゃねえんだぞ

匿名BBSシステムとしてのWinny2
,金子氏は大規模匿名BBSシステムであるWinny2についての解説を行なった.
,大規模掲示板をP2Pシステムで実現するというアイディアは,金子氏がWinnyを開発する以前の2000年頃からしばしば議論されていた.

基本的なアイディアは,BBSにおける｢スレッド｣を,Winnyにおけるボディファイルとして扱うというものだ.
Winny2では,ファイルの中に1番目からX番目までの投稿内容が連なって記述される.
ここで課題になったのは,ファイルの｢同期問題｣である.
そもそもP2Pシステムでは,ファイルをたらい回しにするために途中で破損や欠落が起こりやすい.
そのため通信途中でファイルが変化しないよう,同一性を確保する必要がある.
Winny1はハッシュ値と呼ばれる仕組みを用いており,ネットワークの途中でファイルの内容が一切書き換わらないという前提で同期を取っていた.
しかし,これをBBSシステムにそのまま応用することは不可能である.
なぜなら一つのスレッドファイルに書き込みを順次追加していく場合,これは｢通信途中でファイル内容を書き換えていくこと｣を意味するからだ.
そこでWinny2に実装されたのは,｢それぞれのスレッドは,必ず特定の一つのノード(マスター)が管理する｣という仕組みである.
Winny2は,スレッドへの書き込み(ファイル内容の追加)をする際,それぞれその管理者のノードに対して行なう.
こうすることで,マスターに必ず最新の投稿が集中するため,ファイルの同期問題は発生しない.
しかし,この仕組みでは,書き込みをするとき必ずマスターへの接続が集中してしまう.

そこでWinny2は,書き込みは一つ隣のノードから行なわれるように設計されている.
しかし金子氏は,Winny2はまだ開発途上にあったため,決定的な欠陥が存在すると述べている.
それは,この仕組みではマスターの匿名性を守ることができない点というである.

Winny2では,分散型BBSに存在する同期問題を,マスターの一括管理という機構で解決した.
しかしその代わりにマスターの匿名性が犠牲になっている.
金子氏はこのトレードオフを解決するアイディアを持っていたが,Winny2の開発中止によって実現できなかったと述べている.

ttp://www.glocom.ac.jp/j/chijo/text/2006/06/winny_glocom.html

>>461
＞時間差で
その時間って正しい値をどうやって取得すんの、という問題がある
俺もその問題にぶち当たったわけだが、
数年前にこんなこと考えてた

コンテンツマスター群をリング状に連結してトークンをまわす
トークンをまわす目的は
１．生存確認
２．時間同期
このリングを俺が勝手にマスターリングネットサーバと呼んでたｗ

マスターリングネット サーバは、あくまでキーのマスターを分散保有する
RAID5チックな構成で、あくまでキーを保有するだけ
いくつかのマスターリングネットに参加できるが、PCの負荷次第でマスターリングネットへの参加は拒否できる
反面マスターリングネットに参加しているPCのメリットは完全なキーリストを容易に取得できること

うんまあ、これでスレ番の問題も解決しそうだけど、
問題が多すぎて挫折したなぁ

>>450
トリップが使えないというそのままの意味だったのか
電子署名が代替になるってことを否定してるのかと勘違いした

>>461 が説明してくれてるが、2ちゃんで何かの配布者などがトリップを付けるように
PDやLairで作者が電子署名をつけて成立しているわけで、 代替になるというのは理解してもらえると思う

ただ、この電子署名って言葉が間違ってる？

あと作者が自サイトで署名を公開することがPKI同等だと思う
それとLairでは板に該当するセクションの管理者が署名をトラストするシステムがあり
これはまさしくPKIだと思う

>>461
つづき

＞投稿文中での投稿者ID(自称)としての電子署名は認証局が有っても良いけど、オレオレ証明書でも良い
んだ

＞投稿の改竄については電子署名の値でなくてハッシュ値でも十分に改竄を防げるから必須ではない
ハッシュだけじゃ、改ざんしまくりだよ

＞ルーティングレイヤでは電子署名でも鍵交換でも構わないけど、
AH的なことを考えてるのか、ESP的なことを考えてるのか、IKE的なことをかんがえているのか？？？
むむむですなｗ

＞IPアドレスを偽装できる相手を想定するならTor同様の信用できるディレクトリサーバは要るかも？
それ、匿名じゃないじゃん

ピットコインが成功してるので、
ブロックチェーンで、先頭からデータを確定させてしまえば追記しか出来ないデータ列ができる。

>>468
暗号の利用モードをCTRにすれば同様のことが既に実現できるので、問題な塩

Shareネットワーク可視化システム「Sharebot」の仕組みと運用方針

Shareネットワーク可視化システム(Sharebot)とその運用について、お話したいと思います。

Sharebotは、基本的にShareネットワークの「クローラー」です。
Shareネットワーク内に存在するノードの一つとして振る舞い、相手を次々と変えながら接続し、キーを収集していきます。
相手のノードとは、暗号化されたShareプロトコルに則って一対一で通信します。
動きとしては、SSLに対応したサーチエンジンのクローラーに近いものがあります。

まずは、Shareネットワークに存在するどこか一つのノードに接続し、そのノードが持っているキー情報(ファイル名やそのハッシュ、ファイルの存在するノードのIPアドレスとポート、などが含まれている)の一覧を取得します。
キー情報には、他のノード情報が含まれていますので、今度は、得られたキー情報一覧に存在している全てのノードに接続し、同様の手順でキー情報一覧を取得します。
これを次々に繰り返す事で、Shareネットワーク内のキー情報を蓄積していくというものです。

キー情報の膨大なデータベースができれば、指定されたファイル(の完全キャッシュ)を所持しているノードのIPアドレスを検索するといった事が可能となります。

Sharebotは、この仕組みをマルチスレッドで実行しています。
一度に複数のノードに接続し、キー情報をキーデータベースに蓄積します。
また、キー情報からノード情報を抽出し、ノードデータベースに蓄積します。
キー、ノードとも重複がないよう蓄積時にチェックしますが、ノード情報は、新しく取得したものほど上位に蓄積していきます。
これは、新しく取得できたものほど、現在接続可能状態にある可能性が高いためです。

ttp://itpro.nikkeibp.co.jp/article/Watcher/20070124/259460/zu.gif
ttp://itpro.nikkeibp.co.jp/article/Watcher/20070124/259460/

UNYUN様のお言葉ですな
ちなみにIPアドレスは公開鍵方式で暗号されておりますが、
なぜそんなことができるかは、直接本人から聞いたことがある

熱くなってしまい申し訳ありませんでした。
後だしじゃんけんになりますが、レス番の修正機能はもう装備済みです。なんか勘違いしてたら申し訳ない。
書き込みにレスアンカーが検出されたら、それが指す書き込みを検索してDHT上のキーに変換し、読み込み時は逆の処理でローカルなレス番に変換しています。

あと>>466の言うとおり、個人サイトで公開鍵を示しておけばPKIの問題は解決すると思います。盲点でした。
掲示板の中のみで個人を特定できる必要性もあまりなさそうではあります。
ただそれはトリップに代わる電子署名として成り立つとして、誰にでも与えられるIDの代替機能はどうするべきでしょうか。

あと上で言われている「途中で書き換えられる」は、一部の改変ではなく「メッセージそのものを別のものを送信する」が含まれるという認識が足りていませんでした。ごめんなさい。

>>468
はー目から鱗だわ。取引履歴をレスに読み変えればビットコインがスレになるのか。
そこまでいくと、今の自分の知識ではついていけない。わりとまじめに>>398の後者なのかな。

472　付け刃的で解決になっていないような
↑　こういう場合、スレ番？としてどうやって認識するの？

100 行かないスレなら大丈夫だけど
↑　これをどうやってスレ番から排除するの？

〉472
↑　これはスレ番？

＞472 名前：461[sage] 投稿日：2014/03/28(金) 02:34:08.82 ID:oHjvQv92 [2/2]
　　　　　　　　　↑　この番号ともズレちゃうよね？

>>474
そもそもこのスレの名前欄461は「その3」における461だからねぇ…
そういうのの区別は機械的に行うのは不可能だから限界は有る
けど、2ch自体あぼ〜ん使わずに(時として私見で)削除する削除人とかいてそういうのでも番号は狂う
番号置換で済ますにしても、全部うまく番号変換できなきゃ駄目って訳でもないと思う
でも、専ブラごと開発するなら最初から投稿毎のユニークなIDをレス番代わりに使うほうが良さげだな

468の言うようにビットコインの仕組みを流用すればスレ番もズレないようできる気がするが、
こっちはレスポンスタイムが心配になってくるんだが…どうなんだろうな、そのへん。
専ブラごと開発の方向なら、スレ番確定までは仮番号でも振っとくべきか。

絶対参照的なものですね

ビットコイン方式もそんなに簡単には上手くいきそうにないな。参加人数が少なければ適当に回せば成立しそうだけど

今日の野球やってる間の VIPとなんでも実況 の重さがなんとかなってほしい

ちらしの裏は、Janeで実働してたぞ。





ちらしの裏は完全分散型のポエム連作支援ソフトです。
ポート開け必須の P2P ソフトであり、2ちゃんねるブラウザを介してポエムの読み書きを行います。
http://chiraura0.web.fc2.com/

> ポート開け必須の P2P ソフトであり
UPnPとかNAT traversalとか使えんもんかね？
なんかこう、ダサいんだよなぁ。

>>480
UPnP実装はGitHubかなんかに転がってたね
P2P2chにはそれを搭載したよ

ちなみにここ2chは
「UPｎP有効のルータがある環境で、Skypeをデフォルト設定のままインストールしたPCが中にいる」
場合に開放されたポートをポートスキャンして、500番代エラーを返すクソ仕様だった(今も？)そうだよ
なのでSkype消すかポート開放切るかUPｎP切るかしないと駄目という

UPｎPってセキュリティ的に大丈夫なの？
悪気が無くてもバグ仕込まれたらと思うと怖くない？

自力で開放できない層はあえて排除してもいい

>>483
Flash　ね

革新的なiOSチャットアプリ「FireChat」が話題に
http://wired.jp/2014/03/31/apple-multipeer-connectivity/

>>486
これは革新的だな
必要なのは書き込んだ情報が誰かに伝わればいいのであって
いつまでも、いつでも読み込み可能にする必要はない
過去ログに残る必要もない

>>486
いいねこれ。インストールしてみよう。
メッシュネットワークには前から興味があったけど、iOSで使えたんだ。知らなかった。
メッシュネットワークで掲示板が実現できたら災害に強いだろうなあ。

一時的に流通させるのは、winnyでも出来てたわけで古い技術。
消えない、消えにくいP2Pが新しい。消えなくて同期的がいい。



BitTorrent Syncとは
パソコン間をP2Pという形式を使ってファイルを同期しましょうというアプリケーションです。
「安心のセキリティ」P2Pという通信方式で暗号化が行われており行き来するデータが漏洩する可能性が0
サーバーにデータを置かないのでパスワードの流出やハッキングによって大切なデータが漏洩する事がない。
「無料で容量無制限」ファイル転送に制限が無い。
BitTorrentSyncはサーバーにデータを置くことが無いので同期し合うPCの容量が限界になります。
「信頼性と高速性」同期の速度・重複の可能性が低い。サーバーからデータを持ってこないので実質的に同期するパソコン同士の高速な同期が可能です。
ttp://www.cafregard.com/?p=43



LifeStuffは、ユーザのデータを暗号化してP2Pネットワーク上に保存するサービスです。
このとき、「ユーザが保存するデータの75%から90%は重複している」という性質を利用し、同じデータを保存しないようにして、ストレージの節約を行います。
http://did2memo.net/wp-content/uploads/2012/09/lifestuff-methods-deduplication-using-self-encryption-naive-encryption-cannot-deduplicate.png
http://did2memo.net/wp-content/uploads/2012/09/lifestuff-methods-deduplication-using-self-encryption-wish.png
http://did2memo.net/2012/09/07/lifestuff-methods-deduplication-using-self-encryption/

>BitTorrent Sync
rsyncでいいだろ

新しくないのに「新しい」といって売り込む手法だな。

ちなみに、winnyや新月はメッシュ型。

メッシュ型P2Pとメッシュネットワークは違うよ

違わないよ。ネットワークのトポロジーのことでしょ。

P2Pはトポロジじゃないからな

p2pかそうでないかを言ってるのか？よけい意味不明だよね。winnyや新月はp2pではないと言いたいのかな？

メッシュネットワークは実際にメッシュ状にパケットが流れているが、P2Pは既存の、いわゆるスター型のTCP/IPスタックのシステム上に構築されたオーバレイネットワークだから別物だと考えた。

P2Pは実質、メッシュ型だが。
使用方法は限定されないから、さまざまな型のネットワークで使える。

端末間通信ができる携帯端末が広く普及したのでネイティヴなメッシュネットワークが実用に耐えるようなった
ということだよね。やっぱり新しいかな。アップル嫌いなんだよね。まあ新しいかな(前からあったけど)みたいなのばかりで

ひろゆき｢2chはJIMに違法行為で乗っ取られた。今2ちゃんでボランティアやってる奴らも訴えるし。｣★2
http://maguro.2ch.net/test/read.cgi/poverty/1396362677/

ひろゆき、ガジェット通信、未来検索ブラジル、ドワンゴ

こういうクズ共が関係してる2ch関係から早くおさらばしたい
早く匿名P2P掲示板作ってくれ

匿名P2P掲示板が公開されて使いやすかったら
まず嫌儲民となんJ民にものすごい勢いで普及するはずだから
ユーザー数は心配ないぞ

誰か作ってくれ

あと一週間あたりでNATを越えられるようにするための変更が終わりそう。かなり大幅な変更になって通信の互換性が無くなる。
httpを投げ合う形式になる。デバッグも容易になるはず。

結局httpになったか。でもその方が色々と都合がいいよね。
もしブラウザ拡張による実装が作れたら一番いいと思う。httpだといけるんじゃないかと。

>>494
普通にメッシュネットワークというと物理層のネットワークトポロジだから、
P2Pのネットワーク構造の文脈で出てくるメッシュとはレイヤが違うかと。
>>495
493の文脈ではP2Pはオーバレイネットワークっていう一つのレイヤだな。
>>498
スター型やリング型も普通に組めるよ。
オーバレイネットワークだから簡単に構造遷移しちゃって長い目で見るとメッシュ的になったとしても、
短期的・用途別での構造がスターやメッシュであるP2Pネットワークは普通に構成されて機能するよ。
>>499
実用になる条件(交信相手距離＞端末通信距離 && 経路端末間距離＜端末通信距離)
が厳しくて汎用アプリケーションは普及してない気がするんだが…
物理層メッシュの無線ルーティングプロトコルって実用になってるか？

無線メッシュネットワークでは匿名性は減るだろうね。接続性は上がるけれど、電波を発するリスクは背負うことになる。大声で叫んでるようなもんだからね（喩えが微妙）。発信元のノードが簡単に特定できるかも。
日本ではそこまで心配するこたないかな。

無線メッシュネットワークは物理層なんだし匿名性もクソもなくね？

>>504
>普通にメッシュネットワークというと物理層のネットワークトポロジだから

そんなことはない。>>486は物理層の実装ではないしね。

P2PのTORもメッシュネットワーク利用だろ

httpは専用サーバーソフト、専用ブラウザソフトが乱立していて、方言も多種ある。
あえてhttpを採用する意味があるか?
一部部分、httpプロトコルらしいモノは、httpでなくてhttpらしいモノだろう。

>>509
特定のパターンで遮断をかける ISP には有用かと
いま使用している ISP は，ny も pd も遮断されてしまって不満たらたら

HTTPに方言なんてあったっけ？

それはともかく、SoftEtherはファイアウォール突破にHTTPSを使ってるらしいな

一部の規約は、こうするのが推奨される、
程度で厳密に規定されてないから方言はつくれるはず。

>>507
知ってる知識分野でどれが普通かは変わるのかもしれんな
ただ>>493のメッシュネットワークは物理層の意味だと思うし、
物理層でのメッシュとP2Pのメッシュはレイヤが違うってのは間違って無くね？
>>509
何も考えずともプロトコルの詳細をある程度明示できるし、
拡張や起こりうる問題についての知見が蓄積されている。
Webブラウザからの直接接続を受けた場合の分岐も楽。
テキストベース故に帯域効率はちょっと下がるし、
プッシュ通信するとなると微妙だけどね…
>>511
改行コードがCRLFであるべき所がLFだったりするWebサイトとか有るぞ
…ってのは置いといて、WebDAVとかのHTTP系プロトコルのことじゃね？

httpの上にRESTなメッセージを載せて投げ合うようにしてます。
httpを採用したのは単にhttpをうまいこと処理してくれるちょうどいいフレームワークがあったからです。もっとましなフレームワークがあればなんでもいいです。
httpはただの台車に過ぎませんので深く考えなくてもいいでしょう。
ついでに暗号化もできるというオマケもついてきますし。

>>514
別段どんなプロトコルでも構わないんじゃね？
ファイアウォールが気になるならUPｎPよりSOAPを実装しとけば良い

ただ、ネゴシエーションは別にしてデータは送受信するわけじゃないから、
HTMLに拘らずに、
SOAP　+ SMTP＋MIMEかBase64で実装してもよいし(ポート25は使えないから80とか通りやすいポートをつかうんだろうけど)
ESPでがっちりでも構わない(オーバーヘッドが気になるけど)

SOAP + SMTP なら他ノードが代理で探してくれたキーや保有ノードを通知する仕組みとして簡単かも

どーせアドレス解決はDNSじゃないもの使うんでしょ？
もしくは、DNSのソースを使って128bit空間のある「IPアドレスとは別のアドレス」で解決する、とかになるでしょ。

UPnPはポート開放に使ってるみたいなので、通信プロトコルは関係ないでしょ
Webサーバだろうがメールサーバだろうがポート開放は必要だからね

「ポート開放」って言葉が駄目だな
P2Pでは定着しちゃってるみたいだけど、ポート転送って言うべきか
ファイアウォールとは関係ない

>>517
え？？？？

つ NAT
つ Proxy
つ ALG

SOAPやらを使うにしても、UPnPに代わるポート開放手段は要るよねってことでは

ポート開放不要な技術が既にあるけどね。ここは出てくるものの情報が古いな。

>>519
ちゃう

中国かなんかで
ポート開放せずにユーザーがブラウザでページ表示するだけで
ライブ配信見つつ自動で中継もして転送量分散できるサイトあったな
ブラウザで開くだけなら利用者が罪に問われる可能性が極端に低くなるはず

これ応用できない？

前も言ったことあるけど、
"ライブ"配信だから転送量分散が成り立つんだよね。
これがいつでも見れるとかなら、転送量分散にならない。

なぜなら、ライブであれば、その時間に
沢山のユーザーが集まることが期待できるから。

いつでも見れる場合はユーザーが集まらないから
転送量分散にならない。

SOAPなんぞHTTPだのの上に乗るプロトコルなのになんでUPnPの代替になるんだよ。
つかHTTPとは言ってるものの誰もHTMLだなんて言ってないのになんでHTML出てくるんだ。
DNSだの名前解決だのの話もどっから湧いてきたんだ……例によって無視推奨なの？

>>518
経路が確定している通信に対するフィルタ解除なら「開放」でいいだろうけど、
そのへんのは任意のアドレス・ポートに「転送」する機能だから「開放」だとちょと違う。
日本語でポート開放と呼ぶとしても、普通はポートフォワードって呼ばれたりするのが大半。
>>520
例えば？
NATの変換を無理くり推測したりしてNAP下のノード同士で通信する技術はなくもないけど不安定だし、
そうじゃなかったらグローバルIPアドレス・ポートでアクセスできるノード使って中継するしかないような…

>>524
＞HTTPだのの上に乗る
＞HTTPだのの上に乗る
＞HTTPだのの上に乗る
ｗｗｗ
もうちっと勉強しろｗｗｗ

SOAPに乗せる場合URIの解決にUDDIが使えないから、
アドレス解決の仕組みが別途必要だって、ここまで説明せな分からんのかね

>>523
同時接続数の多いチャットのページを作って
そのページを開いてる間はいろんな情報の中継者として役割をもたせるってのはどう

>>526
今の、日本においてなら有効だろうけど。
著作権侵害は、日本において親告罪であり、TPPでも話題になってる
非親告罪化すれば、共同正犯に問われる可能性がある

児童ポルノなんかは単純所持が構成要件ではないけど、
海外ではサムネイルですら構成要件を満たす。

海外旅行のついでに逮捕ってこともありうる。

つまり、今の法制度で日本に限ってなら数年は使えるかもね、程度のアイディア

あーID:jOu28WHpの言ってることが何となく分かった
確かに既存のプロトコルを使うのは色々と利点があるかもしれんな
ただ、UPnPの代わりにSOAPを〜とかDNS云々とか、思いついたことを文脈考えずにどんどん書いていくのは勘弁してなｗ

>>522
Flash PlayerのP2P機能はUDP Hole punching的なの使ってるみたいだね
ピア間で直接通信できるし、AESで暗号化もできるらしいし、割といいかも

ただ、通信を確立するのにAdobeのサーバが必要っぽいのが残念だ
IPアドレスじゃなくて、Adobe側が生成したIDで通信するらしい

完成版のデータは誰も保持しないようにしたらいい

>>522
ポート開放が違法ではない。オンラインゲームが違法となってしまう。
手動でポート開放しなくても、違法配信してたら違法。

>>528
性格がワイルドでスマンネ。

RTMP　(Adobe ) は、ストリーミングデータやマルチメディアの転送にはメリットがあるけど、
データファイルに関してこれを使うのはどうかねぇ、って感じはする。
オーバーヘッドが大きすぎるし、データのフラグメントサイズが128byteとか、小さすぎ
本格的な転送が始まったら、1024byte ( RSAで暗号するなら1000byte ) 程度は欲しい


ただ、RTMP　にしろ、　RTP/RTCP にしろ、
例えばQoSが利用できる、とか、
IP電話が導入されていれば、F/Wを超えやすいとか
.NET Framework のライブラリやMonoプロジェクトのライブラリが利用できるとか
安定したアプリケーションが構成できるのは大きなメリットかなぁ

こんなのあった



パソコンや携帯電話をサーバーに，Operaが新ソフト「Opera Unite」を発表
http://itpro.nikkeibp.co.jp/article/NEWS/20090616/332034/

Opera、Webブラウザ内サーバ機能「Opera Unite」発表
「Opera Unite」は、サードパーティーのサーバを経由せずにPC同士でコンテンツ交換やチャット、Webサービス運営が可能になるサービスだ。
http://www.itmedia.co.jp/enterprise/articles/0906/17/news022.html

Opera、Webブラウザーにサーバー機能を内蔵する“Opera Unite”技術を発表
ファイルの共有やチャット、Webサイトの構築などがWebブラウザー単体で実現可能
http://www.forest.impress.co.jp/article/2009/06/17/opera_unite.html

衝撃的なデビューをはたしたOpera Unite
http://news.mynavi.jp/articles/2009/06/17/operaunite/

重いファイルを仲間同士で共有するときベストなツール「Opera Unite」
http://www.lifehacker.jp/2010/02/100216operaunite.html

RTMPの128は可変らしいが。
53バイト固定で、いまだ利用されてる仕組みもある。


Asynchronous Transfer Mode - Wikipedia
Asynchronous Transfer Mode（非同期転送モード、ATM）は、53バイトの固定長のデータであるセルを基本的な通信の単位とする、
Virtual Circuit cell relay（仮想回線セルリレー）による通信プロトコルである。
小さなデータのセルを使うことの目的は、データストリームの多重化において発生するジッタ（遅延の揺らぎ）を軽減することにある。
音声信号は遅延に敏感なため、セルの組み立てによるタイムロスを減らすにはペイロードが小さいほどよい。
ヨーロッパ案の32オクテットとアメリカ案の64オクテットの折衷でペイロードが48オクテットに決定された。
ATMフォーラムでの仕様策定が遅れに遅れたり、100BASE-TXの普及や1000BASEのめどがついてくると、ATMフォーラムは一時壊滅状態となった。
その一方で多数の電話会社が広域ATMネットワークを構築し、速度保証を謳ったキャリアサービスのほとんどは、ATMバックボーンがベースとなっている。
また、高速通信の分野でも、既にPDH・SONET/SDH網とパケット交換網の統合のためにATMを構築してしまった部分もあるので、そういった分野でもしばらくの間は使われることになると予想される。
現在ADSLなどのDSLでも多重化のために広く用いられており、この分野については実用上のニーズに良く適合したと言える。
また、速度の異なる回線を一本の物理回線に多重化できる利点を生かしてW-CDMAなどの方式携帯電話のバックボーンにも用いられている。

>>533
KDDI なんかは、もう使っていないよ

>>526
> そのページを開いてる間はいろんな情報の中継者として役割をもたせるってのはどう
それって通信量を無駄に増やしているだけって気づいている？

>>535
全く無駄じゃないとは思うけど
共同正犯にはなるけどな

>>536
転送量分散の話をしてるんだけど？

ライブ配信で転送量分散になるのは、
それを見ている人が必要なデータを
別の必要な人に配信するからであって、

必要とされないデータを転送すると
転送量が増えるだけなんだけど。

>>515についてですが、
私が勘違いしてるのかもしれないですけど、いわゆるTCP/IPスタックで走らせる以上IPアドレスを無視することはできないでしょう。
いわゆるTCP/IPスタックを使わないにしていも、IP/Ethernetは普及率の問題から絶対的に使うことになりますし、今更低レベルレイヤの設計をするメリットが感じられません。
ひょっとしてノードIDを利用してノードを特定するという意味でしょうか？それでしたら既に実装されていますが。
どの道メッセージが載るのはインターネット網なのですから、IPアドレスとは必ず付き合うことになります。

「ポート解放」ですが、本来インターネットはP2P的な通信方法を主眼としていましたし、それに使うアドレスが枯渇しそうになったり、回線を共有したほううがコストが安くなるという事情からNATのような技術が出たわけです。まあどう呼んでもいいんじゃないですか。
ちなみに、私はポート解放というとファイアウォールの解放をイメージしますし、ポート変換/転送というとルータのPort forwardingを思い浮かべます。
住人同士にその辺の勘違いがあるんじゃないですか。

？？？
SOAPもSMTPもTCP/IPより下位レイヤだと思ってるのかな？
さすがに無知すぎるからないよね

話は追えてないけど、文面見た感じだとIPのレイヤ無視した議論になってるのかな
アイディア書くのはいいけど、既存の技術の積み上げ無視すんのはやめてくれろ
そして今度はNAT越え用アプリケーションの話かな？

NAT越えだとこの辺見るずら
こいつらUPnP使わなくてもNAT越えできる（必ず越えられるとは言っていない）
http://ja.wikipedia.org/wiki/STUN
http://ja.wikipedia.org/wiki/TURN

>>539
IPアドレスを使わないうんぬん...といった話が出たようだったので書かせていただきました。
SOAPやSMTPをHTTPに代えても問題は無いと考えていますが、単に使いやすいという都合でHTTPを利用しています。

そもそも自動的にNATを越えさせる必要があるのでしょうか？
NATを越えさせる話は話題違いのような気もします。

まあ、IPv6が普及してくれるのが一番楽です。

>>525
> SOAPは拡張可能で分散的なフレームワークであり、HTTPやSMTPなど
> 様々なコンピュータネットワークの通信プロトコルで利用することができる。--Wikipedia
UPnPだのホールパンチングを内包したSOAP*実装*の上に乗せればその辺り見る必要はないけど、
*見ない*事にしてるだけでSOAP*自体*はUPnPの代替になってるわけじゃねーだろ何言ってんだ。
「ファイアウォールが気になるならUPｎPよりSOAPを実装」ってとこに突っ込んでんだから名前解決以前の問題
>>530
違法云々じゃなくてポート転送設定ないしUPnPを不要とする場合にどうするかの話じゃね？
>>531
通信のボディ部を直接RSAで暗号化して通信する馬鹿な実装はそうそう無ぇと思うぞ？
オーバヘッド気にするなら借り物プロトコルでゴテゴテ修飾すればするほど重くなるからシンプルに。
>>532-533
Opera UniteはNATで通信失敗したらサーバクライアント方式にフォールバックする。
そもそもOpera自体が縮小してるから乗っかるのは無理だな。
てか名前とURI位でいーよ、タイトルや引用文多すぎて見づらい…
>>538-540
なんかもう彼はWS-Iとかのベンダの食いつきが良さそうな辺りの話を主食にしてる感じで、
OSI参照モデルでいうところの1〜7層じゃなくて9〜10層で生きてる類の人間な気がする。
>>541
TRUNはただの中継サーバだからP2Pで(もといnyとかで)ポート0って言われてる状態だな。
その近くにあるhttp://ja.wikipedia.org/wiki/NAT_traversal の記事の方が網羅的かも。
http://ja.wikipedia.org/wiki/Interactive_Connectivity_Establishment の方にはオプソの実装ライブラリのリンクも。
>>542
それよりも先に考えること有るだろうってのはそのとおりだから、保留にしといても構わない話だとは思うけど、
ユーザ数稼ぐって意味では最低限必要なサーバ動作可能なノードを手軽に確保する為にNATは越えたいかと。

あー、わかった。

アプリからは、SOAPでもHTTPでもなんでも切り替え可能なように作ればいい。
そうすれば、SOAPでもHTTPでも好きなものに入れ替えればいいから
SOAPでもHTTPの話はする必要ないな。

お前ら何の話してるの？ｗ

Proof of workって匿名掲示板でも使えそうだよね
掲示板への書き込みに30秒程度の計算を要求するとか

>>544
だから、一番初めにプロトコルに拘る必要が無いと書いたんだがなぁ

それよりは、流通している古いバージョンのデータと前方互換、後方互換双方である方が重要
そういう意味でメタデータが扱えるプロトコルの方がね、ってことだよね

確かに、XMLならプロトコルの拡張なんかは簡単かもなー
個人的にはSOAPは冗長すぎて嫌いだし、今時XMLで通信するのもちょっとなと思うけどね
好みの問題だが

しかし話題が変な方向に行ってるな
P2Pネットワークにしてみれば、プロトコルなんて通じればええんやで

何を使ってもプロトコルの拡張は簡単だろ。
それがHTTPであっても。
新たなコマンドを作るだけ。

実際に送受信される本体に関してはASN.１での記述になるだろうよ。
そうでなくて、それ以外にやり取りしなけりゃならない、アドレス解決、キー、マスター情報、サブカテゴリInfo
あたりに関しては、バイナリで構築しちまったら首が回らなくなる

それでなくとも、通信経路のプロトコルに柔軟性を持たせるのであれば、
TCP/IPのみのユニキャスト通信とはことなるところが非常に多く出てくる

インターフェースさえきっちりしてりゃ、
NGNでもDSLでも、サブドメイン内での通信でも、X.25でも、WAP1.2でも
それこそ、ATMでも構わないことになるのは大きなメリット
ジャンボフレームに対応した高速通信までは対応が難しいけど
互換性は保たれる( まあこの場合はパケット単位での多重化かな？)

拡散する場合は、無理にTCP使わんでも、別段UDPでも良い訳だよ
だったら、マルチキャストも使えるかもねぇ〜

ｲｯﾄ企業の営業みたいな奴だな

>>549
別にバイナリで構築してもなんの問題もない。
ほんの一1イトのバージョン番号フィールドさえあれば
なんの問題もない。

プロトコルはTCPとかUDPぐらいで、通信路に流すフォーマットは作り手が自由にしていいだろ。

ASN.1わらた
RFCですら状態遷移図とBNFやろ

初心者と資格取り立ての説教強盗のせいで荒れてるのか

インターネット上のOLNの話してるのに、
IP以下やUDPのマルチキャスト考えるとか意味不明やろ
自分語りや知識自慢したいなら、知恵袋でも行ってこい

アルファベット数文字の略称で言われてもわかりません

すまんOLNの事だな
overlay-networkという意味
他に使ってる奴がいたので、通じるのかと思った

SOAP SMTP MIME ESP DNS
NAT ALG UPnP HTTP UDDI
P2P RTMP RSA RTP RTCP
ATM PDH SONET SDH OSI
TRUN NGN DSL ASN RFC
BNF OLN

これらの単語を使って文章を作りなさい

OLNはP2Pの話だとかなり般的な語なんだがな

>>557
分からないことは恥ずかしいことじゃない、いいね？

ほかに何か話すことは無いんですかね

>>558
はい、恥ずかしく無いですよ（笑）

>>553
BNFで記述した定義の具体的実装の1つがASN.1だろ
初心者杉わらたｗｗｗ

>>561
ASN.1がBNFで実装されてる？の意味はわからないが、
BNFで定義されてるとして、何の関係があるんだ？
もしかして、ASN.1の中でBNFが使われてるって言いたいの？

こっちの意図としては、ハードウェア標準寄りで
ガチガチな定義で使われる物を、こういう話に出すのが場違いだと言ってるわけ
専門用語を振りかざして気持ちよくなってるだけだろと

>>562
ちょｗｗｗ
お前は何を言ってんのｗｗｗ

中途半端な知識すらもっていないのに、変に噛み付くからおかしなことになるんだよ。
ASN.1のどこがハード寄りなのかねｗｗｗ
大笑いしたｗｗｗ

つまんねー流れ

つまらないならお前が面白くすればいい。

すまない構ったのが間違いだったようだ

有る意味十分おもろいよｗｗｗ

　 　　　 　　 　＿＿＿_
　　　　　　 ／ ＼　　／＼　ｷﾘｯ
.　　　　　／　（ー） 　（ー）＼　　　　「ASN.1はハードウェア標準寄り」
　　　　／　　 ⌒（__人__）⌒ ＼
　　　　|　　 　　　|r┬-|　　　　|
　　　　 ＼　　　　 `ー’´　　 ／
　　　　ノ　　　　　　　　　　 　＼
　 ／´　　　　　　　　　　　　 　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一””””~~｀`’ー?､　　　-一”””’ー-､.
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))
　　　　 　　　 　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ　　　だっておｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒)
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/　
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/
ヽ　　　　/　　　　　`ー’´ 　 　 　ヽ /　　　　／
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　バンバン
　ヽ　　　 -一””””~~｀`’ー?､　　　-一”””’ー-､
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

177って名前欄に入ってたらもう構っちゃ駄目ってことでよくね

> 177を支持する理屈も説明できずに支持した挙句に罵倒し散らかす奴がいるってのは
> 177〜300くらいの流れで解ってるんだからその説明が無い支持はスルーしろよ
> ｲｯﾄ企業の営業みたいな奴だな
> 初心者と資格取り立ての説教強盗のせいで荒れてるのか

>>562
こういう奴って揚げ足取られそうなことばかり言うくせに揚げ足取るのは上手かったりするから
ツッコミ入れるにも軽く調べてからの方が良いかもね。スルーするのが一番かもしれんけど。

ところで大きめのデータをP2Pに流す時、どうやってRAIDみたいなデータ保護を実現します？
さすがに信頼できないノードに単一のデータを流すのは心配。

ttp://www28.atwiki.jp/cryptospace/pages/155.html

関係ないけどこんなのあった
ストレージ証明　ってやつ
暗号を使ってサーバとかが大きい容量のデータをちゃんと保管していることを証明するプロトコル

（データの容量より少ない量の通信で保管していることを証明できる）

信頼できないネットワークにおいて完全性を確保するための現実的なテクニックは
１．暗号
２．署名
３．アクセスコントロール

後は分かるな

>>569
RAIDみたいなデータ保護とは？
ノードの故障・脱退によるネットワークからのデータ消失を防ぎたいってこと？
Chordなら確か、SuccessorListの担当範囲も保持しておくって方法が用意されてるでしょ
Kademliaはデータを持ってるノードが定期的にDHT上の担当ノードに送るようになってる
これに関しては何とかしてデータをコピーしていくしかないよね
後はGnutellaみたいな方式の古典的なP2Pを組み合わせるとかか

いや、勘違いしてるっぽいな
「流す時」ってのはデータを作って最初にネットワークへ流す時のことか
大きいデータだから多重化はしたくないのに、送った先のネットワーク環境が劣悪だったり
もしかしたらデータを全部捨てちゃうスパムノードだったりするかもしれない

欲しいデータが○とすると、持ってるPCが送信するときに(○△□)とパックして送る。△と□は、ネットワーク上に少ないデータ。

>>574
煽ってるつもりはないがとりあえず勉強してから現実的な仕様の提案を頼む

>>575
同感だなぁ
インターネットは国境が無いと勘違いしている奴が多すぎるんだが、
実際には国境の壁もあるし、地域の壁もある

国が違えば需要が違って当然なんだが、
需要が少ない海外の要求を国内に流されてもなぁ
そもそも、
自立システムが疎結合しているわけで
需要が無いとか有るとかの判定ってものすごく難しいんだが

95%タイルで需要があると決められたとしても、そのくらい時間を掛けて判定するの、とか
Shareの被参照ってどんなアルゴリズムだったのかは興味あるところだね

国境……？ 海外……？

ネットワーク上のデータを冗長化するためのアイデアっぽいし、需要がどうのとか関係ないのでは

冗長化するために送るデータをどう選定するのか、という話をしてる

>>577
こういう奴って、DNSのルート(例えばJ)　は物理的に1台しかないと信じてるんだろうなぁ

やはりレプリケーションするのが現実的ですね。
私はChordを使っているのでSuccessorList分のデータをコピーする方式にしてみます。

それで一旦実装してみるのは構わんと思うけど、
２〜３回位のレプリケーションなら発信者をIPアドレスレベルで特定されちゃうよ
そういう技術が既にある
もっと多重化してもよいけど、それってまさにオニオンルーティング
暗号しちまえば違いがほとんど無くなる
そのとき、オニオンルーティングとの違い(というかそれと比較したメリット)
はきちんと考えているんだよね？

オニオンルーティングとレプリケーションは排他的な仕組みではないから同時に使ってもいい。
オニオンルーティング等の上で全部やれば総消費帯域幅が10倍とかに達する以外は問題ない。
帯域節約するにしても、初段だけオニオンルーティングするとかすればいいからまぁなんとか。
というか発信者特定を避けるなら他人へのプッシュに成功したら発信者はデータ破棄じゃない？

そもそも、レプリケーションする単位(≒読み取り可能な状態)でレプリケーションのリレーしてたら
多重暗号化はできないし経路上にデータ置けるしオニオンルーティングとは似ても似つかない気が…

オニオンルーティングの欠点は
入口と出口に当たる人にはばれるってことなんだよな。
完璧じゃない。

もしかして、理想的なネットワークが構築されることを前提に作ってないか？
匿名化をどう考えているのか疑問

>>584
P2P上に構築する場合、入口でバレるのはネットワークに参加しているという事実だけ
掲示板を構築する場合、出口でバレる情報は公開情報だからバレても痛くも痒くも無い
特定ノードの入出力を全て監視しても、自発的な送受信量と転送通信量しか分らない
自発的送信量が増加したタイミングで行われた投稿をそのノードの投稿と推定する事はできるけど、
確定情報ではない上にオニオンルーティングプロトコルに時間差転送を組み込めば十分撹乱できる
オニオンルーティングに使用した経路上の全ノードの入出力トラフィックと出口ノードの公開出力を集約しないと特定は無理じゃないかな

>>586
？
入り口でばれるのは、書き込み者のIPアドレスと書き込んだ内容

>>587
暗号化しない通信転送はオニオンルーティングとは呼ばないと思うよ？
(≒オニオンルーティングで転送している間の転送量は全て匿名の代償として消費され情報の共有に繋がらない)

>>587
ネットワークの中に居るんだから入口からは書き込まないんじゃ

あまりにも低レベルなレスで絶句したが・・・

暗号しててもバレルのよ
残念ながら

そもそも暗号化してるから大丈夫！
ってそれどうやって他の人読むの？って話だよな。

今度は暗号君かぁ
このスレのレベルうｐまでの道のりは長いなぁ・・・

そういえば、国境……？君消えちまったねぇ
ちった勉強できたのかな？

>>590
いやいやいやいや、オニオンルーティングの暗号化ちゃんと知ってて言ってるの？
暗号化という名前の難読化じゃなくてちゃんと暗号化してるからな、アレは。
RSA+AESで実装されたオニオンルーティングでもバレるとか言うなら暗号学の大事件なんだが。
(念の為：鍵配送に失敗してる場合や、TORの場合の「ローカル」SOCKSまでの経路の話を除く)

>>591
オニオンルーティングの場合は各中継ノード一人が読めればそれで良い訳だが…
中継ノードの公開鍵をどうやって入手して検証するかってのは問題だが、それだけ

>>593
馬鹿？
HTTPSが盗聴できないとでも言いたいみたいだなｗ

先は長すぎ・・・

＞公開鍵をどうやって入手して
ｗｗｗ
今頃かいｗ

>>582 の段階でそれを踏まえてるんだが、馬鹿だから気にも留められないんだよなｗ

だめだこりゃ。

>>596
確かにｗ
自分をあまり卑下しない方が良いよ

ちなみに、
Shareの場合、多分RSA+3DESだと思うけど、ふつうに読まれてるからね
え？
その話、知らなかった？ｗｗｗ

で、
国境君、何処言ったのｗｗｗ

>>597
RSA が何ビットかにもよるしねえ，いまどきなら 1024 ビットでも足りないか
個人的にはデフィーへルマンがよさそうだ

>>599
はあ？？？？？


お前、勉強足りないっちゅうの

量子コンピュータの普及も考えて、耐量子コンピュータ公開鍵暗号を用いるべきでは？

お、冷静になろうｗ
あまりにも馬鹿すぎで涙がでるわ

１．bit長は関係ない
Shareの事例の場合、4096bitでも普通に読めてたよ。多分1024bitだったんだろうけど

２．デフィーへルマン・・・
ああ、そう思ってくれ
Torなら普通に君の送受信データを軒並み読ませてもらうから



で、国境君はどこへ？ｗｗｗ

>>601
今は小手先のアルゴリズムで対応するしかない
そういう暗号を見つけ出すのは我々の仕事ではないし、
まじめにノーベル賞レースに出ている人たちが頑張る話だと思うよ

>>603
だから、いつでもアルゴリズムを変更できるように、
アルゴリズムを設計から切り離した設計にすべきと思うよ。

>>604
そだね

具体的に言えば、
キー探索と
データ
は完全に分けたほうが良い

それから、
オーバーレイ上の仮想ネットワークも分けた方が良い

特に、3つ目は、転送効率や、ネットワークに大きく依存するから、自分でコーディングしない方が良い
インターフェースを公開して・・・の流れがよいと思う

さらに・・・

暗号アルゴリズムは完全に分離したほうが良い
想定されるトポロジーも分離したほうがよいけど、場合により設計思想とクロスオーバするので微妙

だからSLAや要求事項をまとめるのが先かな？とは、思う

さあ、Google先生の授業が開始されたようですね(はあと
終了日時が未定なところも面白いところｗ


さて、国境君は何処へ行ったのでしょうか
＞国境……？ 海外……？
＞国境……？ 海外……？
＞国境……？ 海外……？
＞国境……？ 海外……？
＞国境……？ 海外……？
面白すぎます

暗号君もGoogle先生の授業のようですｗ
渾身のメッセージを残して行方不明中ｗ
＞RSA が何ビットかにもよるしねえ

落ち着け、俺はずっと読んでるよ

面白すぎます

HTTPSが盗聴できる、って脆弱性のある暗号化方式を使ってる場合の話でしょ？
公開鍵暗号はNSAによって破られてるとかって話か？w

TorがHTTPSなんかより弱いのは当たり前だし、なんで引き合いに出したのかわからん

>>609
芸人魂が燃える。

>>610
RSA余裕

>>602
＞１．bit長は関係ない
＞Shareの事例の場合、4096bitでも普通に読めてたよ。多分1024bitだったんだろうけど
RSA-1024(1024ビット数の素因数分解コンテスト） はまだ解けていないんですけど？http://en.wikipedia.org/wiki/RSA_Factoring_Challenge / http://en.wikipedia.org/wiki/RSA_numbers#RSA-1024
share の脆弱性は暗号以外のところにあったんじゃないですかね？

＞Torなら普通に君の送受信データを軒並み読ませてもらうから
デフィーへルマン＝離散対数問題も容易にとける問題じゃないと思いますよ．

＞お、冷静になろうｗ
http://hissi.org/read.php/tech/20140409/YnJNN2hFTGE.html　(ｗｗ

なんだお前ら俺が働いてる時間帯におもしろレスしやがって
よ〜し、じゃあパパHTTPSの暗号を頑張って素因数分解で解いちゃうぞ〜（煽り）

Torは暗号化より、経路を分からなくする目的だろ。
暗号化とも両立できる。

PolyPassHash

不勉強な奴はRSA暗号とHTTPSとSSLのWikipediaを読んだ上で
C言語でSSLの実装をやれ

とりあえず読んで理解してからレスしろ
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

RSA暗号
http://ja.wikipedia.org/wiki/RSA%E6%9A%97%E5%8F%B7

SSL
http://ja.wikipedia.org/wiki/Secure_Sockets_Layer

ここを参考にプログラミングの課題をやれ

SSL/TLS の導入 (1)〜(4)
http://x68000.q-e-d.net/~68user/net/ssl-setup-1.html

>>616
BigInteger とか ProbablePrime のある Java を許していただけますか？
http://www.amazon.co.jp/dp/4627847610

>>612
レベルが低すぎて、頑張れ、としか言い様がないなｗ
ちみ、HTTPS盗聴できたことないでしょ
俺はあるんだけどｗｗｗ

>>616
でも、一般的なHTTPSの盗聴方法は書いてない不思議ｗｗｗ

>>618
DH鍵交換はまさに「盗聴」に対処する為のアルゴリズムなの。せめて鍵交換を突破できる「中間者攻撃」を覚えよう
SSLには証明書があるので、中間者攻撃されたら認証に失敗するだけなんだけどね

>>616
RSAしか実装したことないけど勘弁してね

>>620
ルートまで辿り着けるRSAより、DH方式の方がMonkeyInTheMiddleしやすいってことに気付けよｗ

>>621

> DH方式の方が
その通り、DH「鍵交換」だけなら中間者攻撃には無力。だから公開鍵暗号による署名を併用してる。

……って>>620でも書いたんだけどな。
> SSLには証明書があるので


> MonkeyInTheMiddle
それを言うならman in the middle。おさるさんじゃないよ〜

1. 匿名化、暗号化をどうするのか
2. 書き込みとログを分けられるのか

この辺がわからないまま。特に2.の方をどう認識してるのか
ネットワークが二つに分断された後に一つに繋がった場合、
ログの不整合が起こるけどそれをどう解消するつもりなのか
それを考えた上で2.をよく考えてみて欲しい

>>608
で、国境は見えなかったんだな
勉強が足りんよ

>>622
ちみ、地雷踏んでるよｗｗｗｗｗｗ
知っている人なら分かるワードだよ

>>625
monkeyの方もあるとは知らなんだ。

とんでもない脆弱性があるのかと思ってすぐに探したが、
今読んだところ、暗号技術とは何の関係もないじゃないか……損したわ
ブラウザが、ユーザが警告を無視して要求すれば証明書の認証をすっとばしちゃうところを突く攻撃だからね

で、DH鍵交換は無駄だって？ 公開鍵暗号は盗聴できるって？ｗ

>>623
有る意味正しい

暗号化は、情報を秘匿する以外にも機能がある
Key探索とデータは別に流通させるべき(匿名性）であり、
データ流通は効率を重視しなければならない

俺が思うに、ログは不整合が生じるだろう
Notes/Dominoでいう競合文書ができても構わない仕組みじゃないと耐えられないと思う>>626

最近暑くなってきたから煽ってしまった、すまんな

>>623
ログという形で保管するのには不整合以外にも色々不都合があるよなー

>>626
ふつうmonkeyは無いよ
manページで確認できる程度
つか、manページあるのねｗ

＞暗号技術とは何の関係もないじゃないか
多分大きな勘違いをしてる
暗号技術で最大の問題であり、最重要な課題は、暗号アルゴリズムでなく、認証だよ

>>629
>暗号技術で最大の問題であり、最重要な課題は、暗号アルゴリズムでなく、認証だよ
まあ、認証は確かに大事だな。反省しよう

さっきまでRSAやDH鍵交換などのアルゴリズムを脆弱だとひたすら主張してた人も居るけどね？

>>618
ふーん、じゃ、君は明日にでも http://en.wikipedia.org/wiki/RSA_numbers#RSA-1024　を破って10万ドル 1000万円 get するんだ、うらやましいねえ
http://en.wikipedia.org/wiki/TWIRL はまだ hypothetical　だけれども、RSA-1024 が破られるのも時間の問題という人もいるしね
実際のところどうなんだろう

>>630
だから、その認証をCAではなく、ネットワークにやらせる必要があるんだわ
できれば、クローラを排除できる(多分多数決？)仕組みも必要

クローラに頑張って暗号しても意味無いからねぇ
それが理解できるまでに2日以上も掛かるんだから大変

>>631
ちなみにさ、

それって、まだやってんだっけ？ｗ

>>632
自分のはSSLの話だよ〜
Pure P2Pは原理上中間者攻撃を防げないのでSSLに関するここまでの話は糞の役にも立たないよ

>>634
＞原理上中間者攻撃を防げない
その自信が何処から来るのか、皆目検討も付かんｗｗｗ

>>633
ダメリカの56bit鍵規制、d.net の RS5-64 ともいっしょに、こいつもおわってたんだね‥‥
http://www.emc.com/emc-plus/rsa-labs/historical/the-rsa-factoring-challenge-faq.htm#WhyIs

RC5だったか‥‥

昼間書き込めなかったから書く

オニオンルーティングが何なのか少しは読んで勉強してから書き込んだらどうよ。
オニオンルーティングの「ネットワーク」つうのは書き込む側や出口からの便宜的な名称で、どのみち書き込む側からは別の入り口を探すことになる。
自分が中継ノードだとしても同じことになる。
だから出口問題は常に表れるし、Torを使うに当たって暗号化も施すのは半ば常識。
Torを使わずにオニオンルーティングをやろうってんなら別の話になるが、そんな手間をかける意味がわからない。

オニオンルーティングは通信を暗号化する技術としても使えんではないが、本来は通信路を撹乱して隠匿するための技術だ。だからどの道メッセージは暗号化しなければならない。

さて思うに、匿名で書き込むのと通信路を匿名化するのを別に考えたほうが生産的だ。互いのIPアドレスを確認できなくするべくTorのhidden serviceを適用する前提で話を進めたほうが無駄な議論を避けられる。
既にある機能は最大限に利用するべき。

Torを使うと
・通信路を撹乱する
・相手の実際のアドレスが不明になる
・hidden serviceで特定できる

「自らの手で実現しなければならない機能」が明確にできる。

ちなみにTorの場合は入口ノードには内容はわからん筈だ。

連投で申し訳ない。
このスレのレベル向上のためにトリップを導入すべきだ。
常駐している住人は酉を付けて欲しい。
相互理解がしやすくなるし、相手の意図を汲みやすくなる。

>>638
出口問題が分かってるんなら、理解できるだろ

＞ちなみにTorの場合は入口ノードには内容はわからん筈だ。
出口はIPアドレスだ

念のためもう一言言っておこうか
悪意のある中継ノードが無作為に次の中継ノードを選んでくれると思えるのか？

さらにもう一言言っておこうか？
悪意の無い中継ノードだという判別はできるのか？

やっぱり認証の問題になってくるｗ

>>641
Torの中継ノードは前後の中継ノードを知ってるけど、選んだりはしないしそもそも選べない
オニオンルーティングの「オニオン」のお陰でな

中継に使うノードは、あくまで通信路を開こうとしてるノードが全部決めてる
何のために、各中継ノードの公開鍵がディレクトリサーバに保存されてると思ってるの？

今のところの結論
捏造改竄クローラに対抗するには、同じメッセージを複数の中継ノードにばら撒け
spam 屋クローラに対してはベイズフィルタを使え

>>643
頭悪いなｗｗｗ

＞あくまで通信路を開こうとしてるノードが全部決めてる
あくまで通信路を開こうとしてる悪意のあるノードが勝手公開鍵を作りながら勝手に転送先を全部決めてる

ってことだろ？
それとも何かい
中央サーバやディレクトリサーバが次のノードを決めているのかい？ｗｗｗ
低脳もここまで来ると、な

>>644
そりゃ、良いアイディアじゃね

>>645
＞通信路を開こうとしてる悪意のあるノードが勝手公開鍵を作りながら勝手に転送先を全部決めてる
‥‥

＞勝手公開鍵を作りながら
公開鍵は接続先からもらうもの、開こうとしている側からは作れないものなんだが

＞勝手に転送先を全部決めてる
悪意がないノードでも転送先が転送路を全部自分で決める >>72

MD5 - Wikipedia
ハッシュの衝突耐性について[編集]MD5のハッシュ値については、パソコンレベルで、数10分程度で、同一ハッシュ値の非ユニークなデータ列を生成できる実装が広まっている。
SHA-0/SHA-1アルゴリズムについても、MD5ほど容易ではないが突破される脆弱性が発見されている。
ただし、任意に与えられたハッシュ値に対して、データを生成する実装が広まっているわけではないので、弱衝突耐性が容易に突破されうる訳ではない。
また、任意に与えられたハッシュ値に対して、改竄者の意図どおりのデータ列を容易に生成できる訳でもない。


SHA-2 - Wikipedia
2005年、SHA-1において数学的な弱点によるセキュリティ脆弱性が発見され、より強力なハッシュ関数が求められるようになった。
SHA-2にはSHA-1と類似する点もあるが、SHA-1に有効な攻撃をSHA-2に拡張することは達成されていない。
2014年1月現在、原像攻撃ではSHA-256にて52ラウンドまで、SHA-512にて57ラウンドまで、衝突攻撃ではSHA-256の46ラウンドまでが最良の攻撃法である。
現時点では衝突攻撃のみが現実的な可能性を有しているが、フルバージョンのSHA-2に対する攻撃は成功していない。

>>647

そもそもだが、>>72 の説明間違ってない？
説明どおりなら、余裕だわ

んでディレクトリサーバの認証はしてるんだよね？
まさかIPアドレスとかじゃないよねぇ？

>>645
> 勝手公開鍵を作りながら勝手に転送先を全部決めてる
勝手公開鍵とは何だ？
中継ノードとの通信には中継ノードの公開鍵を使うんだよ。
始めのノードとの通信には始めのノードの公開鍵、始めのノードを経由しての次のノードとの通信に次のノードの公開鍵を使う。

これぐらいTorの公式サイトにも書いてあるだろ。調べろや

>中央サーバやディレクトリサーバが次のノードを決めているのかい？ｗｗｗ
違うよ。ディレクトリサーバは公開鍵を持ってるだけ。

>>650
だから、レベルが違うっていってんだろ

＞中継ノードとの通信には中継ノードの公開鍵を使うんだよ。
それって、正しい公開鍵なのか？それをもらったディレクトリサーバは正しいサーバなのか？
いつ、誰が、どのようにして、何を確認して、正しいと認識できたんだ？
偽者でも通るプロトコルだろ

＞始めのノードとの通信には始めのノードの公開鍵、始めのノードを経由しての次のノードとの通信に次のノードの公開鍵を使う。
公開鍵方式わかってんのかな？ｗｗｗ

＞違うよ。ディレクトリサーバは公開鍵を持ってるだけ。

　　だ　　め　　だ　　め　　じ　　ゃ　　ん

>>651
そうだよ、ディレクトリサーバは弱点なの
不正するには、不正なTorノードもたくさん要るけどね

>公開鍵方式わかってんのかな？ｗｗｗ
こっちの言葉が悪いのかなぁ。自分にはこうとしか言えないんだけど
経由するノードの公開鍵が分かってるんだから、
・Aとのセッション鍵交換をAの公開鍵で暗号化して行う。
・Aを経由して、Bの公開鍵で暗号化してBとセッション鍵を交換する
・AはBの秘密鍵を知らないから、安全にBとも通信できるようになる。これを数ホップ
うーん……

これがオニオンルーティングの元になったアイディアの図
この公開鍵の矢印をディレクトリサーバが担ってる訳

http://homepage3.nifty.com/toremoro/gif/tokumei2.GIF

元になったアイディアの図っておかしいな。
オニオンルーティングは、この図が説明してるMix-netの応用なんだよね

>>652
問題はいくつもあって

ほ〜んとうにそもそもだが、 >>72 間違えてるだろ？
実装してみりゃ、一発で分かるレベルだわ
それに対して今まで突っ込みが無かったこと
そんだけレベルが低すぎってことよ


で、もう一回書くぞ

出口問題が分かってるんなら、理解できるだろ

＞ちなみにTorの場合は入口ノードには内容はわからん筈だ。
出口はIPアドレスだ

>>655
そりゃ>>72も461も間違ってるけど、君もまあ微妙やった訳やん？

> 出口はIPアドレスだ
出口はIPアドレスだ、って文の意味がさっぱり分からんが、

・出口になるノードが分かるのは通信内容と通信先、そして前の中継ノード
・中継するノードが分かるのは後の中継ノードと、前のノード(これが別の中継ノードか、それとも書き込み者なのかは区別できない)

出口ノードには通信先のアドレスが分かるって言いたいのか？

>>655
全然間違いが分からない俺に教えて

>>657
オニオンルーティングというかTorの場合、

・通信自体の暗号化には公開鍵暗号を使わない
・こんな風にデータをまとめて暗号化して送ったりしない。暗号化された通信路を先に構築し、10分ぐらい使い回す

>>658
それだと、Torという実装の話ではなくオニオンルーティングの話をしてる>>72は別に間違ってないよね？

>>659
おもいっくそ間違えてる
実装してみ

つか、ヒントをやろう

Subject を明確にしろよ

Subject
1)　A
2)　A
3)
4)
5)
6)

>>661
1)　A
2)　A
3) A
4) A
5) A
6) A

>>649
オニオンリングなら >>72 でいいとおもうよ
認証？
P2P に認証サーバーを立てたら P2P にならない
というかディレクトリサーバーとか NT ドメインの話がどうしてここで出てくるの？

>>663
なんでNTどめいんやねん
古いなｗ

せいぜいNIS+とかKerberosとか言ってくれればねぇ
ypでもいいけど、あの内容でNTドメインはないだろ
ADとかいうならまだしも・・・

LDAPもいいんだけど、OpenLDAPは曲者だからなぁ
毎回苦労させられる
まあ、厳密性を追求すりゃそうなるのかもしれんが。


あ、
すまん、
ちょっとばかし本職の内容だったもんでな

>>660
「公開鍵で全文を暗号化するのは確かにコストが高いから、普通は共通鍵暗号で暗号化しておいて、共通鍵のみ公開鍵暗号系で処理するというハイブリッドでやる」
といいたいだけなの？

なら　>>72 でおおかたあってるよ

>>664
sun os の yellow page とか古いのはどっちもどっちだろう？

>>664
答えを、>>72の間違いを教えてください。

>>667
>>664 は本職屋さんがテキトーにキーワードを散りばめて遊んでいるだけだから
「子犬も子供のパンくずはいただきます」(*1マルコ7:24-30)‥‥‥おこぼれください

やっとhidden serviceを使おうかって方向になったのかな？ほんと時間かかり過ぎでうんざりって感じだが
hidden service を使うなら出口問題とやらは無いはずだけど

２ちゃんねる分裂の危機だから、開発してるやつはうまく時代に乗ろうぜ。

荒らし対策とかってあんまり複雑に考えることはない気はするんだよな。
荒らされてるスレに書き込む奴はまず居ない。というかだからこそ荒らしになる。
つまり生きてるスレの対策ならば書き込みのついでに
任意で承認（つまり逆に言えばNGの）情報を流す程度で充分なんじゃないかな？

>>662
だ〜よ〜ね〜

つまり、Aと何がしの間にProxyを噛ませば余裕ってことやん
だからOverとかOverlayとかが必要になってくるんだろ

>>672
どういうこと？全然別の話に思えるんだけど。
オニオンルーティングとして>>72はどう間違ってるの？

×悪意がないノードでも転送先が転送路を全部自分で決める >>72
○悪意がないノードでも転送元が転送路を全部自分で決める >>72
訂正しとくわ

>>669
tor の hidden-service って https://www.torproject.org/docs/hidden-services.html.en をみるかぎり PK を管理する「なんでも知ってる」 DB が存在するのね
大丈夫なの？

そもそもIDなんて何に使うの？
暗号使うなら後出しトリップみたいなのはいくらでも可能なんだから、
後は気に入らないレスをNGする位にしか使えなくね？

>>675
後だし捏造レス

>>674
んあ。
なら理解できる

>>676
それができるならビットコインとか大変じゃないかな？

>>678
まず、算数から勉強しなさい
後だしでも掘り出しゃ勝ちなんだよ


国境君が地下にもぐっちまっておもろないんだが、
ディレクトリサーバの件

グローバルIPアドレスなんざ、多少重複してもなんとでもなるんだよ
電気通信事業法をガン無視すりゃ、なんとでもなる

>>678
ビットコインはそれを防ぐためにバカみたいな量の計算リソースをつぎ込んで
真の取引を認証してるわけじゃん。
結局はつぎこんだリソースの多い方が勝つ。
しかし、不正な取引を認証してしまうと信用がガタ落ちになって
ビットコイン所有者全員が大損をこくので、逆にそれが保証となっている。
ビットコインはそのリソースをつぎ込むインセンティブを用意してるけど、
掲示板なら荒らしに対抗するだけのリソースをつぎ込むインセンティブなんてないっしょ。
荒らしの捏造レスが横行したところでみんな使わなくなるだけで、
それこそ荒らしの思う壺だしね

>>679
よう。
まともにアルゴリズムが実装できない人。

10分更新を、10秒更新にして、ブロックチェーンを確定したらいい。
それほど頑丈でなかったとしても、確定済みデータを書き換えることは、
参加してる最速マシンの何倍、何十倍の速度がいるだろ。データ量次第だが。

>>679
掘り出すってあれ要はトリップ探ししてるだけじゃないか？
全部一致したら偽造できちゃうけど、
そもそもたまにヒットする程度の桁数の一致で掘り出したことになる訳だから、
取引偽造できる未知のテクノロジーがあるならこっそり掘ってればいいって話。

>>680
荒らしを認証するのは荒らしだから、正常な枝とは隔離されると思う。
乗っ取りに成功しても、次に書きこむ人が捏造を承認しなければ
スレの捏造レスを消去した枝は過去の正常な枝と同じものになるから、
衝突分は新着として復活してきて、次の人がそれを承認すれば、
それが正常な枝として成長していくんじゃないかな？

590、592、594あたりでID:brM7hELaやID:5FPqNoMqは177と同じだって気付けよ。
それらしい単語をちりばめて知識でシッタカした挙句に、
具体的な事を聞かれると低レベルだなんだという煽りで返し始める。
この話題の場合、最後の逃げ道は「現代暗号は総当りで解けなくも無い」っていう極論あたりかな。

>>610
ルート証明書をインストールさせるあたりから話を始めそうな気がする。
>>612
鍵配送や暗号化範囲の問題で読める事例引っ張ってきて騒いでるんじゃない？
Shareの場合は鍵交換前の通信はただの難読化だから問題なく読めるし、
暗号化ルーティングは無いから中間者や通信相手には読めるとかそういう当たり前の話。
>>614
多分彼はオニオンルーティングのオニオンがどういう意味か知らないんだろう。
何せShareとかのバケツリレーとオニオンルーティングを混同するレベルだし。
>>616
理解してレスする気が無い奴が一匹混ざってるから、見つけたら無視したほうがいいと思う。
当然の知識を前提に踏み絵させるあたりがいいんじゃないかな。
>>638
理解してから書き込み気が知ったかもしくはそれを装った荒らしだろうし何言ってもムダじゃね？
>>639
今のところは騙りされてるわけじゃないし名前欄だけでも十分な気がしなくも無いが・・・

>>685
＞最後の逃げ道は「現代暗号は総当りで解けなくも無い」っていう極論
一般数体篩法でRSA-768 まで解けたので、RSA-1024 も時間の問題といわれ続けてはや云年
でもさすがにRSA-4096 がすらすら解けるわけにはいかないね

まったく、知ったか無能野郎のせいでスレが汚れちまったぜ
2chではよくあること

>>685
残念だねぇ、本当に残念だよ、ちみ
＞この話題の場合、最後の逃げ道は「現代暗号は総当りで解けなくも無い」っていう極論あたりかな。
つまり、ちみの限界ってことだね
もう思い浮かびません、と

自分で低脳だと自己紹介してどーすんのｗ

だからレベルが違うんだと言っているんだがねｗｗｗ

>>688
さすが>>72も実装できないレベルなだけはありますね

また非生産的なナゾナゾやってんのかよ。良い加減にしろ。

書き込む人によってばらばらの通信のトポロジを想定していらっしゃるらしく、ある人は完全に分散したシステムを想定していたり、私はDHTで疎結合したシステムを想定していたりするので議論がまとまらんのではないですか。

>>690
そりゃ、RequirementやSLAを決めていないから必然的にそうなるよ
それ以前にRFI の段階で能力のない奴がRFP出してくるから駄目出ししてるだけよん

各ノード間で発生した利害関係に対するコンプライアンスをどのように取るのかも考えておかないと
ステークホルダはノードだけじゃなくて
プロバイダ
国民
国
他国
いろいろあるし

例えば自分に必要の無いデータをどう納得して転送してもらえるか、とか
通信パフォーマンスにも、ジッタの有無やQoS、大域幅、効率的な転送、セグメント分け、いろいろ考慮点がある
レイテンシーの許容範囲は？
許容されるHDDの大きさは？
パケットの大きさは固定長？可変長？
最大転送可能バイト数は？


トポロジって言っても1つのシステム内に複数存在する可能性もある
実ネットワークのトポロジ以外にも仮想ネットワークのトポロジがあるだろ
例えばキー探索はメッシュだが、データ転送はツリー、だけれどもIPのネットワークはそれはそれであるみたいな
キー探索とデータ転送を同一トポロジで実現しても構わないけど、何かが犠牲になる

そんなことも考えなきゃならんのに、国境？とかいうレベルの人が偉そうに間違えたこと語るから
落とせるところに落とせないんだよ

461がどういうもの作ってんのか想像できてる人いるの？

>>689
え？なんだって？
http://heartbleed.com/

まあ、それでもBoost やら openSSLやら使っていくんだろうなぁ

>>693
さすが>>72も実装できないレベルなだけはありますね

>>693
荒らし死ね

そういやちょっと前に調べてたけど忘れてたlibjingleを紹介するぜ

とは言っても他人のブログだが
http://www.piax.org/en/?Libjingle

コンパイラの内部エラーじゃない方のICEをつかっている。NAT越えとかもできるらしい。
ICE (Interactive Connectivity Establishment)

元のリポジトリ
https://code.google.com/p/libjingle/

ただ今はソースコードおいてる場所が移動して、プロジェクト名も変わっているという
https://code.google.com/p/webrtc/

へ？
怒ってんの？

俺、なんか悪いことした？
感謝されてんのかと思ってたけど

気づかずに紹介してたが

PIAX（P2P Interactive Agent eXtensions）は、P2P構造化オーバーレイネットワークと
エージェント機構を組み込んだオープンソースのフレームワークです。
http://www.piax.org/

らしい

>>690
特定の方式を想定した会話に対して間違った理解に基づく具体性の無い批判する奴はそれ以前の問題だと思うよ。
それに加えてstaticおじさんとか横文字大好き無能SEみたいな事やってるからもうどうしようもない。
議論まとめるとか無謀だし、異なる前提で物考えてそうだと思ったらそいつは無視して進めた方が良い。
>>695
Heartbleed自体は結構シビアな話題だと思うよ。スレチだけど。

まあ、利用者あっての掲示板だから、
誰も動作の全体像が把握できないようなものを誰が信用するかって問題はあるんだろうね。

よくある安全神話なんかは太鼓判が匿名じゃ胡散臭くて成立しないわけで。

>>699
ふーん
能力が足りないから理解できないだけじゃんｗ
ま、tier2くらい上のレベルで話をしてるから、理解できなくて当然かな
よく知っている人なら分かるキーワードをきちんとちりばめてるからね
3年後に読み返せば、また違った内容に思えるだろ


どちらにせよ
暗号できてるから安全だって勘違いは、そろそろ気づいてくれたのかい？
公開鍵の本質的なことも指摘しないと分からない位だったからね

暗号データを読む方法なんて星の数ほどあるわ
隠れチャネル、逆汗、MITM、メタデータ解析、フック、脆弱性を利用した参照、操作ミス、ポートリダイレクト、トロイ・・・
それを全部ぶっ飛ばして総当りしか思い浮かばない低脳さ加減は悲しくもおもろいｗｗｗ

大切なことは、認証が行われない空間で暗号が安全だって勘違いしてることだろ
むしろ、そっちの方が大切

認証を行う場合、サブジェクトは必ずしもサーバである必要はない
もっと言えばネットワークがサブジェクトにもオブジェクトにもなってよいんだよ
つか、サーバを建てないなら、今のところそれしか選択死が無いと思うよ


ま、言っていることが理解できないんだろうから、反論もできないんだろうけど

>>698
なんつうか、

多分、多対多のP2Pでなく
一対一もしくは一対多のP2Pがメインセグメントだと思うぞ
1000を超える多対1000を超える多では使いにくい

掲示板やファイル交換の要件じゃないものも含まれてる
ジッタ、ディレイ、レスポンスを気にしてるので、用途としては、サーバの無いLINEに近いものだろうな

>>701
で、>>72の間違いは？

> 1)B および中継ノード X, Y .... を「最初にAが決めておく」

最初にAが中継ノードを決めるためには、
XとYであることを知っていなければならないんだけど
匿名性のせいで、XとYかどうかがわからない。

1の時点で矛盾してるよね。

>>703
まだ分からないのかｗ
ヒントは十分過ぎるんだがな

ny の成果をみると，意地でも pureP2P でやりたいですね

＞認証を行う場合、サブジェクトは必ずしもサーバである必要はない
＞もっと言えばネットワークがサブジェクトにもオブジェクトにもなってよい

すまんが｢認証」の定義は？

>>704
それは簡単な話では？
既知のノードに「友達教えて」といって get してくるのは ny でもやってるよね，さいてーげんの初期値は必要だとしても

匿名性の定義は？

> 匿名性の定義は？

接続先のIPアドレスがわからないこと。


> 既知のノードに「友達教えて」といって
nyで返ってくるのは「友達」ではなくて、
誰かわからん人だろう？

匿名なんだから友達かどうかなんてわからんよ。
その中に警察関係者がいるかもしれない

当然だが匿名なので警察かどうかもわからない。

とりあえず単純化してみようか。
オーナー専用の掲示板なら他人の書き込み対応とかは不要で、
RSSの匿名配信手段さえあればP2Pで実現できると思うんだけど、
具体的にはなにが使えるのだろうか？

>>706
ノードで言えば、ネットワークに参加してもよいか、排除されるか( ノード認証 )
データで言えば、ネットワークに流してもよいか、排除すべきか( データ認証 )
公開鍵で言えば、受け入れてよい鍵か、排除すべきか

>>704
結果的にXがKx、YがKy、...の所持者であれば良いだけでしょ。
もし違ってたらリレーの途中で解錠が失敗して内容は闇に消えるし、
中継ノードからは前のノードしか分からないのはそのままだし。

>>709
それは掲示板としてのインターフェイスはローカルで、書き込みのデータをp2pでやりとりするというシステムだよね？

まずこういうことから決定していかないと話が進まないと思うんだが。
何度も書いてガン無視されてるけど、書き込みとログは分けるのか？というのはここに繋がるんだけど。
i2pのfrostとかAmoeba/LairのLairとかはそういうシステムでこれが一般的だと思うんだけど。

>>712
だからその辺独自フォーマットなんて誰かが作らないと決まらないから
とりあえずRSSって話ね。

いやRSSとかよりももっと根本的なことだよ。
実はログをやりとりする部分だけが本質であって、
掲示板として書き込みをどうするかなんてのは勝手に実装してもいい部分

つまり junet/usenet の net news そのまんまでいい、ということだね

ny の k 氏も暗号化に意味はない（だからリアルタイムでデコードできるあのやり方だった）、という見解だったようだが
今もときどき夢想するんだが、せめて DH で最低限のガードをしておれば寿命はもうちょっと伸びだのでは？
ワイヤータッピングくらいには対抗したいもの

>>710
ちょっと質問を変えてみよう
「認証」によって何を防ぎたいのか？「認証」によって「何を」排除するのか？
>>710 はその点については徹底してとぼけているね

>>714
掲示板に書きこみ更新より根本的な機能も無いと思うけどなあ。
何も考えなければ軽いけどスパムで埋まってしまう。
最初に言ってたブロックチェーン式なんかは書き込みの承認が肝だけど、
今回はその辺割愛してまず匿名化を確立しようって話。

>>715
をいをい・・・

要求事項もSLAもまともに揃っていない状況で設計思想に強く関係するところに結論なんて出せるほど俺は超能力者じゃない
ニュートラスステアだよ
右でも左でもない

>>716
＞書き込みの承認
ネットワークが承認すればよいんでないの
ブロックチェーンはどうかと思うけど

＞匿名化を確立
非情なことをいうけど、完全に匿名ってことは、隣接ノードも、やり取りしている内容も分からないってことだよ
だから、個としてのノードは内容を知らないし、隣接ノードも誰だかわからないけど
ネットワークはそれらを知っていれば十分ってことよん

>>716
書き込み部分でいくら工夫しても仮想ネットワーク上でスパムだらけの正統なログを作れる
仮想ネットワークと実ネットワークが繋がっていればスパムだらけのログが流れることになる
それを防ごうとしたら書き込みを検査しログに追加する人は信頼できる人でないといけないから
結局2ちゃんやtor板に書き込むのと変わらない

まあ、戯言だと思ってスルーしてくれ

人間の人体は60兆もの細胞でできてる
個の細胞はすべての状況を見渡せるわけでもないし、
脳細胞でさえ、役割と機能を分担している

すべての細胞を任意にコントロールすることはできないが、
間接的に、ホルモン、酵素、血液、麻薬などで全体として統制の取れたコントロールができるようになっている

ガンによって人体という生命が終わりを告げる時もあれば、
突然変異により変異した細胞を排除する仕組みもある
免疫機能なんかも興味的ですらある

マクロファージをP2Pに実装するのは大変かもしれんけど、
参考になるものは多々あるんじゃないかと

ま、血液に相当するものは造れるからね

ああ、本当に戯言だわｗｗｗ

まず、書き込みの反映に時間がかからないP2P掲示板って作れるの？
それができなきゃ2chの代替は不可能

>>718
何が非情なのかサッパリだけど、結局RSSのうまい配信方法は思いつかないって事でFA？

>>719
匿名の中で信頼というのは結局書き込みからその人間性を見極めるしか無いね。

>>721
んなもん、既に過去レスにフレームワークが出てるだろ
過去レスくらい嫁

>>723
存在しない
だから、P2P掲示板はどこも過疎なんだろ

>>724
ちみは、マーケティングと日本語をもう少し勉強した方がよいよ

>>720
戯言にしてももっとマシな話しろや
脳が腐る

>>726
だったら、スルーすりゃいいのにｗ

分かりやすいところで言えば
ウイルスなんかまさにそうだよね

免疫はまさにパターンマッチング
だから年に1度予防接種といわれるシグネチャーのUpdateを行う
それでも感染しちゃうところなんかそっくり

利他主義、利己主義なんてのもそうだよね
利他主義では種は生き残れるはずが無いと思っていたダーウィン
ところが、ソフトウェアでも生物でも利他主義で種の保存ができちゃうんだよね

利己的遺伝子とか面白れぇぞ

>書き込み部分でいくら工夫しても仮想ネットワーク上でスパムだらけの正統なログを作れる
正統な書き込みであればスパムと呼ばれることはないからその時点でログの正統性はないな。
単にザルをすり抜けただけの未承認ログだろう。

>>728
そのログが未承認かどうかをどの段階で判断するのか、
ということを考えると書き込みで工夫しても無意味だということがわかると思う

>>729
承認完了＝書き込み完了ということを考えると、
書き込み処理を人海戦術でやるのは効果的だな。

>>712
P2PはただのでかいKVSストレージだというふうに考えるのが実装は簡単になるでしょうね。
しかしP2P掲示板が従来のサーバクライアントモデルの掲示板を拡張したものと考えれば、書き込みも含めてP2Pで実現するのが自然かもしれません。

内容の承認に人間が積極的に介入するのは疑問だなあ。

>>701
Tier2事業者がP2P型BBS作る話なんかして何したいんだお前・・・
実装の無い段階で実装や運用に失敗した場合を前提とする話とか何がしたいんだよ
相手に24時間365日ぴったりゼロ距離で監視員貼り付ければ暗号は無意味、見たいな事言って何の意味がある
明日巨大地震で死ぬかもしれないから何しても無駄です言ってるのと同レベルの論法で話にならん
>>708
IPアドレス一つも知らずにIPユニキャスト通信で構築されたネットワークに参加とか不可能だし、
ブロードキャストなどを使ってもIPアドレス偽装しない合法的な手段で通信参加の事実は隠蔽できないだろ。
現実的な範囲の話にして、ネットワークに参加しているという事実以上の事が不明となる、程度にしとかないか？
>>726
分ったフリしてるマーケティングの人間が技術の人間にマシな話できるとでも？

>>731
どうにも判別しづらい画像の写経なんかを強制されるよりはマシだな。
リアルな掲示板なんかはスタンプ押されるし、公共性があると即時公開ではない方が多いだろう。
２ｃｈの巻き添え人力規制と代理かきこなんかを考えてみるならば、むしろセミオートと言えそう。

>>717
要件定義や仕様と実装技術は依存関係・トレードオフにあるから、切り離して扱うのは大人の対応とはいえないね
おお、これは珍しいものをみたね、ウォーターフォールなんてとうに絶滅していたと思っていたよ

>>732
構うだけ増長するタイプの典型的な衒学家だろうが
どうみたって自演までしてんだからとっととNGしとけよ

認証で思い出したけど、猫画像認証ってのがあるらしいね。数枚の画像から猫の画像だけを選ぶってやつ。あれって結構有用な気もするけどかなりの猫画像を用意しないといけないのがなあ。
認証サーバだけサーバクライアントモデルでたてて、そのサーバの電子署名をレスに付けたらある程度の安定性は保てるかも？

>>736
そんなエシュロンみたいな鯖や自分の周囲のイエスマンよりも、レスの相手が下す評価の方が信用できる。
というのがそもそも匿名板の意義じゃないの？

わざわざ畜生画像集めなくたって、アイちゃんの訓練に使ってるコーパスでいいよ。
問題は住人による正統な筈の書き込みがチューリングテストに耐えられる気がむしろしないことだな。

>>734
ｗｗｗｗｗｗｗｗｗｗｗｗ
やべぇｗｗｗ
おもろすぎｗｗｗ

頑張って背伸びしてちょいと難しい単語を検索して散りばめてみました
って感じかｗｗｗ

国境君以来のネタだなｗｗｗ

並べて見るとおもろいので、貼り付けておくｗｗｗ

717 デフォルトの名無しさん[sage] 投稿日：2014/04/10(木) 22:52:42.35 ID:n4KnyZUq [16/21]
>>715
をいをい・・・

要求事項もSLAもまともに揃っていない状況で設計思想に強く関係するところに結論なんて出せるほど俺は超能力者じゃない
ニュートラスステアだよ
右でも左でもない


に対して


734 デフォルトの名無しさん[sage] 投稿日：2014/04/11(金) 07:12:59.39 ID:5I17xPmm
>>717
要件定義や仕様と実装技術は依存関係・トレードオフにあるから、切り離して扱うのは大人の対応とはいえないね
おお、これは珍しいものをみたね、ウォーターフォールなんてとうに絶滅していたと思っていたよ

これも並べておくといいよ
>ほ〜んとうにそもそもだが、 >>72 間違えてるだろ？
>実装してみりゃ、一発で分かるレベルだわ
>それに対して今まで突っ込みが無かったこと
>そんだけレベルが低すぎってことよ

>>740
ヒントも出して、それでぐうの音も出なくなった奴ねｗｗｗ
まだ分からんかねぇｗｗｗ

腹イテェｗｗｗｗｗｗｗｗ
おもろすぎｗ

>>741
本当にその通りでだから教えて欲しいんだよ。
早く>>72の間違いを教えてよ。

>>735
余りにも斜め下だったんでつい・・・すまんね

STAP論文と一緒だろ。
理論の論点とは無関係の致命的なミスプリントは、出版前には誰にも気づかれない。
名付けてゴキ（カ）ブリの法則

>>742
なにをわがままなw
低脳をさらしてるんだから俺はこのままが楽しいんだが
なんでまた、お前を虐めてる俺が、俺の楽しみを無くしてまでお前に便宜を図らにゃならん？

個人的にはアンチ国境君の

http://toro.2ch.net/test/read.cgi/tech/1390486453/597
：Shareの場合、多分RSA+3DESだと思うけど、ふつうに読まれてるからね

http://toro.2ch.net/test/read.cgi/tech/1390486453/602
：602 名前：デフォルトの名無しさん[sage] 投稿日：2014/04/09(水) 18:21:22.42 ID:brM7hELa [12/27]
：お、冷静になろうｗ
：あまりにも馬鹿すぎで涙がでるわ
：
：１．bit長は関係ない
：Shareの事例の場合、4096bitでも普通に読めてたよ。多分1024bitだったんだろうけど
：
：２．デフィーへルマン・・・
：ああ、そう思ってくれ
：Torなら普通に君の送受信データを軒並み読ませてもらうから
：
：で、国境君はどこへ？ｗｗｗ

の方が爆笑ものだったんだが
「share の RSA」と注意深く限定しているつもりなんだろうが．

そういえば只の掛け算と割り算くらい今時のコンピュータなら何も考えなくても一瞬だろう
と思ってやってみたら撃沈したな、正直巨大数舐めてたわ。
まあRSAで必要なのは余りであって、これは馬鹿正直に計算せずに済むうまい方法があった筈だけど、
一発検索出来なかったのでとりあえずSSLの下請けみたいな奴にぶん投げたら一瞬だったのは
いいんだけどなんか悔しい。

>>745
そう言わずにこの低能めに知の恵みを与えてくださいよ。>>72の間違いとやらを。

>>747
あいよ
ja.wikipedia.org/wiki/%E5%86%AA%E4%B9%97#.E5.8A.B9.E7.8E.87.E7.9A.84.E3.81.AA.E6.BC.94.E7.AE.97.E6.B3.95

だから、RSAの場合公開鍵の署名は秘密鍵に較べてめっさ速い
都合の良い素数であればよいわけだからね

>>746
うん、おもしろいねwww
レベルの違いがよくわかる

もう必死に虚勢張ってるだけだろコレ

>>750
反論せずにそんな事言ってると負け犬と思われちゃうよ
ああ、負け犬だったかｗｗｗ

　 　　　 　　 　＿＿＿_
　　　　　　 ／ ＼　　／＼　ｷﾘｯ
.　　　　　／　（ー） 　（ー）＼　　　　「ASN.1はハードウェア標準寄り」
　　　　／　　 ⌒（__人__）⌒ ＼
　　　　|　　 　　　|r┬-|　　　　|
　　　　 ＼　　　　 `ー’´　　 ／
　　　　ノ　　　　　　　　　　 　＼
　 ／´　　　　　　　　　　　　 　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一””””~~｀`’ー?､　　　-一”””’ー-､.
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))
　　　　 　　　 　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ　　　だっておｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒)
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/　
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/
ヽ　　　　/　　　　　`ー’´ 　 　 　ヽ /　　　　／
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　バンバン
　ヽ　　　 -一””””~~｀`’ー?､　　　-一”””’ー-､
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

>>751
そんなことより>>72の間違いを教えてくださいよー。

＞622 返信：デフォルトの名無しさん[sage] 投稿日：2014/04/09(水) 20:32:16.79 ID:0ebJovHs [2/6]
＞
＞> MonkeyInTheMiddle
＞それを言うならman in the middle。おさるさんじゃないよ〜

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>753
お願いしますよ。>>72の間違いを教えてくださいよ。

＞612 返信： ◆QZaw55cn4c [sage] 投稿日：2014/04/09(水) 19:32:36.38 ID:IdW5t/y4 [2/2]
＞>>602
＞＞１．bit長は関係ない
＞＞Shareの事例の場合、4096bitでも普通に読めてたよ。多分1024bitだったんだろうけど
＞RSA-1024(1024ビット数の素因数分解コンテスト） はまだ解けていないんですけど？http://en.wikipedia.org/wiki/RSA_Factoring_Challenge / http://en.wikipedia.org/wiki/RSA_numbers#RSA-1024
＞share の脆弱性は暗号以外のところにあったんじゃないですかね？


で↓煽りｗｗｗ

＞613 名前：デフォルトの名無しさん[sage] 投稿日：2014/04/09(水) 19:32:57.13 ID:ICJhp6O3 [1/2]
＞なんだお前ら俺が働いてる時間帯におもしろレスしやがって
＞よ〜し、じゃあパパHTTPSの暗号を頑張って素因数


結果↓ｗｗｗ

＞685 名前：646@3[sage] 投稿日：2014/04/10(木) 04:54:08.76 ID:IUUfcRRw [1/2]
＞この話題の場合、最後の逃げ道は「現代暗号は総当りで解けなくも無い」っていう極論あたりかな。

>>755
>>72の間違いはまだですか？
お願いしますよ。知りたいんですよ。

>>755
>>72の間違いはまだですか？
お願いしますよ。知りたいんですよ。

具体的に言ってしまったら、論破されるからできるわけない
負け犬と吠えるしかできない負け犬だからなｗ

2つもあるんだから、いい加減1つくらいはそろそろ気付くだろｗｗｗ

>>759
それが分からないから聞いてるんすよ。>>72の間違いって一体何なんすか？

涙目っぷりがおもろいwww

>>761
私の涙目で良ければ好きなだけ笑っていただいて構いませんから、
どうかその叡智を授けてくださいませんか。>>72の間違いとやらを。

低脳が一杯w
こんな恐ろしいレスする奴もいるしねぇw

＞517 名前：デフォルトの名無しさん [sage]： 2014/04/06(日) 06:36:59.07 ID:7fCDh1Rd (3)
＞「ポート開放」って言葉が駄目だな
＞P2Pでは定着しちゃってるみたいだけど、ポート転送って言うべきか
＞ファイアウォールとは関係ない

ポートフォワーディングからポート転送で合ってると思いますが、
むしろポート解放のほうがわかりやすいと思いました。

ポートを（別のIPアドレスやポート番号に）転送するのはポートフォワーディング
転送とは無関係に、外部から特定のポートにアクセスできるようにするのが「ポートを開ける」という。
全く別の機能。

他所でやってよ