14/01/23 23:18:39.60
ゴミ
3:デフォルトの名無しさん
14/01/23 23:22:06.74
乙
4:デフォルトの名無しさん
14/01/24 01:33:38.09
あと前スレで公開されたものもまとめてほしい
それから新月とFreenetとAmoeba/Lairは体験しといて欲しいね。
5:デフォルトの名無しさん
14/01/24 01:38:02.06
>>4
P2P2ch
URLリンク(p2p2ch.web.fc2.com)
ちらしの裏
URLリンク(chiraura0.web.fc2.com)
6:デフォルトの名無しさん
14/01/24 23:10:04.84
P2P2chはJDKってやつが必要なんですか?
動作用件はJREって書いてあるけど
7:デフォルトの名無しさん
14/01/28 18:56:23.69
Bitcloud developers plan to decentralise internet
URLリンク(www.bbc.co.uk)
Bitcloud: A Peer to Peer System for Sharing Bandwidth
URLリンク(github.com)
URLリンク(talk.bitcloudproject.org)
8:461
14/02/06 18:36:49.10
お久しぶりです。都合によりしばらく書き込めませんでした。
前スレに登場したノード間ダイレクトメッセージ、面白そうですね。FreenetのN2NDMですね。
>>6
JDKは開発のために必要なツールですね
JREはJavaのプログラムを走らせるためのツールです。
9:デフォルトの名無しさん
14/02/06 19:40:57.74
効率の良いP2Pは匿名性能が著しく悪くなる。
効率の悪いP2Pは効率が悪いほど匿名性能が上がる。
そんなの明白である。だがマシン性能を使えば匿名度が上がるという
論点のすり替えはよくない。
効率とは応答性能やら無駄な資源の消費度合いのことである。
人を隠すなら人ごみという言葉の通りでどんなトリックを使っても
ほぼ登山者がいないエベレスト登山している1人を隠すのは簡単ではない。
10:デフォルトの名無しさん
14/02/07 01:17:05.59
>>9
まぁ"ネットワーク内"に最低3"者"いれば隠蔽は可能だよ。
"中継ノード経路"が3"者"以上で有ることを保証するのは難しいけど、
その保証がなくても確率的な隠蔽は達成できるから、ギリなんとか。
11:デフォルトの名無しさん
14/02/07 20:23:15.05
中継するノードがプロキシであり、誰に何を転送してるのかが分からなければ三者である必要性も無い
転送先がビンゴであるかもしれないし、そうでないかもしれない
内容も分からない
それで十分
12:デフォルトの名無しさん
14/02/08 13:02:32.55
>>11
でもそれやると転送量が無駄に使われるよね?
ネットワークに負荷を与えているんだけど。
13:デフォルトの名無しさん
14/02/08 20:42:24.57
初心者がP2Pやネットワークの基礎やアルゴリズムを学ぶにはどこいけばいいの?
2chの代わりになるものを作るっていう高い次元の話ではなく、
学んどけば将来就職か何かにいかせるかな?っていう学習目的なんだけど・・・。
14:デフォルトの名無しさん
14/02/08 21:33:20.44
>>11
二人しか居なかったら「俺が送ったんでなければもう一人」って確定しちゃうだろ。
「誰に何を転送してるのかが分からない」って状況になりうるのが「三人目」だよ。
>>12
隠蔽のための転送と共有のための転送の二段階があるとして、
前者はメッセージ長×隠蔽段階数の転送量(ネットワーク全体)であるのに対し、
後者はメッセージ長×(全共有人数-1)の転送量である。
隠蔽は最小で(Torの場合)3段位なんで比較にならないくらい小さい。
問題が有るとしたら遅延の方(前者がO(n)に対し後者がO(log(n)))だが…
やぼったいプロトコル/フレームワークに依存せずエラーがなければ数秒以下で済む…筈。
>>13
学校的な意味にしろコミュニティ的な意味にしろ「どこか」で学ぶってばかりではない。
ネットワークの基礎はともかく、P2Pなんかの発展途上な部分のある技術は特にそう。
既存の実装を知りその解説を探し関連する技術を知りその解説や論文を探せばいい。
15:デフォルトの名無しさん
14/02/08 22:48:06.08
サーバー、クライアント 両用の鳥でおぬぬめは?
16:デフォルトの名無しさん
14/02/08 22:50:08.74
15です。誤爆すまぬ
しかもageてしまた。。。
17:デフォルトの名無しさん
14/02/09 05:59:13.45
>>14
だれに転送するか分からない状態で、どうやって2人しか居ないと確認できる?
頭悪いなぁw
18:デフォルトの名無しさん
14/02/09 06:40:17.25
2人しか居ない状態で「だれに転送するか分からない状態」が作れるとでも本気で思ってんのかお前
19:デフォルトの名無しさん
14/02/09 08:26:56.63
>>18
「だれに転送するか確定しない状態」とでも
20:デフォルトの名無しさん
14/02/09 15:43:22.45
2人しか居なくても、それは短期的の問題のすり替えにすぎない
長期的に2人の外にいる外部者の接続があるのがP2Pであり、その
前提を排除するのは頭が悪い証拠である。
通信する相手が固定で2人だけであるならそれはP2Pの掲示板とはいわない。
21:デフォルトの名無しさん
14/02/09 21:56:55.97
>>17
ありがとうございます。
まだ独自研究に行けるようなレベルじゃないのです・・
とりあえずスレの話題に出てるURLに目を通してみます
22:デフォルトの名無しさん
14/02/09 23:54:26.07
>>20
今居ないノードに中継させて投稿するとか投稿完了まで何日掛かるんスカ?
23:デフォルトの名無しさん
14/02/10 10:48:11.16
間に中継する人がいるとしてさ、
その人が中継しなかったらどうなるの?
書き込みはなくなっちゃうわけ?
それと中継する人は中身を書き換えられないと
思うけどさ、(暗号化しているから)
でも中継する人がやたらめったら、中継しまくったらどうなるの?
一つの書き込み内容を一万個に倍増させるとか。
いや、倍増させなくてもいいか、中継する人が
他人のふりして、自分でどんどん自動送信するとか。
24:デフォルトの名無しさん
14/02/10 10:57:52.14
ちょっと図にしてみた。
書き込み先
↑
中継者
↑
書き込み専用の一万個の仮想マシン
↑
評価専用の一万個の仮想マシン
(書き込み専用のマシンの書き込みが
信頼できると評価する専用のマシン
このマシン自体は書き込みはしない)
25:デフォルトの名無しさん
14/02/10 10:59:12.54
※評価専用のマシンは、書き込み専用のマシンだけではなく
不特定多数、つまり普通の書き込みに対してもランダムに評価する
26:デフォルトの名無しさん
14/02/10 14:25:53.95
>>23
> その人が中継しなかったら
最終到達先は投げられた書き込みをブロードキャストするから、それを監視してリトライすればいい。
書き込みの内容自体にユニークID振っといて、複数経路から書き込みして同一の投稿は無視とかすると失敗率は減る。
> 中継しまくったらどうなるの?
書き込みの内容側に振ったユニークIDで重複・再送を検知すれば何の問題も無く無視される。
トラフィックは増えるからDoS/DDoS攻撃は成立するけどコレはどうしようもない。
>>24
不快な書き込みを評価してるユーザの評価を無視すればなんとかなるんじゃね?
27:デフォルトの名無しさん
14/02/11 00:57:00.65
>>26
FDDIだと一定回数巡回して消化されないパケットは自動破棄だったな
中継しなかったらというより書き込み保証をしないが正解だろう
リトライをしても有限で
28:デフォルトの名無しさん
14/02/11 01:19:46.34
>>26
> 不快な書き込みを評価してるユーザの評価を無視すればなんとかなるんじゃね?
その評価をするのが誰で、その影響力は誰に及ぶの?
たとえば、俺がある書き込みが不快だといって、
その評価情報が分散してしまったら、
もし俺が不快だといった書き込みが、実はいい書き込みだとしても
その評価がみんなに伝わるんだよね?
29:デフォルトの名無しさん
14/02/11 05:13:57.45
>>28
既知の書き込みについて不快な書き込みをNGしてる評価者達が
未知の書き込みについて共通してNGしてるかを検証すれば緩和できるが・・・
そもそも、他人のNG基準に依存するってのはそういうことだし、それに何か問題でも?
30:デフォルトの名無しさん
14/02/11 09:14:36.04
あなたとNGの傾向が似ているユーザはこの書込みもNGしています
31:デフォルトの名無しさん
14/02/11 10:21:50.75
あなた A:NG B:NG C:NG
似ているユーザー A:NG B:NG D:NG
あなたとNGの傾向が似ているユーザーは
DもNGしています。
D涙目www
32:デフォルトの名無しさん
14/02/14 03:10:01.39
実用化急げ
2ch アダルトが認証しないと書き込めなくなった。
これでユーザー離れが起こる。
このとき互換の掲示板があれば人増える。
33: ◆QZaw55cn4c
14/02/15 22:27:57.43
>>32
URLリンク(next2ch.net)
ここ使えないか?
34:デフォルトの名無しさん
14/02/16 18:43:58.23
シェア獲得出来て大人数でも潰れないのが大事。
35:デフォルトの名無しさん
14/02/16 19:12:39.90
bbsぴんくが画像認証付きになったとか何とか
そのくらいで離れやしないだろう
36:デフォルトの名無しさん
14/02/19 18:17:43.77
Pinkと●を運営しつつ2chに鯖を貸してたNTTechのJimが2chの鯖を乗っ取ったとか云々。
●流出騒動の関連から相当胡散臭い(専ブラ作者に行くはずの金を横領したらしいし)人だし、
2ch側の鯖で●止まった後の対応もだいぶ胡散臭かったからこの先がすげぇ不安な感じ。
マジで全部まるごと潰れるかも分からんね。
37:デフォルトの名無しさん
14/02/20 03:01:48.72
PINKはいらねえと思うが収入源になってるなら必要なのかもな
38:デフォルトの名無しさん
14/02/20 07:11:54.17
jimが資金難を理由にクーデターめいたことをやりだしたし儲かるなら潰さないだろうね
39:デフォルトの名無しさん
14/02/20 07:14:56.54
資金難で儲け口が見つからないと潰れるだろ
40:デフォルトの名無しさん
14/02/20 12:03:56.63
1月からなんの進展もないな
まだ開発続けてるの?
41:デフォルトの名無しさん
14/02/20 12:37:08.08
普及目指すなら今しかないだろうね
荒らし対策が心配だけど
42:デフォルトの名無しさん
14/02/20 13:21:08.75
荒らし対策を備えたバージョン2が完成しました!!!
とやるなら互換性を投げ捨てても大丈夫な気がする
だがいずれ薬物売買厨に占拠されてお上に目をつけられるかもしれない
bitcoinとか見てると後からどんどん規制がうるさくなりそう
43:デフォルトの名無しさん
14/02/20 14:06:05.36
やっぱり、あらし対策で詰まってるみたいだな、
キャプチャとかしかないのかね
44:デフォルトの名無しさん
14/02/20 14:24:49.38
あらし対策はどうでもいい。
頻繁にされるほどメジャーになるかが疑問。
45:デフォルトの名無しさん
14/02/20 14:42:55.24
あらし対策が一番重要だろ、それで人が集まり始めてたLairは過疎った
46:デフォルトの名無しさん
14/02/20 14:55:23.53
荒されていないのに、過疎っている掲示板のほうが多い。
荒されてて過疎っている掲示板を見つけるほうが難しい。
47:デフォルトの名無しさん
14/02/20 15:03:48.39
あらし対策ができりゃ、Lairのときみたく俺が宣伝すれば人増える
だがあらし対策出来てないうちは宣伝しないよ、俺は
48:デフォルトの名無しさん
14/02/20 17:09:10.07
いまこそここに移住しようぜ
take2ch.net
49:デフォルトの名無しさん
14/02/20 19:33:45.19
一生宣伝されることはないだろうな
50:デフォルトの名無しさん
14/02/22 11:05:26.48
そもそもそんなもん必要かとか思っちゃう常識人なんですけど……
政府の弾圧がある国あるのか……通信の秘密ってのが常識レベルで守られてないと困るね。
アメリカがどうのとか情報も出てるけど、別に犯罪なんかしないし(笑)
2ちゃんねる避難所リンク集を作りました。原発関係のスレのはちょこっとあります。
2ch避難所リンク集(・∀・)bグッジョブ!!
URLリンク(jbbs.shitaraba.net)
しっかし、避難所立てたら最低限の管理はしよう。自分のところは管理した後荒らしは来てないみたいだけど。
51:デフォルトの名無しさん
14/02/22 11:09:36.51
>>50
運用板でも宣伝してたけど帰って
どうぞ
52:デフォルトの名無しさん
14/02/22 16:55:48.96
>>51
よく分からないけど恵まれてる人かい?
53:デフォルトの名無しさん
14/02/22 22:14:38.55
>>52
多分君よりは
54:デフォルトの名無しさん
14/02/22 23:16:30.89
>>53
そりゃ良かったね。愛情溢れる人であって欲しいってのは高望みかい?
55:デフォルトの名無しさん
14/02/22 23:35:49.23
それは望みではなく、すでに叶ってる。
56:デフォルトの名無しさん
14/02/24 22:35:29.93
Wiki追記しといたよ
57:デフォルトの名無しさん
14/02/27 01:30:47.96
荒らし対策って言うけど、荒らしはどう防ごうが発生するものとして捉えたほうがいいんじゃないかな。
機械判定で防いでも、どの道抜けられるだろうし、各人によっては基準も変わるだろう。
まず全員を受け入れて、その上で荒らしてくる人間を外すしかないと思う。人は外観では分からんよ。
58:デフォルトの名無しさん
14/02/27 03:20:28.56
>>57
ID がつくようにすれば、そして IDの付加はクライアント以外で行うようにすれば
嵐はブラウザ側で弾くしかない‥‥
59:デフォルトの名無しさん
14/02/27 15:13:18.42
それはIDの付与条件を明確にしないと、IDの生成に使う情報がID(よりも強力な個人識別情報)となって匿名から遥か彼方に吹っ飛ぶ可能性が…
60:デフォルトの名無しさん
14/02/27 20:41:18.97
利用者が自分で持つ情報を管理 (自分に必要のない情報を削除したり、必要な情報だけを取得) できることが前提として、
その人が持ってる情報の一部をランダムに要求して、すべて一致していれば同じ人とみなす
61:デフォルトの名無しさん
14/02/27 22:29:32.45
それだと、同一人物判定を避けたい荒らしは、毎回違う答えを返せばいいよね。
62:デフォルトの名無しさん
14/02/28 02:08:08.40
>>59
クライアントがオニオンネットワークに接続する最初の段階で判断、IPアドレスと日付からつくる従来方法でいい
63:デフォルトの名無しさん
14/02/28 02:38:26.50
つまり最初に接続を受けた人が情報バラせば匿名性はなくなる、と
IPと日付だけだと計算式が共有だからIP空間総当りでIP逆算できるからIP強制表示と同等っすね
IP+逆引きだと多少はマシだけどやっぱ逆算できちゃうしなぁ…
64:デフォルトの名無しさん
14/02/28 03:00:37.16
>>63
クローラの存在は考えておかねばならないが、ネットワーク全体がIPばらしクローラだけ、という想定は無理がある
>IPと日付だけだと計算式が共有だからIP空間総当り
過去にさかのぼって日付ごとに総当りを計算とかは現実的とは思えないが
65:デフォルトの名無しさん
14/02/28 04:51:28.88
オニオンルーティングって、誰かが情報を送ってきても、その人が発信者なのか中継者なのかわからないってのがキモなんだよ。
でも中継者が発信者のIDを付与するためには、送ってきた相手が発信者なのか中継者なのかを特定しなきゃいけないよね。
66:デフォルトの名無しさん
14/02/28 05:16:58.38
起動して書き込んだら一定時間は書き込めないとか
連投できないとか、ソフト側で対処できないんだろうか
67:デフォルトの名無しさん
14/02/28 05:24:52.19
自分自身に対して制限する方式だと、荒らしは改造して無効化するよね。
でも他人が発信者に対して制限するには、発信者が誰なのかを特定しなきゃいけないし。
68:デフォルトの名無しさん
14/02/28 06:09:08.04
>>64
一度クローラに引っかかるとその日のうちは別のノードに繋いでも意味なくなるから、遭遇率は存在率よりも高くなる
書き込みに使う転送ルートを固定しないと…
そんで、総当り対象の空間が2^32なんて、全然大した計算量じゃないっていう
一回試した事があったが予想外に早くて驚いた
みっちり最適化やGPGPUすれば数分以下で1日分の全ID特定できるだろうし、IP空間を日本に絞るとかすれば一瞬だろう
ストレッチ掛けても知れてるんじゃないか?
>>65
中継時のID自体微妙だと思うけど、中継時にIDを追記してけばそこは回避できるね
書き込みに付与された複数の中継者IDのうちどれが一つが書き込んだ本人のID、的な
69:デフォルトの名無しさん
14/02/28 06:14:52.64
>>66>>67
P2Pネットワーク内でノードが書き込み・書き込み中継ノードとして認証されるまでの時間を設けるってのは出来るんでない?
有効化時間を計算するのは周囲のノード側だから、他人に対して緩くはできるが自身に対して緩くは出来ない
連投防止の場合、書き込み・書き込み中継に参加したノードは一定時間それらの権利を失う
・・・とかだと中継コスト高過ぎるか
70:461
14/02/28 20:04:12.12
ちょっとした論点のまとめ
・荒らしを抑えるために書き込みを(頻度的に/内容的に)制限しなくてはならない
・自己に制限を掛ける形式だとプログラムを改造して不正利用される恐れがあるため使えない
・そのため外部から制限を掛ける必要があるが、そのためにはノードと書き込み内容の一致がなければならず、匿名性を危うくする
これを解決しないといけないね
71:デフォルトの名無しさん
14/02/28 20:36:48.20
書き込みとログを分けてるみたいだが、荒らしデータはログにも混ぜられるんだよ
72:デフォルトの名無しさん
14/02/28 20:58:05.76
>>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 をつけたいものだ、なにかいい手は?
73:デフォルトの名無しさん
14/02/28 21:38:59.05
IPとIDを紐付けするとそのデータが残るんだから時間を掛けれるので必ず解析される
74:デフォルトの名無しさん
14/02/28 23:22:49.84
いっそ逆に自分で自分にID振って電子署名するって手もアリなんだよね
前スレでの自己署名云々と相互評価・評価者評価って提案はソレに該当する
75:デフォルトの名無しさん
14/02/28 23:25:26.23
>>74
電子署名には認証をつかさどる第三者が必要なのでは?そうなればもうP2Pじゃない
76:デフォルトの名無しさん
14/03/01 00:37:24.72
dhtを実装してるんだったら、ログの保証が大事でしょ。ログの改竄をどう防ぐのか?
77:デフォルトの名無しさん
14/03/01 02:23:36.60
初回起動時にtime()呼んでseed確保
あとは毎日rand()してID生成でいいんじゃないの
メッセージ内にIDも混ぜておくだけで済むし
ID重複する可能性はあるが仕方ない
78:デフォルトの名無しさん
14/03/01 03:01:32.35
悪意のあるハッカーや荒らしの心配よりも。
タイムラグが少なくてレスの同一性とか、
大人数でも耐えられるとか、
幾つか接続が消えてもスレが消えないとか、
掲示板としての最低限度の機能を実現できないと。
79:デフォルトの名無しさん
14/03/01 10:05:34.63
ログは暗号化して3分割
A、B、Cとしたら
復元するためにはそれぞれ3つ以上のパーツを3つ以上集める必要がある
AならAで3つ以上、3つのうち2つ以上同じものを有効とする
BとCも同様に集めて最後に復元
80:デフォルトの名無しさん
14/03/01 12:59:00.41
この方法なら、誰か一人が捕まったら、
他の人はログを復元できないわけで
犠牲者は一人で済むだろう。
81:461
14/03/01 13:40:43.40
P2P2chではログはレスごとに分割される。
ログに電子署名を付加すれば完全性は担保される。ただし署名を信用するかどうかの判断は別に行う必要がある。多数決とかを使うことになるかも。
話が変わるけど、TCP/IPみたく掲示板機能、データの保持、ルーティングなど各層が分離すればIPアドレスを上層から知られる可能性は下げられる。もっとも現在掲示板とデータ保持で分離しているが。
プログラムを改造されるおそれはあるが、各層を各ノードに分離させるという手段もある。
あくまで個人的な願いだけれど、ここでの議論に書き込む時には名前をつけてくれると助かる。酉まで付けることはないけど、論議が錯綜していて流れが全くわからなくなってきた。
82:デフォルトの名無しさん
14/03/01 14:38:21.97
>>75
オレオレ証明書の存在がいい例だけど、電子署名自体には認証機関は不要だよ
電子署名とは、事前に生成した暗号鍵と復号鍵のペアを使い、
署名対象のハッシュを暗号化した値と復号鍵(と付加情報≒証明書)を添付する行為
認証機関は復号鍵と関連付けられた付加情報が正しいことを、
復号鍵と付加情報のセット(証明書)に自分の暗号鍵で署名することで保証する
復号鍵のハッシュをIDとして使う場合、付加情報自体が不要だから認証機関も不要
83:デフォルトの名無しさん
14/03/01 14:56:49.31
つまり、電子署名自体には認証機関は不要ただし改ざんした時に注意が必要になる。
改ざんすれば、署名も変わるから改ざんしたことがわかる。
オレオレ証明書の場合は、その署名は俺のもの。として俺は知っているから信用できるし、
その署名が違えば俺のものじゃないとわかる。でもこれは「俺」しか登場人物がでてこないからできること。
さてP2Pにこれを適用するとどうなるか。ファイルに署名が付いている。それ知らない人のもの。
そのファイルが改ざんされれ署名が変わる。それも知らない人のもの。
つまり、ファイルAに「匿名希望Aさん」の署名があります。信用しますか?
ファイルBに「匿名希望Bさん」の署名があります。信用しますか?
匿名希望Aさんって誰ですか? → 匿名だからわかりません。
ファイルは、AさんとBさんのどちらが作ったのですか? → わかりません。
ファイルAとファイルB、改ざんされたのはどちらですか? → わかりません。
という状態になる。そもそも匿名なのだから、署名の信用もなにもあったもんじゃない。
もちろん、一人がファイルも署名も複数で大量に作り放題だから、投票とか評価であれば、
一人が多人数になりすまして行うことは可能。
結局の所、他人がある人になりすますことは出来ないが、ある人が別人になりすますことは可能。
このことから、完全な匿名P2Pによる投票・評価システムは、たとえ電子署名があったとしても成り立たない。
84:デフォルトの名無しさん
14/03/01 14:59:27.14
分かりやすく言えば、YouTubeで韓国が動画に票を入れて不正にランキングあげてるでしょ?
匿名P2Pというのは、あれが韓国のしわざであることすらもわからないということ。
完全匿名P2Pだと、大量に票が入っているが誰か全く分からないという状態になる。
85:デフォルトの名無しさん
14/03/01 15:02:58.81
ちらしの裏
ちらしの裏は完全分散型のポエム連作支援ソフトです。
ポート開け必須の P2P ソフトであり、2ちゃんねるブラウザを介してポエムの読み書きを行います。
URLリンク(chiraura0.web.fc2.com)
新月 - P2P匿名掲示板
URLリンク(bbs.shingetsu.info)
blogban(ω)
おとなもこどももおねーさんも
みんなで作ろう巨大掲示板
今後、ステマや薬物取引のないキレイな巨大掲示板群になり得る『blogban』へようこそ!
URLリンク(blogban.net)
alias - Alliance Network - Google Project Hosting
URLリンク(code.google.com)
86:デフォルトの名無しさん
14/03/01 22:30:20.66
Bitcoinじゃないけど、Monacoinってのがあるじゃない。それをIDの代用にできないかなあ。
有用な書き込みにはいくらか心付けをあげられる、みたいな。
87:デフォルトの名無しさん
14/03/02 00:27:55.73
有用な書き込みにはいくらか心付けをあげる人が
自作自演だったりするわけだからね。
88:646@3
14/03/02 02:04:55.34
>>83
なりすましというか自演だな、防げないのは
自演可能な仕様だと単純投票は不可能だけど、同一署名での評価傾向は偽造してもそれが内容になるからそれ使えばいい
↓今考えてる「ぼくのかんがえたとくめいのあらしえぬじーきょうゆうしすてむ」
評価署名と投稿署名を用意して、どちらも定期的に(評価用はより長くてもよいし、複数持ってよい)作り直す事で同定を避ける
評価傾向の一致で評価者や自己評価が同定できないように評価結果のいくらかはマスクする
評価署名は表示後NGした/しなかったという評価情報を公開して、評価傾向が自分とそぐわない評価署名からのは無視する
評価署名を発見してからの経過時間も評価署名の有効性の判定に使ったりすると攻撃がより面倒になる
後ろめたいことがないやつは署名を長めに使うことで署名交換後のブランク発生を抑えられる
新しい投稿署名での投稿は誰かが表示しないと評価が付かないからしばらく無視されるが
投稿者自身の評価署名がランダム時間後に評価するし、スパムメールフォルダを覗く感覚で読んだ奴も評価する
それと古い投稿署名は単純に破棄せず後継者(自分含むランダムな数人)を指名して信用を委譲して評価値を少し稼ぐ
89:646@3
14/03/02 02:05:28.24
UI的には、評価情報の更新で随時変化する評価値が閾値を超えれば表示するようにして、
(スラッシュドットのスコアシステムみたいな)一時的に閾値を下げる操作も用意しておく
レスの表示順は、表示条件を満たした順を選べるようにしとくべきかな
「表示後NGしなかった」を明確にするために出来れば専ブラ上では非NG操作とか表示時間や表示位置を計測する
この場合、平均的な住民の評価値の閾値を確実に超える量のダミー評価署名を1投稿ごとに使い潰さないと荒らし投稿が出来ない
荒らし投稿をしても実質NGが共有されるから然程経たずにその投稿はNGされて消え去るから、
荒らし投稿の表示状態を継続するには同等の(同一でない)投稿を延々と繰り返せるだけの大量のダミー評価署名が要る
そこまでいくと荒らす側も大変になってくるし、なによりここで使い潰すのは評価署名であって投稿署名ではない
評価署名であれば匿名性は然程重視されないだろうから、
IPなりメールアドレスに対して一定数以下の投稿署名だけ認証する簡易認証局(単なるWebサイト)とか設置して、
気合の入った荒らし対策が必要なスレの住民は住民が維持する簡易認証局の証明書を使って評価署名の有効性を判断する
簡易認証局は同一IPアドレスから一定期間内に一定数以下の認証しか発行できない程度の制限で十分(ダミーは相当数が要る)
90:デフォルトの名無しさん
14/03/02 05:04:05.74
>>89
でもそれ、人間がやる場合でしょ?
自演は、自動化して、署名をたくさん作るので
何千人、何万人が評価するんだよ。
しかも一回限りの評価だから
その人が他になにを評価しているかなんてわからない。
ということで、評価が一回のものを省こうとしたら
今度は、他の誰かをランダムに選んで評価することで
評価の回数を増やすことも出来る。
91:646@3
14/03/02 05:40:53.68
>>90
その手の荒らしが出現した時は簡易認証局を使えばいい
ロガー付き認証局に引っかかっても所詮は評価署名だし無害
普通は荒らし投稿1つに付き複数の評価署名が必要だけど、荒らし投稿自体寿命が短い
意味の有る広告や荒らしをするには大量のIPアドレスが必要だがIPアドレスは有限だ
同一IPアドレスからの認証要求を一定期間無視する簡易認証局を使うだけで効果がある、筈
92:デフォルトの名無しさん
14/03/02 06:38:38.82
荒らし対策、個人認証システムよりも、それなくとも2chほどに人集められる方がいい。
2chもあらしの時代を経てバージョンアップしてきたろ。
93:461
14/03/02 08:13:43.23
>>92
気持ちはよく分かるけれど、仕様を2chと同じにしたとして考えて管理能力や安定性、速度、安全性が低いP2Pに人が来るのだろうか……
P2Pのデメリットを出来るだけ潰してメリットを最大に伸ばせる仕様設計をするべきと思うなあ。
94:デフォルトの名無しさん
14/03/02 16:38:42.55
匿名性よりも荒らしよりも、1週間前、1ヶ月前、一年前とかの
未取得データをちゃんとP2P上に残せるのか?
あるPCが接続やめたら、取り出せなくなったら使えない。
95:デフォルトの名無しさん
14/03/02 17:42:53.92
>>94
え? 今までの流れって
誰か一人のPCがスレ管理人になるって話でしょ?
書き込みを残すも残さないも、その人次第。
96:デフォルトの名無しさん
14/03/02 20:06:16.17
1から作ろうと思ってるんだけど一緒にやりたい人いない?
97:デフォルトの名無しさん
14/03/02 20:28:46.20
アーッ!
98:461
14/03/02 23:53:09.75
>>94
私が開発してるやつだと分散して保存される。予備も保存する(ここは予定)。ネットワークから抜けるときもデータの引き継ぎがあるはず。
>>95
あくまでここではつらつら議論するだけで、各実装は酔狂な開発者が好き勝手するスタイルかと。
>>96
何度もその流れになり、結局各人が好きに実装するふうになった。
私も書いてはいるものの、だれかWiki書いてくれよー
スレの流れがわからんちんになるんじゃー
99:デフォルトの名無しさん
14/03/03 16:35:04.26
ふたたび2chが止まってるが。
すぐにでも実用化して人集めたほうがいいな。
特別なソフトウェア、ポート開放なしでURL打ち込むだけでつかえるのがいい。
100: ◆QZaw55cn4c
14/03/04 12:42:52.51
>>72
>2)B, X, Y の公開鍵Kb, Kx, Ky A が自力で入手
のときに、公開鍵を渡す側で、接続してきたIP を記録しておく(この場合は Kb と一所に接続先を記録する)。
B での復号時はあちらこちらにばら撒いた公開キーを覚えておいての総当りになるが‥‥
まあ期限をきめればいいか。
後は IP4 空間 2^32 の狭さだねえ、IP6 にしますかね
101:デフォルトの名無しさん
14/03/04 13:25:25.36
freenetを土台にしたらいい。
使ったことないが匿名なんだろ。
102:デフォルトの名無しさん
14/03/04 15:32:43.67
匿名性はいらんからサーバー不要でダウンしない掲示板がいいな
103:デフォルトの名無しさん
14/03/04 15:36:56.47
それは自分も思ったが。
少し考えると、ヤバイ、レスを保有・配信しているPCの所有者が逮捕される危険。
ヤバイ、レスを放置しても逮捕されない仕組みがいるだろう。
104:デフォルトの名無しさん
14/03/04 15:38:54.92
投稿者の匿名性は別にいらないが。
配信者の匿名性はかなり欲しい所。
どういった仕組みで実現できるのかは知らないが。
レスポンスが異常に遅くなるのはダメだろう。
105:デフォルトの名無しさん
14/03/04 20:17:00.44
ビットコインの匿名性と掲示板のの匿名性を比較論議する奴が出てこない時点でこのスレ用済み。
研究系の連中なら論文のタネになるような話だからこんなとこで話さない。
そもそもお前らの欲しい「匿名性」ってどんなものなんだよ?
いつまでたってもそういう基本的なところでgdgdやってっから何もできないんだよ。
106:デフォルトの名無しさん
14/03/04 20:42:46.56
ビットコインは特殊事例だから当てはまらない。
ビットコインのコアというのは用は
一つのデータを複製できないことにある。
コインという簡単に複製できてはいけないものが合って
それを守るためにアルゴリズムが作られている。
匿名性はおまけ。あってもなくてもいいもの。
完全匿名掲示板に求められるものが、いくらでも情報を作れる+匿名性であるならば
ビットコインの事例は全く当てはまらない。
107:デフォルトの名無しさん
14/03/04 21:37:35.82
>>105
こういう低脳、どうにかして欲しい。
結局煽ってビットコインの知識を得たいんだろうけどw
108:461
14/03/04 23:49:17.68
まあまあ。
ある論文で読んだんだけど、IPv4(v6でも可)アドレスをハッシュ関数にかけたものと公開鍵をハッシュ関数にかけたものの論理和、つまり
H(IP) || H(PublicKey)を使えばなりすましも防げて確認も容易、みたいな話を見た。
IDからは直接はIPアドレスを知ることができない。
109:461
14/03/04 23:52:18.70
連スマソ。
とりあえずその元になるスライド。
URLリンク(www.ietf.org)
110:デフォルトの名無しさん
14/03/05 00:09:53.25
もしわかるならば(論文に載っているならば)
確認方法のロジックと論理和のサンプルを示してくれないか?
要望を書き連ねるよりよほど有意義だ
111:デフォルトの名無しさん
14/03/05 01:11:10.34
>>100
vをつけろよデコ助野郎
112:461
14/03/05 01:40:39.79
論文にないからちょっと書いてみる
本当は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の正当性を検証する。
113:デフォルトの名無しさん
14/03/05 03:33:40.79
Q.ビットコインへの各国の対応が異なるが、ビットコイン利用におけるメリットや付随するリスクは正しく認識されているのか。
A.ビットコインは従来の金融/決済サービスに比べて、安価で迅速に資金取引が完了できるメリットがあります。
一方でリスクとして一般的に言われるのは、ビットコインの匿名性です。
匿名でアカウントを開設し取引できるため、マネーロンダリング等に不正利用されることもあります。
しかし、実際には取引そのものは一般に公開されているため追跡できますし、匿名で開設したアカウントでも、最終的にIPアドレスを調べれば利用者の特定は可能です。
URLリンク(e-public.nttdata.co.jp)
ビットコイン匿名ですか?
ビットコインは、暗号化メカニズムを経由して、ある程度の匿名です。 しかし、取引はこのように匿名性が大きく、あなたの本当の場所(IPアドレス)を隠すどれだけの尺度である、IPレベルで見ることができます。
あなたはBitcoin取引については、インターネットサービスプロバイダ(ISP)によってあなたに与えられたアドレスを使用している場合、十分な欲求、技術に精通し、かつリソースを持つ誰もが、おそらくあなたをトレースすることができます。
あなたはTorのか、他のサービス経由でIPを難読化した場合、あなたの匿名性が大幅に向上します。 ただし、仮想Bitcoin交換によって駆動現実世界の物理的な取引はまだあなたがオンラインに維持どんな匿名損なわれる可能性があります。
URLリンク(www.099978.com)
Bitcoin中核開発チームのメンバーのJeff Garzik氏からメールあり。氏曰く、BitcoinはSilk Road生息者が思うほど匿名でもないらしい。
なんでもBitcoinの決済はすべてパブリックログに記録が残るので、関わる人の身元は匿名になるものの、捜査当局が高度ネットワーク分析技術を駆使すれば決済フローを解析し、個々人のBitcoinユーザーを絞り込むことも可能なのだとか。
「大型の違法決済をBitcoinでやろうと思っても、捜査当局が現場で実装している既存の統計解析技術にかかったらひとたまりもありませんよ。かなり無謀な試みでしょう」(Garzik氏)
URLリンク(www.gizmodo.jp)
114:デフォルトの名無しさん
14/03/05 03:40:22.87
オニオンルーティングの実装を考えたり、新しい匿名化技術を考案するスレじゃないと思うんだけど。
115:646@3
14/03/05 06:12:59.79
>>108>>109>>112
そのページはノードID偽装対策・検証の話らしいからIPの隠蔽は特に重視されてるわけじゃなさげ
CGA variantってのがよく分らんけど、多分、暗号学で||演算子は論理和じゃなくて連結ぽい
参考:URLリンク(ja.wikipedia.org)
論理和で撹乱しても良いけど、>>62に似てるから問題点も似てくると思う
・公開鍵が判っている場合、論理和だとするとH(Ipv4)のうちH(PubKey)が0になってる桁が公開される
・計算を行ったノードにはID-IPの対応がバレる
・>>65の問題に対応する為に例えば>>68的アプローチを取ると、単一の投稿に複数のIDが付く
116:デフォルトの名無しさん
14/03/05 06:34:15.36
オニオンルーティングを調べたが。これは通信経路を隠すやつだな。
中継してる間にレスポンス落ちそう。
暗号化でなく、細分化でいいんじゃないか?
犯罪予告のようなデータを保有しているPCが警察に狙われる可能性が出てくるが。
犯罪予告の一文を10台、100台で分担して保有してれば、警察もそういう仕組みなんだと納得してターゲットにしないだろ。
HDDの多重化のRAIDみたいにできないか。
117:デフォルトの名無しさん
14/03/05 06:41:55.81
>>116
「オニオンルーティング系統の方法で匿名化してDHTで分散する」
ってのが今の所このスレで提案されてる方法の基本だと思うが、
DHTの場合データを保持するノードが離脱する事は前提なんで、
普通は複数のノードが同一のデータを保持するよ
118:デフォルトの名無しさん
14/03/05 06:50:56.00
犯罪予告の一文が、一台のPCからは取り出すことが不可能なように分割されていれば、暗号化は不要だろ?
たとえば、10台のPCに記録するなら、10バイト飛ばしのデータずつ保管していれば、だれかが違法配信者として逮捕されることはない。
10人だと共犯にされてしまうかもしれないが。
1000人とかくらいだったら、共犯でなくそういうデータ保存方法だと納得してくれて安心かと。
RAID 5
RAID 5は、耐障害性の向上と高速化、大容量化のすべてを実現できるRAID技術である。分散データ・ガーディングとも呼ばれる。
RAID 5では、ディスクの故障時に記録データを修復するために「パリティ」と呼ばれる冗長コードを、全ディスクに分散して保存するのが特徴だ。
URLリンク(image.itmedia.co.jp)
RAID 6
RAID 6は、RAID 5の改良版といえる技術で、1つのデータ・ブロックにつき2つのパリティを生成する。
これにより、同時に2台のハードディスクが故障しても、元のデータを修復可能としている。この耐障害性の高さがRAID 6のメリットである。
URLリンク(www.atmarkit.co.jp)
119:646@3
14/03/05 07:12:02.13
>>118
犯罪予告は投稿が罪なだけで配信は罪じゃないと思う
配信がアウトなのは個人情報とか無修正エロ動画とかだろ
あとその目的の場合、多重化じゃなくて分散化がキモなような…
つか未成熟なDHTじゃないんだしRAIDの説明は要らんだろ
有名だから大概の人は知ってるし、知らん人はググりゃいい
それはそれとして、スレ単位投稿単位より細かい粒度で分散ってのはアリかもな
算術符号的な方法で1ビット以下までバラして保持できたら情報工学的に面白そうだ
120:デフォルトの名無しさん
14/03/05 07:17:37.30
2chまとめサイトで、GIFで時間経つと犯罪予告が現れるのを
そのまま乗せて逮捕されたか事情聴取されたのが最近なかったか?
個人情報でも一つのPCから配信してたらヤバイだろ。
121:デフォルトの名無しさん
14/03/05 08:19:08.27
まだIPにこだわってんのか
NATにぶらさがってて同一IPになってるのも多いのに
122:デフォルトの名無しさん
14/03/05 11:20:19.85
学生が知識自慢したいだけに見える。現実感が全く無いな
今時、固定IPなんて殆どいないというのに
123:デフォルトの名無しさん
14/03/05 11:29:58.12
>>121
脳足りんサンw
124:デフォルトの名無しさん
14/03/05 11:34:13.31
Bitcoinが目指してるのは別に匿名機能じゃないからなぁ。
アルゴリズムで通貨の価値を担保するってことが目的だし。
他の何かを参考にしろ。という意見がどれだけ意味が無いか
まったく目的が違うものは参考にできんよ。
125:デフォルトの名無しさん
14/03/05 11:43:06.95
>>118
> 犯罪予告の一文が、一台のPCからは取り出すことが不可能なように分割されていれば、暗号化は不要だろ?
いや、そもそも、その暗号化されてれば万能です。
あらゆる災害から身を守れます。みたいに思ってるのなんなの?(笑)
みんなさ、暗号を万能薬みたいに思ってるでしょ?どう使うかが重要なんだが。
喩え話をするとね。わかりやすいから学校のクラスの話と思ってくれ。
俺と誰かが内緒話をする。その話は周りに誰も居ない所で耳元で
小さな声で話す(つまり暗号化) だから誰にも盗聴されない。
さてこれがほんとうに安全か?
俺は誰とでも構わずこの内緒話をする。相手が匿名だから誰々には内緒とか
制限不可能だからね。さてクラス全員と内緒話をした。暗号化して通信を行った。
さて俺の内緒話=犯行予告は、暗号化によってなにが守られたというのだ?
126:461
14/03/05 16:03:03.55
>>125
DHTだとその内緒話は同じアドレスに送られるわけよ
127:デフォルトの名無しさん
14/03/05 18:21:51.15
同じアドレスに送られるから安全になるのであって
暗号化は関係ないって話だろう?
128:デフォルトの名無しさん
14/03/05 20:47:00.87
P2P完全匿名掲示板は
まとめサイトを作るのに適していますか?
129:461
14/03/05 21:28:58.10
書き込みをクリエイティブコモンズの営利禁止にすれば安心なんじゃなかろうか
130:デフォルトの名無しさん
14/03/05 23:27:27.62
>>128
それはライセンスの問題だから、P2P完全匿名掲示板であることは特に関係がない
>>129
ライセンス無視する奴は無視するから転載禁止にしたところで実効性が微妙、て意味では安心のしようがない
131:デフォルトの名無しさん
14/03/05 23:32:20.04
>>129
各ユーザが自分の書き込みのライセンスを自由に選択出来る仕様にしたらいいんじゃね?
132:デフォルトの名無しさん
14/03/05 23:38:17.32
>>112
今更だが乙です
133:デフォルトの名無しさん
14/03/06 01:51:21.27
>>132
乙だけど誤解っぽい(>>115)からな、それ
134:デフォルトの名無しさん
14/03/06 05:42:41.80
簡単には、
ビットコインは、 データの暗号化
TORは、経路の暗号化
だろ?
データも経路も丸出しで、データの多重化・キャッシュ目的で分散させれば十分だろ。
文書が連続するようにデータ保持しなければ。
135:デフォルトの名無しさん
14/03/06 06:26:20.27
これはどうだ?
グーグル・クラウドサービス、グーグル・ドライブなどがあるが。
P2P上に、一台の仮想スパコンがあるかのように、見せかけるソフトウェア。
その仮想スパコンへのやり取りで、掲示板やWebサーバー機能を実現する。
P2Pだから、全員撤退しない限り、仮想スパコンは消失しない。
136:デフォルトの名無しさん
14/03/06 06:36:48.41
すでにあった
グリッド・コンピューティング - Wikipedia
グリッド・コンピューティングは、インターネットなどの広域のネットワーク上にある計算資源(CPUなどの計算能力や、ハードディスクなどの情報格納領域)を結びつけ、
ひとつの複合したコンピュータシステムとしてサービスを提供する仕組みである。
提供されるサービスは主に計算処理とデータの保存・利用に大別される。
一箇所の計算センターや、一組のスーパーコンピュータでは足りないほどの大規模な計算処理や大量のデータを保存・利用するための手段として開発されている。
137:デフォルトの名無しさん
14/03/06 10:04:30.49
情弱キモ
138:461
14/03/06 10:11:35.25
ども。
現在鋭意開発中のP2P2chのコア部分がかなり完成してきたので、とりあえず報告までに。近いうちにアップロードします。
とは言っても暗号化とはまだ無縁ですが、これから改良できると思います。
そういえばノード間のダイレクトメッセージを求める声がありましたよね。
簡単に実装できると思うのですが、ちょっとここで思い付いたのですが、切手みたいにダイレクトメッセージを「有料」にしてみたら面白いと思います。
データ転送を請け負うノードが、転送に伴う負荷の代償としてこれを受け取る、といった感じです。
ただbitcoinでは速度が遅すぎますね。
139:デフォルトの名無しさん
14/03/06 10:15:27.76
ツイッターが中央サーバー方式であるのが納得できん。
これこそP2Pでいいはずだ。
140:デフォルトの名無しさん
14/03/06 18:53:10.40
>>139
ブログのrssを拾えばいいだけのこと
141:461
14/03/08 01:17:44.38
そういえばですけど、P2P掲示板でもスレあたりのレスは1000までにするべきだと思いますか?
技術的には1000を超えたり無制限にすることは可能ですが、制限することでなにかメリットはあるでしょうか?
142:デフォルトの名無しさん
14/03/08 01:34:57.79
>>141
パートスレとかではじめて来た人がなるべく新しい >>1 (テンプレとか) を見れる とかかな
143:デフォルトの名無しさん
14/03/08 02:36:56.54
>>141
無制限だとアンカーの桁数増えるし、テンプレの確認も面倒になるし、古い話題が延々見えてるってのも鬱陶しい
1000超えたら時間経過毎にレスしづらくする(不可能である必要もない)程度だと自分は嬉しいけど、一般的にはどうなんだろう
144:デフォルトの名無しさん
14/03/08 03:47:32.39
天ぷらの更新とかもあるから1000区切りが使いやすいんじゃないの
145:461
14/03/08 03:56:11.77
>>142,143
無制限だとスレの新陳代謝によくなさそうですね。
じゃあ1000区切りというかんじで進めることにします。ご意見ありがとうございました。
146:デフォルトの名無しさん
14/03/08 05:12:32.86
続スレ立ての時、通し番号間違いとか防止できるようになんない?
147:デフォルトの名無しさん
14/03/08 15:09:35.89
>>146
そこは専ブラの仕事じゃないかな?
できないことは無いだろうけど掲示板に付ける機能とは思えないなあ
148: ◆QZaw55cn4c
14/03/09 13:41:03.84
>>138
24時間立ててくれるモチがほしいです、電気代とかもかかるしね
ny の機能はつきませんか?
149:デフォルトの名無しさん
14/03/09 21:36:52.40
書き込みが改変される可能性も少ない確率である、ってくらいでも
匿名掲示板は成り立つのでは?
その匿名掲示板で固定ハンドルとして活動する場合はいろいろ問題もあるだろうが
匿名なら改変されても被害は少ないだろう
150:デフォルトの名無しさん
14/03/09 21:38:14.66
もっと極端な方向性として
改変が簡単に行われてしまう匿名掲示板というのでも構わないんじゃないかと
151:デフォルトの名無しさん
14/03/10 00:28:24.42
既存のp2p匿名掲示板でどういうことが起こったか知らないからそんなことが言えるんだよね
152:デフォルトの名無しさん
14/03/10 02:23:22.79
>>149 >>151
書き込み改変=中間者攻撃、を防止するには
①送信者の公開鍵を確認できる=送信者特定可能
とするしかないので、匿名を追求する限り無理なのでは?
IDは >>100 でなんとかなりそうだけれども
153:デフォルトの名無しさん
14/03/10 02:25:35.97
ちなみにどういうことがあったかというと、freenet, lair, 新月 どれもスパムだらけの壊滅的な状態になったことがある
154:デフォルトの名無しさん
14/03/10 02:33:01.05
>>152
freenet, lair, perfect dark など匿名性が高いネットワークでは匿名ネット内での個人を特定できるようにしているね
新月は匿名性が前者と比べると無いようなものなのでスパム元のIPを特定できるし本気で荒らす人がいない
155:デフォルトの名無しさん
14/03/10 02:37:53.82
>>154
>匿名ネット内での個人を特定できるようにしているね
それは公開鍵の改変をチェックできる仕組みかな?
156:デフォルトの名無しさん
14/03/10 06:54:33.59
匿名性の意味がごっちゃになってるが、
海外のやつはたいていIDまではわかるんだよ。
ユーザーに対して一つ(もしくは複数)のIDが割り当てられ
書き込みに対して、どのIDが書き込んだかがわかる。
IDから個人を特定する方法を用意していないっていうのが
匿名という意味の本質。
IDまではわかるんで、もし仮にこのIDは俺のですと発表すれば
当然、ある書き込みが俺の書き込みかどうか調べることが出来る。
IDもなにもかもわからないようにしようとするからダメで
逆に言えばIDが分かることを認めてしまえば、中間者攻撃を
防止しながら匿名性を保てる。
もっとも俺は複数のIDを持てるわけで、
AというID = 俺 と判明しても
BというID = 俺? かどうかはわからないんだけどね。
つまりAとBというIDを使い分けて、自作自演は可能ということ。
157:デフォルトの名無しさん
14/03/10 12:45:51.33
>>152
署名すりゃいいじゃん。簡単なことを・・・
158:デフォルトの名無しさん
14/03/10 13:19:51.03
分散保管して多数決チックに決めてしまえばRAIDライクに解決する
159:デフォルトの名無しさん
14/03/10 13:50:07.55
ほう、自作自演すれば勝ちとな?
160:デフォルトの名無しさん
14/03/10 19:02:33.45
>>157
すまんがその署名が正しいかどうかはどうやって判断する?結構悩ましいと思うけれども
161:デフォルトの名無しさん
14/03/10 19:05:54.12
>>100 で A が B の公開鍵を get する段階で、同時に B に自分(A)の公開鍵を送り、それを ID にする。
だめか?
162:デフォルトの名無しさん
14/03/10 19:14:53.09
電子署名を使えば、署名と書き込みは対応させられる
公開鍵の改変をチェックとか正しい署名とかは特定の個人やIPと対応させたいということなのかな
それは当然、匿名性を失なうことになる
163:デフォルトの名無しさん
14/03/10 19:20:38.20
結局転送途中で内容が変わることは防げないのか‥‥
改変ものが増殖するのは仕方がないとして、オリジナルが消えない工夫はどうすればいい?
164:デフォルトの名無しさん
14/03/10 20:06:34.67
>>160
それが、レベル低いっちゅうてんねん
165:デフォルトの名無しさん
14/03/10 20:08:27.35
>>164
>>160=>>163
166:デフォルトの名無しさん
14/03/10 20:08:59.83
>>165
防げるよ。低脳
167:デフォルトの名無しさん
14/03/10 21:33:07.77
>>163
できるだけ広く拡散して、多くのノードで保持するしかないんじゃないかな。
掲示板のレスなんて容量小さいんだから、全ノードが全レス保持するくらいの勢いで。
168:646@3
14/03/11 03:25:15.56
>>149
自分自身の同一性を証明するのは簡単だよ、極端なことを言えば本文に手でPGPかなんかの署名するだけ
>>152
いくつか誤解がある
書き込みの改変は、投稿後の改変と投稿時の改変の2つがある
投稿後の改変は追記型のネットワークDBにしておけば、データ保持者全員が結託して改変・消去しない限り問題ないし、
そのうえで投稿単位のデータについて名を値のハッシュにしておけば、名の一覧以外は結託しても消去しか出来ない状態にできる
別の署名をしたコピペを逐一ポストされると区別が難しくなるけど、署名を先行して送信するとかで回避できんこともない
投稿時の改変については受信者の公開鍵を正しく入手さえ出来れば、投稿時の改変はできなくなる
中間者は投稿文を読めないので破壊や消去しかできないから、単なる不達が起きるだけで済む
送信者としての公開鍵は自分から同一性を証明するために必要なだけだから、破棄したければ破棄すればいい
あと>>100のやり方だと実質IPが全部筒抜けだからあんま意味ねぇんだよな…
>>163
単純送信なら送信先の公開鍵で暗号化して送れば変造不能
情報取得なら、自分の使い捨て公開鍵と要求情報を最終相手先の公開鍵で暗号化して送れば変造不能
不達や消滅は起こりえるけど、変造それ自体は防げるよ
169:デフォルトの名無しさん
14/03/11 04:23:19.00
>>168
ネットワークDB ですか‥‥当方には新しい概念だから少し調べてみる
後半
>単純送信なら送信先の公開鍵で暗号化して送れば変造不能
その送信先が改変意図を持っていたら‥‥
前提として多数のノード間での単純なバケツリレー(あるいは投稿単位交換)を想定していた
投稿者の最初の送信先が悪意をもったクローラで、そこで改変して次のバケツに渡すとき、次のバケツでは改変を検出できないものかと
投稿者が秘密鍵で投稿単位(かそのハッシュ)を暗号化、それと一所にオリジナルのID=公開鍵を渡すのであれば、バケツリレーの先でもチェックは可能かな
公開鍵すら変えると成りすましが成立しなくなるから。
>>100 は送信経路の撹乱と接続先でのIDの付与が目的だから、目的の送信先にIPが筒抜けてるのもやむを得ない。
目的の送信先が悪意を持ち、IPとID=公開鍵の紐付けを謀ったり出来る可能性が生まれるのは認める。それを他のバケツに記入改変して転送、とはいかないだろうが
となると、改変された投稿単位をどうするか、だが、悪意を含む可能性のある投稿単位消すか‥‥オリジナルは失われるな‥‥
170:デフォルトの名無しさん
14/03/11 04:50:40.87
なんか公開鍵暗号と電子署名の公開鍵がごっちゃになりそうな気がするんで一般的な暗号の概要
■暗号学的ハッシュ関数
元の文章からハッシュ値を求める関数
与えられたハッシュ値から元の文章の特定が困難
与えられたハッシュ値と同一のハッシュ値を持つ別の文章の作成が困難
同一のハッシュ値を持つ複数の文章の作成も困難(現在、MD5はこれを満たせない)
■共通鍵暗号
暗号化と平文化に使う鍵が同一、処理が早い
■公開鍵暗号または電子署名
暗号化と平文化に使う鍵が同一ではなく、暗号化鍵と平文化鍵のペアを使う
通常は処理が遅いので、ハッシュ値や使い捨ての共通鍵暗号の暗号鍵を対象文の代わりに使用することで高速化するが以下略
■公開鍵暗号
暗号化鍵から平文化鍵が求められない場合は、公開鍵暗号として使用できる
通常は、暗号化鍵を公開鍵として公開して、平文化鍵を秘密鍵として保持する
送信者は公開鍵を何らかの手段で入手・検証し、公開鍵で暗号化した文章を受信者に渡し、受信者が秘密鍵で平文化する
高速化のために実際は共通鍵暗号を使い以下略
■電子署名
平文化鍵から暗号化鍵が求められない場合は、電子署名として使用できる
通常は、平文化鍵を公開鍵として公開して、暗号化鍵を秘密鍵として保持する
送信者は秘密鍵で文章を暗号化し、受信者は何らかの手段で入手・検証した公開鍵でそれを平文化することで検証とする
なお電子署名の場合は暗号化の処理を署名と呼ぶ事が多い
高速化のために実際はハッシュ値を使い以下略
■認証局
公開鍵暗号や電子署名を補助するシステム
公開鍵に付随する何らかの情報について記した文章を認証局の電子署名秘密鍵で署名して配布する
利用者は何らかの手段で入手・検証した認証局の公開鍵を使い、証明書に記された内容が認証局に認められているかを検証できる
■証明書
何らかの内容を何らかの電子署名で署名したもの
通常は文章ではなく、何らかの署名とそれに付随する内容が記されている
検証する者にとって未知の認証局の署名しか行われていないものをオレオレ詐欺と同様にオレオレ証明書と呼ぶ
171:デフォルトの名無しさん
14/03/11 06:29:57.21
>>169
> その送信先が改変意図を持っていたら‥‥
もちろん変造されうる、けれどそれは実質消去された(不達が起きた)上で同じ時刻に送信先が直接投稿したのと同じ
投稿文の識別番号に本文ハッシュを含めれば変造された投稿を元の投稿と誤認させる事もできず不達しか起こせない
最初から複数に送ればいいし、送信先から新着取得して握りつぶしていることを確認したらその送信先は捨てればいい
> 次のバケツでは改変を検出できないものか
投稿文を識別するID(識別番号、投稿者識別のIDでは無い)の一部にハッシュを使うだけで大丈夫、暗号化は不要
成り済ましの防止は最悪GnuPGとかで本文の中に署名を打てばいいだけだから伝送のレイヤで考える必要はない
172:デフォルトの名無しさん
14/03/11 08:54:46.05
そういえば、DHTでハッシュが衝突したらどうします?
173:デフォルトの名無しさん
14/03/11 09:06:11.47
はじけ飛びます
174:デフォルトの名無しさん
14/03/11 09:12:05.00
>>172
普通のハッシュテーブルと同じく連結リストの後ろに追加で良いんじゃね
その場合キー=ハッシュだと不都合があるからサブキーも持たせといたほうがいいかも知れん
DHTのノードID(≒ハッシュ)が衝突したら>>173ほどじゃないけど残念な事になるだろうな
175:デフォルトの名無しさん
14/03/11 09:44:53.91
>>174
スレッドを特定するのがUUIDで
UUID+メッセージNo + MAC
を電子署名するでなんら問題ないと思うけど
176:デフォルトの名無しさん
14/03/11 09:46:52.91
なんで偽造できるMAC?
177:デフォルトの名無しさん
14/03/11 09:49:33.03
理想を言えば
H( UUID + メッセージNo + UnixTime(書き込み時間) + PrivateKey(書き込み者のRSA秘密鍵 ≠SecretKey ) )
を署名すりゃ良い
178:デフォルトの名無しさん
14/03/11 09:50:21.07
>>176
ちみの言っているのは、
Media Access Control
俺が言っているのは
Message Authentication Code
179:デフォルトの名無しさん
14/03/11 18:38:58.91
そういえばスレのハッシュをhとしてハッシュ関数をHとしたら、レスが付くにつれてレスのIDをH(h), H(H(h))...みたくしたら自動的にスレの同期が取れるんじゃないかな
どうだろ
180:175
14/03/11 19:53:07.48
>>179
そういう仕組みは既にある
Message1
Message2
Message3
Message4
とあった場合、
h1 = H( Message1 )
h2 = H( Message2 )
h3 = H( Message3 )
h4 = H( Message4 )
とする
全体の完全性(I)を保障するためには
h-a = H ( h1 + h2 )
h-b = H ( h3 + h4 )
h-c = H ( h-a + h-b )
みたいな
181:デフォルトの名無しさん
14/03/12 00:30:16.40 sV0NfGMp
>>170 >>171
>電子署名
>GnuPG
これは送信元がはっきりしており、「いつでも」送信元から公開鍵を入手できる場合に実力を出すと考えたいね
今は匿名下、または部分的に匿名な状況で、それでもバケツリレーの中で投稿単位の改変を検出して捨てることを考えている
>投稿文の識別番号に本文ハッシュを含めれば変造された投稿を元の投稿と誤認させる事もできず
投稿文の識別番号も改変されたら結局オリジナルは失われる、
が、結局
>投稿文の識別番号
>最初から複数に送ればいい
まあそういうことか、「最初から複数」かな。
182:デフォルトの名無しさん
14/03/12 01:02:43.38 QIz6tpDE
考えるまでもなく、匿名性と書き込みIDの一貫性は矛盾する。
考えるべきは、IDが正当なものは低コストで済み、IDの乗っ取りを企てる者には馬鹿高いコストの仕組み。
そこの現実的な解が無い状態。
というか、匿名なんだからID無しでもおkじゃね?
183:デフォルトの名無しさん
14/03/12 01:06:53.59 sV0NfGMp
>>182
SPAM は専用ブラウザ機能で、でいいから弾きたいねえ、ID を使って
184:デフォルトの名無しさん
14/03/12 01:08:05.09 QIz6tpDE
>>183
それは普通にベイジアンフィルタでいいでそ
185:デフォルトの名無しさん
14/03/12 03:04:53.92 +FPX7RuE
2chと違うだろ。
匿名かつ、可能な限り、IDを保持させることは可能だろ。
IPアドレス、接続名がそのままIDになったらバレてるがそれはIDではない。
186: ◆QZaw55cn4c
14/03/12 03:09:17.27 sV0NfGMp
ベイジアンフィルタにかからないSPAMってあるじゃない、QZの投稿とかさあ‥‥
187:デフォルトの名無しさん
14/03/12 03:14:57.47 +FPX7RuE
MACアドレスを暗号化(ハッシュ化)したらIDに使えないか
荒らしもそれで弾けばいいんでは。
MACアドレスとは、個々のネットワーク機器を識別するための装置固有の物理アドレスです。
個々のネットワークアダプタに割り振られており、またこれは世界で一つしかないアドレスです。
同じマックアドレスのネットワーク機器は存在しません。IEEE(※参照1)により管理されています。
URLリンク(www2.chuo-u.ac.jp)
188:デフォルトの名無しさん
14/03/12 03:16:29.55 v3f2809c
MACアドレスが届くのは最初のルーターまで
189:デフォルトの名無しさん
14/03/12 03:19:06.71 sV0NfGMp
>>185
>>68 で指摘されている、つまり IP(+日付)のハッシュならレインボーテーブルで一発でIPを特定できる、と
なにかいい ID の生成方法はないものか?
190:デフォルトの名無しさん
14/03/12 03:19:18.07 +FPX7RuE
送信する側が発信すればどこまでも行くだろ。書き込み+暗号化したMACアドレス。
191:デフォルトの名無しさん
14/03/12 03:21:52.01 sV0NfGMp
>>187
実は MAC なんて自由に変えることができるのです
realtek RTL8019 とかはそうだし、Windows のデバドラでも変えられるように作っているものも多いし
192:デフォルトの名無しさん
14/03/12 03:22:49.22 sV0NfGMp
>>190
送信側の申告は信用しない
193:デフォルトの名無しさん
14/03/12 03:25:31.24 +FPX7RuE
IPだと、総当りで計算されるってことか。
日付+IP+MACくらいにしたら桁増えるが。
194:デフォルトの名無しさん
14/03/12 03:28:37.40 +FPX7RuE
少なくとも毎回書き込み時に偽造してくる強者は除き、普通の荒らしは弾ける。
1割、MACかハッシュ偽装だったら9割は弾ける。
195:デフォルトの名無しさん
14/03/12 03:31:08.40 +FPX7RuE
2chの忍法帳システムも自己申告制だろう。
偽装できるから使えないんだったら、これを導入し続ける意味は無いはず。
196:デフォルトの名無しさん
14/03/12 03:35:36.76 v3f2809c
忍法帳ってクッキーを正しく送らないといけなくてクッキーはIDとパスワードがあわさったものになってるんじゃ
197:デフォルトの名無しさん
14/03/12 03:46:54.86 Ep3X8sbh
>>195
忍法帳システムが有効なのは、
サーバーに書き込みが行われて(つまりP2Pではない)
プロキシサーバー経由の書き込みを弾いている(つまりIPアドレスチェック)
からなんです。
特に「プロキシサーバーを弾く=本当のIPアドレスを知ろうとしている」という機能は
IPアドレスをわからなくするという匿名と組み合わせるのは不可能なんです。
198:デフォルトの名無しさん
14/03/12 03:48:49.35 sV0NfGMp
>>194
SPAM 屋さんだったら自動で MAC をコロコロ変えるプログラムを作ると思うよ‥‥
1割、というのが投稿数のことだったら、その見積もりは甘いと思う‥‥
忍法帳のクッキーはお上からの賜りものだろう?つまりサーバーの存在が前提だから P2P ではないと思うんだ
199:デフォルトの名無しさん
14/03/12 03:52:20.16 sV0NfGMp
>>193
でも IPの偽装は困難だから ID の生成法としては有望なんです
ネットワークにソルトを浮遊させる、とかはどうでしょうかね
一列射撃問題、みたいなのはないかなあ
200:デフォルトの名無しさん
14/03/12 03:56:45.13 Ep3X8sbh
> でも IPの偽装は困難だから ID の生成法としては有望なんです
プライベートIPアドレスのことだよね?
簡単だけど?
グローバルIPアドレスは、IDを生成する側はわからない。(ルータが持っていたりする)
サーバー側でならわかるから、2ちゃんねるはプロキシサーバーを禁止して上で
アクセス元IPアドレスを取得しているんだ。
でも、匿名=プロ機西によるIPアドレス隠蔽を使うならば、
サーバー側でさえもIPアドレスは取得不可能になってしまう。
201:デフォルトの名無しさん
14/03/12 04:20:17.78 +FPX7RuE
忍法帳システムはP2Pでも可能では?
荒らしや違法な書き込みをするやつ、一般人のIPはばれてもいい、
データ保持してるやつのIPはばれては駄目というのは可能では。
初回書き込みで、ネットワーク上の少なくとも1台がIP見ながら忍法帳データのようなものを発行。
P2Pネットワークを監視し続ければ書き込みとIPが特定できたとしても、
過去レスに対してはIPがばれたり、発信しているPCがばれないようにはできるだろ?
202:デフォルトの名無しさん
14/03/12 04:28:58.43 Ep3X8sbh
>>201
まず、プロキシによるIP匿名化を行うのであれば、
どのマシンもIPアドレスはわからない。
> 荒らしや違法な書き込みをするやつ、一般人のIPはばれてもいい、
コンピュータが書き込み内容を違法かどうかなんて判断できないので
つまり、全員のIPアドレスはばれるということになるね。
> データ保持してるやつのIPはばれては駄目というのは可能では。
データ保持するには、適当なダミーデータを保持すればいいだけ。
データを保持しているという偽装は簡単。
匿名化をやめるという前提でIPアドレスはわかるとしよう。
(その時点でスレタイの完全匿名掲示板は無理ということだが)
> 初回書き込みで、ネットワーク上の少なくとも1台がIP見ながら忍法帳データのようなものを発行。
その1台が嵐の仲間だったらどうする?
> 過去レスに対してはIPがばれたり、発信しているPCがばれないようにはできるだろ?
過去レスのIPアドレスがわからないってこと? ならば過去レスを監視することは出来ないってことだね。
203:デフォルトの名無しさん
14/03/12 04:32:05.96 Ep3X8sbh
既存の○○システムで実現できてるから
それと同じものを搭載すればいい。で
思考停止しないでくれ。
それとは別のものなんだから。
「P2P型の完全匿名掲示板」という条件があるために
既存の○○システムを取り入れるのは
不可能か困難になるんだからさ。
204:175
14/03/12 08:50:12.45 MYUfcuak
>>181
>これは送信元がはっきりしており、「いつでも」送信元から公開鍵を入手できる場合に実力を出すと考えたいね
>今は匿名下、または部分的に匿名な状況で、それでもバケツリレーの中で投稿単位の改変を検出して捨てることを考えている
勘違いしてないかい?
公開鍵を入手する経路は、たとえそれが信頼を置けないノードであっても構わないんだよ
>投稿文の識別番号も改変されたら結局オリジナルは失われる、
>>177 をよく読め
>まあそういうことか、「最初から複数」かな。
これも勘違いしてないかい?
保証したいのは、ノードではなく、メッセージなんだけど?
>>182
うん、
投稿者が、唯一のその投稿内容を、その時に、その人だけが作成でき、証拠がのこれば、IDを保証する意味は無い
>>191
つか、俺の知っている限り、MACを変えられないOSを知らんがなw
SolarisだってBeOSだってMacOS Xだって、漢字talkだって変えられる>>199
>>199
> IPの偽装
容易だよ
205:デフォルトの名無しさん
14/03/12 09:32:51.17 BZHSr6bQ
情報伝達が確実で検証可能ということは、それは完全な匿名にはなりえない。
不完全伝送こそが完全な匿名である。
なんでエラーチェックとかするの?なんで中身を復帰したあとに
確実に戻せたかチェックできるの?
206:デフォルトの名無しさん
14/03/12 09:47:00.84 MYUfcuak
>>205
そうでもないよ
207:646@3
14/03/12 11:14:31.97 AM85Ao7I
>>175
DHTはノードIDとキーの2つがあって、どちらもハッシュ長でハッシュと絡めて生成する値なんだ
DHTではキーやノードIDに生の値を使うと破綻しやすくなり攻撃耐性下がるから、生値はあまり使えない
値のハッシュ値をキーにするような構成の場合値中の一部をサブキーとして持たせるとかってのが前半
後半はピュアなハッシュ値ノードIDのDHTの場合で、部分的に生IPをエンコードするとかの対策に繋がるネタ
>>177
最後の項が物凄く不穏なんだけど…署名ってことはその項は検算用に公開しちゃうんだよな?
>>181
掲示板上の投稿としての成り済ましに対しては、トリップと同じで同一性さえ示せばいいかなと
>>182
トリップ的に電子署名を使えば乗っ取りは簡単に防げる
匿名のために署名を乗り換えた時や新規参加時にどう信用を獲得するかは課題だけども…
>>187
自由に変更できるし実は結構被っている(不正なベンダIDや、古いMACの再利用が有るらしい)
ルータ境界を越えられないって制限があるからまず問題が表面化しないというだけ
208:デフォルトの名無しさん
14/03/12 11:15:18.61 AM85Ao7I
>>192
現代暗号とかはわりとそういうところがあるんだが、または信用出来ない事を前提に設計するしかないね
>>194
それも当初は有効だと思うけれど、どーせそのうち不正改造版が出回るって想定した方がいい
>>199
>>91も最終手段的にそういうアイディアだし、ID生成サーバみたいなのを設置するのは有りだけど
常時それにしか頼れない仕組みではそのサーバの運営者が匿名性を保証しないと駄目なんよ…
上手く適用できる秘匿計算アルゴリズムがあればいいんだけど
>>200
ローカル計算に依存してたら只の自称でMACアドレスと同じで無意味じゃない?
IPアドレスを使う場合、外部(相手や認証局)から観測することでそれを保証するしか無いと思う
>>201
忍法帖云々とか関係なく、データ所有者を隠蔽するのは独立して実現できる
それと、その方法でIDを保証する場合「少なくともN台」ノードをエミュレーションすれば幾らでもIDを偽造できる
N台をネットワーク上のN%とかにすると、小数のクローラを設置するだけで全ID-IP対応をロギングできてしまう
209:デフォルトの名無しさん
14/03/12 11:23:32.16 MYUfcuak
>>207
>最後の項が物凄く不穏なんだけど…
大したリスクにはならんよ。それがMD5だとしても
210:デフォルトの名無しさん
14/03/12 12:24:00.60 sV0NfGMp
>>204
>公開鍵を入手する経路は、たとえそれが信頼を置けないノードであっても構わないんだよ
今は匿名性に比重を置いているのだから、公開鍵の入手先はどうするか、という問題はどうするか?
>> IPの偽装
>容易だよ
winny にプロキシをかまして偽装する、とかは聞いたことがないんだが。
ブラウザのIP偽装は簡単だが、プロキシ対応していないアプリがごにょごにょやるとき、そいつのグローバルIP を偽装する方法はあるのか?
211:デフォルトの名無しさん
14/03/12 12:44:42.78 MYUfcuak
>>210
は~あ・・・
>今は匿名性に比重を置いているのだから、公開鍵の入手先はどうするか、という問題はどうするか?
別に持ってくる必要があんのか?
言っても分からんと思うけど・・・
電子署名 ≠ 署名
だかんね。
212:デフォルトの名無しさん
14/03/12 12:45:22.51 MYUfcuak
>>210
>そいつのグローバルIP を偽装する方法はあるのか?
いくらでもある
213:デフォルトの名無しさん
14/03/12 21:37:36.44 Ecp3hakT
一旦話を整理しましょうか。
☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
☆電子署名には幾つかの手法があるが、PGPなどの自己署名する形式の署名は幾らでも作成でき複数の投稿を複数の署名で行うことにより自演できてしまう。
☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
214:デフォルトの名無しさん
14/03/12 22:06:28.16 Ep3X8sbh
☆ID(署名)でできること。
ある書き込みに署名Aと書いており、
別の書き込みにも署名Aと書いている。
どちらも署名Aだから同一人物であることはわかる。
なぜなら赤の他人が署名Aを作ることは不可能だから
☆ID(署名)でできないこと
ある書き込みに署名Aと書いており、
別の書き込みにも署名Bと書いている。
この二つの書き込みをした人が別人かどうかはわからない。
なぜなら、一人が複数の署名を持つことは可能だから。
215:デフォルトの名無しさん
14/03/12 22:17:36.01 Ep3X8sbh
「☆ID(署名)でできないこと 」
に関して、2ちゃんねるとの違い。
2ちゃんねるでは、このスレでもそうだが、IDがでてる。
このIDによって、2ちゃんねるでは自作自演が難しくなっている。
たとえば、俺の今のIDとは違うIDにしたければ、
回線を複数持つか、一旦回線を切ってIPアドレスを変えないといけない。
この2ちゃんねるの仕組みと同じことをP2P型完全匿名掲示板でも出来るかといえば、できない。
なぜなら、2ちゃんねるはIDを発行するのは2ちゃんねるのサーバーであり、
P2P型完全匿名掲示板では、IDを発行するものがいない。
誰かがやるとしても、その「誰か」を自分自身がやることで好きなIDを作れる。
ID発行サーバーを作るならば、それはP2Pの完全匿名掲示板にはならない。
また、2ちゃんねるのIDは、IPアドレスを元に算出しているが、
P2P型完全匿名掲示板はIPアドレスが隠蔽(別の人のIPアドレスになる)される。
ID発行サーバーへはIPアドレスを隠蔽してはならないという制約をつけると、やっぱりP2P完全匿名掲示板にはならない。
だから2ちゃんねると同じ仕組はできず、自作自演を防ぐ効果は著しく低くなる。
216:デフォルトの名無しさん
14/03/12 22:23:05.29 Ep3X8sbh
>>210
> winny にプロキシをかまして偽装する、とかは聞いたことがないんだが。
winny の「中継」という機能は「プロキシをかまして偽装する」行為そのもの
Winnyの匿名性というのは、プロキシ機能によるもの。
相手のグローバルIPがわかってしまえば、匿名性が無くなる
だから中継(=プロキシ)によって匿名性を保つっていうのが
匿名技術の本質。Torも同じ仕組。
だから、相手のグローバルIPアドレスはわからない。
偽装以前に、相手のグローバルIPアドレスは、わからないんだよ。
だから2ちゃんねるは、相手のグローバルIPアドレスをなるべく確実に見つけるために
プロキシサーバーの利用を禁止して、匿名(IPを知らせない)での書き込みを禁止している。
217:デフォルトの名無しさん
14/03/13 00:07:33.64 g1sRHDdX
>>215
時間同期型のトークンを無作為生成するだけで対処できると思うが
発行サーバーはいらない
問題はこのトークンが改変されない仕組みを作り出せるかどうかだけ
IP依存にする必要がなくなる
極めて低確率でトークンが同一になる可能性はあるがそれは仕方ない
おそらくトークンのジェネレータを不定期に変更する権限を開発者が持つ必要がある
そしてそれが実行されたか知られないようにしなければいけない
218:デフォルトの名無しさん
14/03/13 00:31:51.78 2uVCIEWC
>>217
それはID発行システムをブラックボックスにするという発想だと思うけど、そういうのは下策だと思う
匿名だと信じていたら実は解析されていた、なんてことになると今の2ちゃんと同じ状況になる
219:デフォルトの名無しさん
14/03/13 01:12:01.54 +lIKaSU4
秘密鍵をコロコロ変える行為にペナルティを課すことにすればいいんじゃないの?
たとえば新しく生成されて自分が見たことのない秘密鍵で署名された、
署名チェインのないレスを送ってきたノードへの接続を制限するとか。
他人のレスに署名チェインを追加して転送する回数が増えるにつれ信用を上げていく感じ。
220:デフォルトの名無しさん
14/03/13 01:42:12.97 2uVCIEWC
>>219
そこをどうするかということを模索することになると思うけど、ベストな方法は無いと思う
複数の方法を実装できれば荒らされたときに慌てずに済むんじゃないかな
221:デフォルトの名無しさん
14/03/13 03:54:12.43 g1sRHDdX
>>218
解析される可能性があるのはやむを得ない
匿名性を守ろうとすればどうしてもそのリスクは受け入れざるを得なくなる
解析されるかもしれないから却下ではなく
解析がとてつもなく厳しいものになればいい
あるいは解析されたとしてもお手上げになるように
具体的にはP2Pコネクションを行っているプロセスA
トークン管理をしているプロセスB
そして第三者のプロセスC
A-B,B-C,C-Aでプロセス間通信で監視しあい、誤った暗号ブロック(クラックされた可能性がある)が送られた場合は即時停止
リポートを流し開発者に伝える
222:デフォルトの名無しさん
14/03/13 05:04:45.81 obdyzpxj
>>213
どこが整理やねんw
なんもわかっとらんし
>☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
うんにゃ
MICでもMACでも電子署名でもハッシュだけでも可能
>☆電子署名には幾つかの手法があるが、
>PGPなどの自己署名する形式の署名は幾らでも作成でき
>複数の投稿を複数の署名で行うことにより自演できてしまう。
CA建てるならP2Pじゃなくなるね。
>☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
PKIじゃなくてもOK
>☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
うんにゃ
ネットワークに参加しているメンバーのIPが特定されても実現は可能だよ
>☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
そうなん???
改ざんが検出されたものは転送せずに破棄すりゃいいじゃん
正しいデータを読み出せる必要は無い
223:デフォルトの名無しさん
14/03/13 05:08:30.64 obdyzpxj
>>217
>>177
224:デフォルトの名無しさん
14/03/13 06:03:19.06 j0o71mYX
>>☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
>うんにゃ
>MICでもMACでも電子署名でもハッシュだけでも可能
確かにそうです
至らない点がありました
>>☆電子署名には幾つかの手法があるが、
>>PGPなどの自己署名する形式の署名は幾らでも作成でき
>>複数の投稿を複数の署名で行うことにより自演できてしまう。
>CA建てるならP2Pじゃなくなるね。
P2P上で、あくまで自動化された鍵の生成と認証をするのみにとどまります。
>>☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
>PKIじゃなくてもOK
何かありますか?
>>☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
>うんにゃ
>ネットワークに参加しているメンバーのIPが特定されても実現は可能だよ
書き込んだ人のIPアドレスの話をしています。
>>☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
>そうなん???
>改ざんが検出されたものは転送せずに破棄すりゃいいじゃん
>正しいデータを読み出せる必要は無い
可用性は出来るだけ上げるべきではありませんか。分散保存される場合は改竄を破棄するとかなりの打撃になります。
225:デフォルトの名無しさん
14/03/13 10:58:42.23 obdyzpxj
>P2P上で、あくまで自動化された鍵の生成と認証をするのみにとどまります。
何を認証するのかが不明瞭なんだよ
話の流れでは、メッセージを認証しようとしているけど、
ここではIDを認証しようとしている
ちぐはぐ
>何かありますか?
無理にCAを建てることもあるまい
>書き込んだ人のIPアドレスの話をしています。
今でも十分書き込んだ人のIPアドレスかどうか分からなくなっているだろ?
なぜ、それでも、分かるんだ?
・転送した記録が各ノードに残る
・要求内容とIPアドレスに紐付けがされる
・転送内容をノードが理解できてる
・フルキャッシュを持っているノードが特定できる
だろ。
あとは良く考えろ
>可用性は出来るだけ上げるべきではありませんか。分散保存される場合は改竄を破棄するとかなりの打撃になります。
ナンセンス
改ざんされたデータは、ゴミ以外の何者でもないので、即時破棄の方が可用性は向上する
226:デフォルトの名無しさん
14/03/13 11:01:09.71 4kUzoZI/
>>219
新しく登場した署名は暫く信用しないってだけで十分だと思うというか、
そこにノードの接続性まで絡めるのはなんか違う気がしてならない
ノードの信用(及び署名+公開(暗号化)鍵)と
投稿者の信用(及び署名+公開(暗号化)鍵)は
分けて考えたほうが良くないか?
>>221
いずれ解析される前提で考えないと不味いって話でしょ
解析されるまでの間は有効に機能するとしても、
解析された後に全滅するしか無いシステムじゃ不味い
>>223>>177
ちょっと式の意味をもうちょい詳しく頼む
秘密鍵(SecretKey)≠SecretKeyとかPrivateKey関数の意味とかよく分からん
227:デフォルトの名無しさん
14/03/13 11:14:00.71 obdyzpxj
>>226
>>177で話されていた内容は、メッセージのIDをどう作るか
Secret : 秘密情報
SecretKey : 共通鍵方式における秘密鍵
PublicKey : 公開鍵方式における公開鍵
PrivateKey : 公開鍵方式における秘密鍵
秘密情報(Secret)やユニークなID と メッセージを関係付けるのは、良い考えかただが、
公開鍵の持ち主との関係が希薄になる。
重要なのは、
○そのとき
○そのスレで
○そのメッセージが
○その公開鍵ペアを持っている人
のみ、IDを作れられなければならない
H( ) はハッシュ関数の意味
228:デフォルトの名無しさん
14/03/13 11:27:26.12 4kUzoZI/
なんてーか、ネットワークを構成するレイヤと投稿やデータ交換を行うレイヤを区別しようぜ
>>213
> ☆1
署名が要るのは成り済まし防止(同一性の証明)の時
> ☆2
実装や認証のツリーが違うだけで仕組みは大差ない
> ☆3
署名の複数所持を認めるなら不要
>>224
> 書き込んだ人のIPアドレスの話
ネットワーク構成レイヤでの参加者IPアドレスは隠したら通信できないので不可能
参加者IPアドレスの中で投稿やデータ交換したIPアドレスを隠すのはオニオンルーティングなどで可能
投稿者IDないし署名の複数所持を認めずその為にIPアドレスを使う場合、上手く設計しないと匿名性が薄れる
> 改竄を破棄するとかなりの打撃
改竄された領域は通常本来のデータを意味しないので、そこから意味有るデータを読み取ろうとしても無駄
改竄に参加していないノードから情報を回復した方が良いし、それにはできるだけ早く破棄したほうが良い
229:デフォルトの名無しさん
14/03/13 11:51:48.62 4kUzoZI/
DHTに格納するデータとしてのキー(ハッシュ値)の衝突の話(>>172>>174)から行くと、
キーを>>175の生値にするとDHTが機能不全を起こすし、>>177だと結局ハッシュが衝突しうるよね?
あと、そのキーが正しいもので有ることを検証するためには(DoS的スパム(≠投稿スパム)の排除)、
ハッシュ関数の入力をそのデータ内で公開する必要があるから検証してる場合には使えない気が
ストレージとしてのDHTは恣意的なキーを使うと容易に死ぬし、
ハッシュだから念のために衝突対策(例:リスト)が必要になる
衝突時の区別に使うサブキーは…ぶっちゃけ何でもいいけど
なんだけど、DHTに格納するキーとしてはその値を署名云々とか何の意味があるのかよく分からんのよ
230:461
14/03/13 13:19:29.74 j0o71mYX
>>228
> 改竄に参加していないノードから情報を回復した方が良い
すみません、そういう意味で言っていました。
>>229
値が変動すればキーも変わらなければならないのですが、たまに同じハッシュが生成されてしまう場合があるのです。
DHTではデータが多数のノードに分散されて配置される。
データを担当するノードはそのデータに手を出すこともできる。
それを検出する機構が必要になるってことですね。
231:デフォルトの名無しさん
14/03/13 13:23:59.80 obdyzpxj
>>229
コリジョンが発生するのは、同一スレッド内だけだから、
死ぬまで使ってもコリジョンしないよ。
232:デフォルトの名無しさん
14/03/13 13:35:11.61 meCkOYxs
改竄されたところでそれが重要なこととは思えないが。
同時性は大事と思うが。
あるPCには見えるものが、離れてるPCでは見えないとか。
233:デフォルトの名無しさん
14/03/13 13:40:15.66 obdyzpxj
>>232
ユーザ側の「勝手な」要望としては、そうだろうね。
ただ、P2Pの性質としては、同一スレッドを参照書き込みしている人達にはより早く
そうでない人にはそれなりに、
ってなっちまうと予測
スレを収集するフェーズで、よりプロバイダとの距離が近い者ほど早く
ってな実装にすると、パフォーマンスと要望が満たせる
んが、同時性は明らかに損なわれる
ところで、読んでさえいない2chのスレッドに同時性を求めるのかい?
234:デフォルトの名無しさん
14/03/13 14:15:32.22 meCkOYxs
読んでるスレッドを更新して、PCごと差が出て10秒以上内容がずれたり、いくら待っても内容が届かないとかは重大な問題。
235:デフォルトの名無しさん
14/03/13 16:17:21.14 4kUzoZI/
>>231
それはつまりスレッドごとにDHTネットワークを構築するってこと?
それならコリジョンはまず起きないだろうけど…
236:デフォルトの名無しさん
14/03/13 17:28:42.04 obdyzpxj
>>235
スレッドのメッセージIDの話をしてんだから、それで問題ないだろ。
そもそも、だ、
自分に関係のないスレッドのメッセージを一意に特定する意味があんのか?
欲しい情報は、
このスレッドの、このメッセージ
じゃね?
スレッド一覧は、ShareやWinnyのようにハッシュで管理すりゃいいだろうし、
分散ハッシュテーブルでも構わんと思うよ。
その中のメッセージがシステムWideで一意のハッシュ値である必要性がどこにある?
237:デフォルトの名無しさん
14/03/13 17:37:41.50 obdyzpxj
>>234
無茶苦茶起こると思うよ
実装次第だけど、俺の頭ん中の実装だと、過疎スレは非常にレスポンスが悪い
逆によい傾向じゃあねぇか
238:デフォルトの名無しさん
14/03/13 18:08:37.29 4kUzoZI/
>>236
DHTネットワークのモデルって単層のキーバリューストアだから、
それをスレッド数だけ多重化するとは思わなかったんだよ・・・
DHTネットワークを多重に構成する場合のコストって何十と稼働させても平気だっけ?
239:デフォルトの名無しさん
14/03/13 18:24:12.63 obdyzpxj
>>238
なんか問題ある?
「多重にうんぬん」の時点で分かってない気がするのは俺だけかな?
多重に云々 が起きる事態なら、それを捨て置けば良いんでなくて?
そうすれば、人気のあるハッシュがより拡散するんでなくて?
どうしてもレアなものをゲットしたいのなら、そのノードが頑張るんじゃないの?
240:デフォルトの名無しさん
14/03/13 18:28:50.44 V8jBRZJr
>>177 のようにハッシュに秘密鍵を入れる必要もないわけだが
お前が一番わかってないから他の人の話と合わないんだろ
241:デフォルトの名無しさん
14/03/13 18:38:41.46 4kUzoZI/
>>239
んん?スレッド単位でDHTに格納してく場合のスレッド内でのメッセージIDの話で、
メッセージ単位でDHTに格納してく場合のメッセージIDの話ではないって事?
読み返したら>>236でDHT前提にしない事も考えてるみたいだけど、
>>229でも書いたように元はDHT格納時の衝突の話だから、
衝突を考慮するID振り当て対象はDHT格納単位の筈なんだが…
242:デフォルトの名無しさん
14/03/13 18:48:36.48 obdyzpxj
>>240
ハッシュに秘密鍵を入れる理由が理解できないお前がアフォなんだとよくわかるレスだわ。
どうぞ、セキュ板だろうと、ネットワーク板だろうと、拡散してくださいwww
243:デフォルトの名無しさん
14/03/13 19:03:18.92 obdyzpxj
>>241
なぜにスレッド単位にしない?
UUID+メッセージIDで充分だろ?
244:デフォルトの名無しさん
14/03/13 19:03:43.57 j0o71mYX
折角分かってるなら説明してあげればいいじゃないか
245:デフォルトの名無しさん
14/03/13 19:33:48.71 obdyzpxj
むしろ、拡散されて、バカが釣れるほうがオモロいんだが
246:デフォルトの名無しさん
14/03/13 20:25:08.49 aSwmjniW
秘密鍵が元に入ってるハッシュと適当なランダム文字列と、他人がどう見わけるの?
これでそんなことをする意味がないことがわかりるだろう
247:240
14/03/13 20:26:10.95 aSwmjniW
ID変わってるけど>>240な
248:デフォルトの名無しさん
14/03/13 21:35:09.78 meCkOYxs
P2P上に仮想データベースを作れ。
追記とリードのみ対応。
各記録ブロックは5-10台程度で保持。
さらにおまけでP2P上にビットコイン採掘を同時に行い電気代回収。
249:デフォルトの名無しさん
14/03/13 21:58:19.12 Slx1TmTl
ん…だからさ。
PKI は論外。アングラ世界で「信用の輪」を広げようったって駄目。原理的に無理。
「とりあえず○○さんを名乗る人からこの書き込みを受け付けました。責任は持てません」ということを多数決で事実確認するのが関の山。
どうせ保障も責任なんて誰も何も取りようがない。
降水確率よろしく、「この書き込みが○○さんである信頼性は××%です。なお、東アジアのノードには改竄警報が出ています」ってくらいでいいんじゃない?
クソみたいにアバウトにやった方がいい気がしてきた。
250:デフォルトの名無しさん
14/03/13 22:01:40.58 9sS6Jz5v
○○さんは、100人の人から信用できると言われています。
(その100人は、すべて○○さんが作ったアカウントです)
匿名である以上、一人が複数の人を演じることは防ぎようがないからね。
251:デフォルトの名無しさん
14/03/13 22:15:12.44 aSwmjniW
論外ではなくて、その「多数決で事実確認する」ということもPKIの一つの実装だろ?
252:デフォルトの名無しさん
14/03/13 22:36:49.30 Slx1TmTl
>>250
そのノリでいいんじゃない?
第三者に拠り所を敢えて求めないならそのノリしか無いと思う。
ていうか、マロユキの「嘘を嘘と…」という言葉は結構名言だわ。
あいつ大嫌いだけど、匿名性を求めるなら何らかの妥協は必要だ。
「完全」「匿名」「IDの一貫性」のどこかで何かをある程度で捨てなきゃならんはずなんだが…。
何をどの程度、となるとスレで合意が得られるものでもあるまい。匿名性の限界は色んな意味でそこにある。
>>251
ねーよ。てめーこそ論外だ。
保証人のいない PKI なんか存在しない。逆に、保証人がいるからこその PKI だ。何のための公開鍵「基盤」なんだよ?
多数決制は主にアングラ面でしか発達してない。
政治的にせよ、経済的にせよ、信頼や保証を得られるものを拠り所にするのは変わらん。
久々の頭悪杉。
あ、「事実確認」は「事実認定」のミスね。意味分かる?
253:デフォルトの名無しさん
14/03/13 22:45:27.80 aSwmjniW
多数決はお前が言い出したんだろ。何だこいつ?
>>177 と同じ奴か?もっと柔軟に考えろよ。頭が硬すぎて全く理解できてないよ
多数決だからPKIと言わないとか言葉遊びがしたいだけなら別スレ立てて独りでやってろよ
254:デフォルトの名無しさん
14/03/13 23:00:02.05 meCkOYxs
分散ファイルシステムをググった結果。そのまま既成品を流用できないか。
Apache Cassandra - Wikipedia
Apache Hadoop - Wikipedia
Apache HBase - Wikipedia
BigTable - Wikipedia
ColonyFS: A Peer-to-Peer Filesystem URLリンク(launchpad.net)
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 URLリンク(www.komoto.org)
OpenAFS - Wikipedia
RAID - Wikipedia
Riakはオープンソースの分散データベース URLリンク(basho.co.jp)
Tahoe-LAFS 分散データ・ストア URLリンク(sourceforge.jp)
分散ファイルシステム URLリンク(dic.gree.net)
255:デフォルトの名無しさん
14/03/13 23:07:51.49 aSwmjniW
はっきり言っといてやるよ。頭悪杉は >>177 押しのお前な。
秘密鍵のハッシュを入れたところでそれで真贋が確認できるのは本人だけ。
何の意味がある?全くねーよ。お前みたいな奴って決まって人に高圧的で暴言吐くよな。
それで結局一番バカってどのスレでもそうだよな。同じ奴かと思うわ。
256:デフォルトの名無しさん
14/03/13 23:37:01.94 obdyzpxj
>>255
おめえ、本当に頭悪いな。
たしかに、秘密鍵でなくとも、乱数で良い訳だよ。
ただな、
あとは読めば分かるよなw
257:デフォルトの名無しさん
14/03/13 23:48:36.61 obdyzpxj
>>252
「IDの一貫性」は、ユーザにコストを強いれば実現可能かもね。
だから、今しがた参戦したIDは自演を疑える仕組みさえあれば良いような気がする
258:252
14/03/14 00:34:18.48 0klM2rM4
>>255
いやぁ…多数決に関しては何も肯定的な意見を述べた事がないのですがね?
それと、
> 秘密鍵のハッシュを入れたところでそれで真贋が確認できるのは本人だけ。
その「本人の証言」が信用できないから裁判沙汰とかになる。
簡単な例を出しましょう。
俺「あ、俺、俺だよ >>255。俺、お前に 1000万貸してるよな?」
>>255「んなもんしらねーよ」
俺「請求書はおまえんちのポストに入ってる。借用書のコピーもあるから」
>>255「んだよそれ?証明してみろよ!!」
俺「じゃあすぐここに来て。確認するから。俺が『確認した』って言えば証明されたことになるんだよね?」
これに納得する >>255 であった…。話にならない。
259:252
14/03/14 00:47:34.77 0klM2rM4
要するに、匿名性とは、裏返すと
「理屈だけで誰かを信じるととんでもなく損を被る」
世界でもある。
秘密結社や裏世界の人間が「濃い」人間関係をもって信頼としてきた理由はそこにある。
「原理的に『一見さんお手軽匿名掲示板』は無理」というところで返したい。
俺のオススメは「IDの一貫性の放棄」なんだけど。それが一番実装的に楽。
260:デフォルトの名無しさん
14/03/14 00:52:16.27 0pDp1vl3
>>256
お前が煽りたいだけのアホだということがよくわかるな。もちろん、ちゃんとした理由があるなら説明すればいい。
もし理由があるなら今の所誰も理解できてないし、それはプラスになる話だからな。だたまあ無いと断言するけどね。
>>257
2ちゃんの荒らしレベルしか想定できてないよね。自演とかはどうでもいい。個人が適当に判断すればいい。
問題になるのはスパムだ。例えば他の掲示板の普通の書き込みを脈絡なく大量に流されたら、
レスを一つ一つみて判断するということは不可能になる。普通の書き込みだからベイズフィルタも効かない。
こういう場合はPKIが必要になる。実際にfreenetのFMSやAmoeba/Lairにはその仕組みが実装されている。
スパムを送ってくるノードを弾けばいいと思うかも知れないけどそれは匿名性が無いことを意味する。
261:デフォルトの名無しさん
14/03/14 01:09:41.04 0pDp1vl3
>>258
>>255 をどう受け取ればその返しになるのか全く理解できんが、
おれも、「多数決に関しては何も肯定的な意見を述べた事がない」よ ?
>>249 >多数決で事実確認するのが関の山
これお前のレスだろ?ID一緒だよ?
262:デフォルトの名無しさん
14/03/14 03:52:13.21 CPRA+HBa
そろそろα実装が出てもいいころだね
263:デフォルトの名無しさん
14/03/14 06:55:48.60 UviZyuU8
>>260
ちゃんと書いてあるのに理解できないってことは、
説明しても理解できないってことだろw
264:646@3
14/03/14 07:29:58.56 VKpN6+bp
>>243
何故にも何もメッセージ単位でDHTに入れる場合のキー値の話だったんだし、
スレッド単位でDHTに入れる場合にスレッド内メッセージのキー値の話するほうが何故に?だよ
スレッド単位でDHTに入れる場合ならまずコリジョンしないだろうから、確かにキーは適当でいい
>>254
そういうのは分散先ノードは同一の組織の管理する"管理が信用できるノード前提"な事が多いからなぁ…
参加しているノードが意図的に不正な動作をした場合の対処が可能なシステムでないとキツイ
265:ID:4kUzoZI/
14/03/14 07:52:00.48 VKpN6+bp
>>256
スマンが詳しく頼む、俺以外にも何のメリットがあるのか疑問に思ってる奴が居るっぽいし
>>177はスレッド内でメッセージを区別するIDとしてそのハッシュ値を使うって用途だと思うが
「そのハッシュ関数の入力は公開するのか(秘密鍵を含むから無理だよね?)」
「入力を公開しない場合、不正なメッセージIDをどうやって検証して排除するのか」
「検証を行わない仕組みとした場合、第三者からみて乱数と何が違うのか」
「検証を行わない仕組みとした場合、意図的なコリジョンが起こせるがどうするのか」
「"署名すりゃ良い"とはメッセージのどの範囲をどの鍵で署名するのか」
「本文のハッシュなら不正な本文を差さない保証があるが、それに勝るメリットがあるのか」
など何を意図した式なのか(そもそもUnixTimeが関数ぽい表記だったり式としても謎い)よく分からんです
>>258
>>255は>>177の方法では無意味って言ってるだけで、その他何かしらの方法を肯定しているわけではないと思う
>>261
「関の山」の後が問題なんじゃないの?
「その程度が関の山だが使えんこともない」と「その程度が関の山だから使えるわけがない」では意味が全く違う
266:デフォルトの名無しさん
14/03/14 08:07:21.36 UviZyuU8
めんどくせぇなぁ・・・
>「そのハッシュ関数の入力は公開するのか(秘密鍵を含むから無理だよね?)」
入力を公開する必要性がどこにある?ただ単なるメッセージのIDだぞ
>「入力を公開しない場合、不正なメッセージIDをどうやって検証して排除するのか」
第三者が検証できてよいのか?その検証結果を偽装することも考えなきゃならんだろ。
不正なメッセージだと主張できるのは、本人だけじゃないのか?
267:デフォルトの名無しさん
14/03/14 08:14:10.04 UFFJd6rH
P2P Replicated File Store
コンシステントハッシングと仮想ノード
URLリンク(stat.ameba.jp)
URLリンク(stat.ameba.jp)
ノード追加時のデータコピーの局所性
URLリンク(stat.ameba.jp)
レプリケーション
URLリンク(stat.ameba.jp)
URLリンク(stat.ameba.jp)
URLリンク(ameblo.jp)