P2P型の完全匿名掲示板はまだ出来ないの?その5
■ このスレッドは過去ログ倉庫に格納されています
>>86
論文ではキャッシュ機能について言及されているけど、
遠いノードには古いデータしかキャッシュされてない蓋然性が高いだろうから、
掲示板のような刻々とデータ内容が変化するアプリケーションではあまり意味がないだろうね。 バケツリレー多次元版でいいと思うんだが,みんな DHT なんだね DHTって匿名性無いもんな。自称IDを許可すれば別だが。
>バケツリレー多次元版 って何? >>91
バケツリレーの場合、配信時間を有る程度保障する方法は何があったっけ?
>>92
匿名性を確保する為のオーバレイネットワークの上に乗せれば匿名性は確保できる(各種効率は下がる)
> >バケツリレー多次元版 って何?
本来のバケツリレーは1次元ってことでしょ
でも多次元のバケツリレーって厳密にはどういう経路を意味するんだろう? >>93
配信時間は保障されないだろうね、それどころか到達性もあやしい、ただDHTよりロバストだろうから掲示板用途ではわりといいのでは?
>>92 >>93
たぶんメッシュとか超メッシュとか、一つのノードが複数の上流とそれと同数の下流を持つ仕組みだろう もちろん掲示板のタイトルはあやしいわーるど@P2Pだよな?
って書いたら消されたぞw
未だにあやしいわーるどと2ch対抗してんのかよw 鯖移転の時に一部ログがロールバックしたらしい
まぁ所詮2ちゃんだし、いわんや今の運営では… 送受信双方がその専用デバイス?を持ってたらいいんかえ >>97
A地点から発した光子をB地点へ生のまま届ける回線が必要になるから、インターネットは使えないぞ。 ほんと、「暗号化」を自分を守ってくれる
万能の技術みたいに思っているやつが多くて笑うよw
暗号化は何を守る? 第三者からの盗聴からだ。
匿名性は関係ない。
むしろ逆で送り主、送り先、この双方が相手を知っており、
その二人にとっての ”第三者” からの盗聴を防ぐのが暗号化だ。
読める二人だけ、第三者は読めない。これを実現するのが暗号化だ。
掲示板でそれをやる? アホか。そもそも掲示板は第三者が読めるものだ。
暗号化を使う意味は無い。 >>100
> 暗号化は何を守る? 第三者からの盗聴からだ。
> 匿名性は関係ない。
暗号化は、情報を盗聴から守るだけでなく、使い方によっては
改ざん防止や経路秘匿もできる。 >>101
ならば、改ざん防止や経路秘匿といえば良い。 だから、暗号化技術じゃなくて、
具体的に暗号化のための技術名を言えばいいだけの話。
改ざん防止技術や経路秘匿技術。といえば良い。 >>97
やっと理解した
これ無線LANの傍受を想定した盗聴防止なんだな いや、無線LANではない。そもそもプラグラミングの技術ではない。 >>105
言葉遊びでもなんでもないよ。
暗号化技術には、共通鍵方式もあるが、
それらは改善防止には使えない。
暗号化技術だからって、それらが改ざん防止や経路秘匿に使えるとは限らない。
また改ざん防止には(P2Pには使えないも知れないが)
特定の機関が保証する方式も考えられる。
これは暗号化技術ではない。
だから正確に言いましょうって話。 DHT使うとして、Pull or Push→Hand shake(メタデータチェック)→Transfer、だよな?
Hand shakeするためにはTCP必須やん >>100
マイナーな話だけど、一応、暗号化は第三者による改竄からの保護も直接の用途に含むよ。
>>102
経路秘匿は、盗聴からの保護の一部に含まれる用途だと思うのだが…
第一その主張だと「暗号化を行い〜」と言わずに「盗聴から保護を行い〜」と一々言えってのと同義だ。
用途が具体化されただけで手段が抽象化されてしまうから結局駄目だよ。
正確に、というなら「暗号化によって盗聴からの保護を行い〜」となるが、どう考えても冗長だ。
>>108
正確に言いましょうって話したいなら>>100の時点から
どれに対するレスか明確にしておかないと結局言葉遊びじゃね どうでもいいけど光ルーティング技術って電話のクロスバースイッチに先祖返りしてるみたいで妙な気分
>>97
現代暗号で取り敢えず十分だし、そもそも量子通信のためのインフラがねぇよ
>>98
そして両者をつなぐ回線(回線網)がこれに対応している光ファイバである必要がある。
現状は専用線として光ファイバ引かないとムリ。
>>99
今のイーサネットでは対応できないけど、将来的にインターネットと呼ばれる可能性はあると思うよ。
光パケットルーティングとか光波長ルーティングとかの電気信号変換しない回線網が全体に行き渡れば、あるいは。
PPPoEじゃないけど、〜oEって形で量子通信対応端末まで繋いで云々とか、ありそうじゃね?
>>106
傍受を想定しているのは確かだが、電線や光ファイバも含んでの傍受および中間者を想定してる。
これ自体は乱数列の共有しかできないけど、それを使って本命の通信の暗号化を行う。
量子暗号はだいたいそんな感じ。 >>111
>現代暗号で取り敢えず十分だし
いや、これはちょっと心配だ。とりあえず RSA から離散対数に乗り換えるつもりだが、いい公開暗号系は存在しないものか‥ >>112
匿名掲示板でどんな情報をやりとりするつもりなんだ… >>113
暗号は改ざん防止と、経路秘匿が目的なんで、
情報はオープンなものだよ。
だれでも見れる。 てかマジで先に要件定義やれってw
UDPとかTCPなんてのは詳細設計だろ。 よくわからんけど、みんなで意見出し合って仕様をきめて、みんなで作業を分担して
作ろうみたいな趣旨なの?
作れる人はさっさと作ればいいじゃんって思うけど。 >>119
スレの目的を考えるに、
後者の趣旨なら、クレクレスレという事になるから、あまりに糞スレ過ぎるだろ。
前者の趣旨の方が、まだ建設的。 これでよくね?
【匿名化レイヤー】torなどsocks串対応
【掲示板レイヤー】普通の2ちゃん掲示板
【検索レイヤー】DHTでスレッド検索 >>121
それのどこがP2Pなんだ?検索だけか?
掲示板運営者の鯖がダウンしたら終わりだろ。 中央集権的な運用から脱却し、分散的な運用をするのがP2P掲示板のメリットではないか。 第一、tor上の匿名掲示板ならOnionちゃんねるという物が既に存在する。 ミラーリングするんだよ。DHTを使うのはそういう意味。
スレッドを閲覧する為にはDATを落とす、落としたDATは所持しているスレッドとしてDHTに登録する
シンプルだが十分だろ? >>119
要件要件騒いでる奴の中には知ったかぶり無能営業みたいな中身の無い用語大好き人間が混ざってるから話半分に聞いとけ。 >>114
現代暗号で不十分なレベルの改ざん防止と経路秘匿が必要な公開の掲示板って一体…
本気で考えるならTorあたりも別途侵入のマルウェア経由でスパイされてたりする話を踏まえて
現代暗号の安全性よりも端末管理の安全性のが先に破綻するだろう問題から気にしていこうぜ 個々のユーザーのポカまで気にしてもしかたがないと思う Outoposが荒らし対策にマイニング実装されていい感じで使えるようになった。
匿名コミュニケーションツールとしては現状第一候補だろう。
http://awabi.2ch.net/test/read.cgi/download/1404036776/52 やっとPart1から追いついた。
4130レスの長い道のりだった。
意味はないけれどトリップ付けておく。 ★2ch勢いランキングサイトリスト★
◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索 >>134
故意に破られる穴を設計しているからです。
完全に破られない暗号などが第二次世界大戦の時代に発明されても
そのときは使われても、あとからあとから
簡単に破られるものを上書きして最強のように騙しこんできた。 >>135
ワンタイムパッドの事かな?
確かに破れないけど実用性が無いから常用されてないんだけど >>136
最近使うところが増えいてるが、無知だとそんなこともしらないんだろうな。 FBIに資料漏れて穴もあったけど対策されたって話だろ >>137
鍵配送問題がクリアできるシステムでしか本格採用できないから当然だが、
クローズドなネットワークは分からんけどオープンなネットワークで
ワンタイムパッド使ったシステムってのはめったに聞かないけどなぁ…
OTPの採用は増えてるけどOne Time PadじゃなくてOne Time Passwordだし。
量子暗号はまだ研究途上で実用レベルに至ってるかというと微妙じゃないか?
具体例教えて欲しい >>140
ネットバンキングで相次いで採用されているようだが‥ >>141
140で指摘済みだが、OTPはOTPでもOne Time PadじゃなくてOne Time Passwordじゃね?それ。
ワンタイムパッドは簡単にいえばメッセージ長(よりも長い)使い捨て共通鍵を使う暗号運用法の事。 ネット銀行のサイトでも「ワンタイムパスワード」になってるね
ワンタイムパッドが非実用的なのはコストがべらぼうに高いからだよね
予測できない乱数を多数生成するのは大変だし、通信量と同じ乱数列を事前に安全な手段で共有しないといけない
NSAと戦ってるのでもなければ、一般的な暗号化アルゴリズムの方が手軽で効果的 >>143
一応、銀行の奴はトークンの配布と言う形で鍵配送のコストはなんとかなってるな。
フラッシュ2GB位は仕込めるだろうし、暗号化する通信内容を限定すれば結構な期間保つと思う。
乱数の生成はアバランシェダイオードとか適当な物理乱数ベースでOKだが…サーバ側の容量がががが
それとワンタイムパッドとして運用するための端末をどう保護するかも面倒くさい。
ワンタイムパッド持ってきてもPC自体が現代暗号破られたら死ぬシステムだし、
トークンをLANに繋ぐとトークン自体がネットバンキング端末になるくらいじゃないとダメぽ。
スレチになってるからP2P掲示板に話を戻すと
「物理的に鍵配送し合える相手のいる匿名掲示板って何スかww」的な。どう使うんだ。 いや、そのスレとこっちは目的が別。こっちは完全匿名。そっちはなんちゃって匿名。 >>147
P2Pじゃないだろ。なんだこのバカは? P2Pオンリーで完全匿名掲示板ができると思ってる奴が馬鹿だよな >>149
「OnionちゃんねるはP2Pじゃないだろ」と書かないと理解できないのか? >>153
何かを得るには何かが犠牲になる。それが特徴というもの。
特徴は有利にもなるが不利にもなる、
強い匿名性は効率を激しく犠牲に求める。
この手の発想者は効率を犠牲にしたくないから壁にぶつかる。
匿名性が完璧に近くなれば掲示板としての機能すら怪しくなる
例えば文章の連続性がより破片となってばらばらになり、
経済学全集のような文面を投稿するのは不可能になる。
時系列の順序も正しく配置すれば匿名性は弱くなる。
匿名性を上げるなら討論の連続性やレスの接続性などを抽象化し不明確にするしかない。 メッセージの到達性をあるていど犠牲にすると,匿名性も効率も両立できる >>154
そうなると需要が著しく低下してしまう。
Outoposではその辺はある程度妥協してしまってる。>時系列
本当は投稿時間すらも隠ぺいしてしまった方が匿名性が高いに決まってる。 匿名性はいらん。匿名化ソフトに丸投げしたらいい。TORなど。 torを利用したとして、P2P型掲示板はどうやって作る? torもP2P型掲示板もどうでもいい。
重要なのはマネタイズの方法だ Torに匿名性を丸投げするとしてもDDoS耐性という面から見て何らかの負荷分散システムは必要。
中央に非依存的なシステムで、負荷を分散させようとすると自然に匿名性も付いてくる。 同期させた掲示板サイトを複数立てればいいだけなんじゃね? p2pファイル交換ソフトって嵐対策で誰も必要としていないファイルは消えていくようになってるけど、それって"高尚な目的"では使えないよね
重要性が知られていないファイルは保持できないから。そう考えると結局tor板のようなサイトこそが重要な役割を果すことになる 今の騒動でもp2pに流れるような話は全くなく、bbsmenuで色々な外部板を登録すればいいという流れ 色々思いついたんで書いとく。
同定可能性とIP匿名性の両立についてだけど、電子署名モドキじゃだめなん?
最初に適当な公開鍵暗号方式を選び、秘密鍵pと公開鍵qとを生成しておく。
暗号化関数をE、復号化関数をDとする。
今書き込みたいメッセージmがあって、発信するメッセージを
1)メッセージmを秘密鍵pで暗号化したものE(m,p)
2)公開鍵q
の2つの情報の組<E(m,p),q>によって定義する。これによって
・メッセージを受け取ったサーベントはm=D(E(m,p),q)によりmを再現出来る
・書き込み主がp,qの組を自主的に変えない限りは、qをキーとして誰にでも同定が出来る
・しかし(メッセージ自体に含まれてたり、伝搬方式に別な問題があったりしない限り)書き込み主のIPは分からない
同定が常に必要だというのでなければ、メッセージmとは別にダイジェストを適当なハッシュ関数H(m)で計算して
<m, E(H(m), p), q>の3つ組を伝搬させる等すると各ノードの負荷が減るかもです。
あとは荒らし対策として、ベイジアンフィルタが使えるんじゃね?とか。
つまり、典型的な荒らしが書き込む内容と典型的なユーザーが書き込む内容とは大分違うから
それに関する情報を必要に応じてサニタイズして共有しときゃ済むんじゃねって思う。
書き込みメッセージが送られて来た時に、そのメッセージを解析して荒らしっぽかったらrejectする感じ。
ただこれだけだとまっとうな内容の文章のコピーを大量に送りつけるタイプの荒らしは防げないから
他の方法と組み合わせる必要はあるけど。 こんな仕組みはどうだろう?
(1)IDに対してランクが割り当てられていて、ランクに応じた行動ができる。
例えばある板ではランク2以下はスレッドを建てられず、あるスレではランク0はレス出来ない
この辺の設定値は板やスレの作成者が作成時にパラメータとして与える
ここで言う所の「ID」は2chでの意味じゃなくてIdentifierって意味で、IPアドレスとは無関係ね。
(2)ランクの上げ下げはポイント制で、ID AからID Bへのポイント操作はAとBとのランク差に応じて重み付けされる。
例えばランク5のユーザーがランク2のユーザーに対しダメ出しした場合、それを取り返すには大きな手間がかかる
その代わり、ランク5のユーザーが大量の他のユーザーにダメ出しされた場合には容赦なくランクが下がりうる
(3)IDに対するランクの最大値はそのIDの見かけ上の古参度に依存する。
つまり、大量に捨てIDを作って高ランクを即日合成することは出来ない
又、あるコミュニティで古参だったとしても別なコミュニティでは新参として扱われる。
プロトコルとしてはこんな感じで、実装の面から行くと
(1)はIDからランクを計算できるなら簡単。その板のデータ保有者が書き込みを弾きゃ良い。
(2)は「AがBにCした」って情報にAが署名したデータをBに関して高々2000個程集めれば
統計的にはかなりの確率でほぼ正しい中央値が得られるから
新規に集めるにしてもそんなにでかいネットワーク負荷じゃない。
ここで言う所の「署名する」は「そいつ以外には作れない上に検証可能なデータを付与する」って意味で、
要は>>166みたいな方式を仮定してる。
(3)はあまりに書き込み頻度の低いIDは捨てられたものと仮定するなら
割と小さなテーブルで実現できる。
問題は、ランクの付け方をある程度標準化しないと
ある板のあるスレであるユーザーがある鯖ではランク1で別な鯖ではランク2になるなんてことが平気で起こる事だな。
計算方法を何通りか用意しといて、板やらスレやらの作成者がパラメータとして与える形になると思う。 unlinkabilityの意味での匿名性を確保しつつ、荒らしは排除する枠組み考えた。
つまり、投稿「された後」、2つの投稿の投稿主が等しいか否かを簡単に判定できないにも関わらず、
投稿「される時」にはその投稿と過去の任意の投稿の投稿主が等しいか否かを簡単に判定できる枠組み考えた。
但し等価性はIPアドレスベース。
まず最初に書き込みメッセージがIPアドレスと「内容」の組としてサーバントにやってくる。
ユーザーIDを、IPアドレスと今日の日付を結合して、少し時間がかかる変換をした物をハッシュした物により定義する。
例えば、結合した文字列を元に乱数の種を作って、1MB位の乱数列を生成してそれの接尾辞配列を計算する、とか。
書き込み内容を、「「ユーザーID」と「「内容」のハッシュ」をxor取って更にハッシュした物」と「内容」のタプルで定義する。
・unlinkability性
書き込み内容のうち「内容」じゃ無い方(以下メッセージID)からユーザーIDを推定することは困難。
ハッシュ関数の特性から、投稿AのユーザーIDと投稿BのユーザーIDが等しいことを確かめる為には
ユーザーIDを片っ端から生成して試すしか無い上に、ユーザーIDの生成に1つあたり0.01秒掛かると仮定すれば
32bit空間総嘗めで1年4ヶ月ちょい、つまり平均で8ヶ月程掛かる為。
・荒らしの排除特性
投稿元のIPアドレスが投稿時に分かっている場合、「内容」からメッセージIDが簡単に計算できる為
割と簡単に弾ける。
思うに、問題点は2つあって
・unlinkability性と荒らしの排除の為の計算時間はトレードオフの関係にある
・この枠組だとundeniabilityが保証されない
ガイシュツだったらごめんよ。 その「サーバント」って何者なの?
サーバントに対しては投稿元IPアドレス筒抜けってことだよね、これ。
誰か特定の人物がサーバントを運営するなら、そこが弱点になるし、そもそもP2P型じゃなくなる。
でも各自が立ち上げる形だと、荒らしの改造版サーバントは投稿元IPアドレス捏造してユーザーID生成するよね。 >>171
ごめんごめんサーバントじゃなくてサーベントだった。
P2Pネットワーク上に分散的掲示板を作って運用するケースを考えてて、
書き込むには
(1)メッセージIDをキーにしてDHT上にスレッドIDとメッセージの書き込みを要求する。
(2)要求の客体は乱数を生成し、乱数をキーにしてDHT上にスレッドIDとメッセージ、メッセージIDを書き込み、乱数を要求の主体に返す。
この時、接続時のIPアドレスからメッセージIDを再計算しておく。もし異なっていれば弾く。
(3)(2)の書き込みの客体は、まず最初に(1)の主体のIPアドレスとメッセージからメッセージIDを再計算して一致性をチェックし、
次に(1)の主体へメッセージIDを投げてtrueが返ってくる事を確認した上で書き込みを受理する。
ここで(1)の主体はメッセージIDが(3)の主体から飛んで来るので、自分が送信したメッセージIDと等しければtrueを返すものとする。
(4)(1)の主体が返ってきた乱数を分散DB上のスレッドに登録する事を要求する。
(5)要求の客体はDHT上で乱数からスレッドIDを引ける事を確認し、要求を受理する。
読み込むには
(a)分散DBからスレッドを読み込み、登録された乱数列を得る
(b)各乱数をキーにしてDHT上でメッセージを取得する
という感じ。
で、分散DBが改竄されず、かつ荒らしサーバントの数は十分に少ない(高々1000人に一人程度の)ものと仮定する。
まず(1)の主体が荒らせるかっていうと、これは(2)の主体が弾くから無理。
次に(2)の主体が荒らせるかっていうと、これは(3)の主体が次の事をチェックするから、運良く荒らしサーバントが協調的に動作しないかぎり無理。
・投稿元IPアドレスからメッセージIDを計算してそのメッセージIDの担当が(2)の主体と等しいかどうかを調べる
・投稿元IPアドレスとなっている場所へメッセージIDを投げてメッセージがそのアドレスから発信されたものかどうかを調べる
次に(3)の主体が荒らせるかっていうと、これは担当するキーに対応する値を改竄するくらいしかやることがないので無視。
次に(4)の主体が荒らせるかっていうと、これは(5)の主体が弾くから無理。登録されていない乱数は投稿できない。
次に(5)の主体だけど仮定より荒らせない。 あぁもう、どうにも1レスに1度はポカするなぁ(´・ω・`) >>172
乱数をDHTのキーに使う場合、自分の担当するメッセージを改竄できる気がする。
それに(3)の主体は、自分の担当になるような乱数生成すると(1)(2)も兼任できて、メッセージ偽造できそうな気がする。
でもこれ、一番狙われそうなのが分散DBの改竄だと思う。
あと、IPアドレスからユーザーIDを簡単に生成できるなら、特定のIPアドレスからの投稿をリストアップとかできる気がする。
何らかの理由でIPアドレス特定されたら過去の投稿まで全部特定されそう。 >>174
>乱数をDHTのキーに使う場合、自分の担当するメッセージを改竄できる気がする。
確かにそれは出来る。
しかし例えば1000ノードあたり1ノードの割合でそのような荒らしサーベントが含まれているとすれば
500回に1回くらいの割合で書き込みがバグる掲示板ということになる(ノードを2回中継するので)。
実用上十分だと私は思うのだけど。
>それに(3)の主体は、自分の担当になるような乱数生成すると(1)(2)も兼任できて、メッセージ偽造できそうな気がする。
ふーむ。
自分の担当になるような乱数を作ってメッセージと紐付けしたら、次に必要なのはそれを分散DB上にコミットする処理になる。
(1)の主体が上手いことメッセージと乱数を生成して(1)(2)(3)の主体が等しくなるようにしたとしよう。
この時(5)の主体が、つまり分散DB上のあるノードが、
(1)(2)(3)の各主体がそれぞれ異なる事をチェックすればメッセージ捏造は防げないかな。
勿論(3)の主体が行うチェックを(5)の主体もまた行う事は前提だけど。
>でもこれ、一番狙われそうなのが分散DBの改竄だと思う。
ネットワーク上に誤り検出率の高いRAIDのようなものを構築してその上に分散DBを作る事を仮定すれば、
分散DBに参加している荒らしのサーベントは単なるバースト誤りとみなせるから
荒らしのサーベントの含有率が十分少なければ分散DBの内側から改竄するのは不可能。
分散DBの外側からの改竄可能性はプロトコル次第、といった所だと思う。
>あと、IPアドレスからユーザーIDを簡単に生成できるなら、特定のIPアドレスからの投稿をリストアップとかできる気がする。
>何らかの理由でIPアドレス特定されたら過去の投稿まで全部特定されそう。
IPアドレスからユーザーIDを計算する、毎日更新されるオラクルをネットワーク上に構築するアルゴリズム誰か教えろください
私も後で考えようと思う。 荒らしが(5)の主体になれない仕組みが必要なんだよね。
そうしないと自分で偽造とか改竄したメッセージを自由に投下できちゃう。
あと、多数の相手に自分のIPアドレス通知する形だと、参加者のIPアドレス収集するスパイへの対策が必要になると思う。
過去の日付のIDを生成できない仕組みにしても、スパイにアドレス知られた日から先の投稿は全部特定されそう。 > 荒らしが(5)の主体になれない仕組みが必要なんだよね。
> そうしないと自分で偽造とか改竄したメッセージを自由に投下できちゃう。
うーむ
分散DBを実際にどう構築するかにも依ると思うんだけど、最終的にその分散DBからスレッドを読み込むことを考えると
攻撃手段としては
・偶然割り当てられたスレッドをまるっと改竄し、連投する
・割り当てられるようなスレッドIDのスレッドを生成しておいてあとで改竄・連投する
の二択になると思うんだよね。
これらの攻撃への対処法としては、
1つのスレッドを1つのノードが完全に担当するような事態にならないように分散DBを構築する事が考えられて、
RAID 5のようにデータを複数のノードに分割して保存し、
誤り訂正符号の応用で不適切なデータを検出・摘出する分散DBを作れれば良いんじゃないかなって思うんだけど。
つまり、単体のノードではどうにもならないように工夫して
連投については複数の担当ノードがそれぞれ再チェックする事で弾いて、
改竄についてはバースト誤りの検出によって分散DBネットワークからノード自体を弾く、とか。
でもそこまでやるならレスをDHTに置くよりはレスも分散DB上に直接置いたほうが改竄される危険性が減るから
改竄耐性の高い分散DBを本気で構築してその上に掲示板を乗っける方が簡単そうだっていう。
> あと、多数の相手に自分のIPアドレス通知する形だと、参加者のIPアドレス収集するスパイへの対策が必要になると思う。
> 過去の日付のIDを生成できない仕組みにしても、スパイにアドレス知られた日から先の投稿は全部特定されそう。
そこも大きな問題なんだよなぁ。
IPアドレスや日付なんかの誤魔化せない情報からユーザーIDを一意に計算できなきゃいけないし(連投荒らしを弾く為) ごめん、ふと思いついてちょっと調べたんだけど、このケースの場合は誤り訂正符号ってそんなに意味がない事が分かった。
> 誤り訂正符号の応用で不適切なデータを検出・摘出する分散DBを作れれば良いんじゃないかなって思うんだけど。
とは書いたけど、1スレッドあたり最大512KiBと仮定すると1024ノード参加しても1スレッド一人あたり4096bit保持する事になる。
何も考えず実装したら4096bitもの系列を改竄されうる事になるから、
この改竄を訂正するには4096bitが数ワードに収まるような超巨大なガロア体を使う符号化方式を使うことになって、
どう考えても実用的じゃない。
無理に誤り訂正符号に頼らずに、単純に4つとか8つとか複製を持った方が良さそう。 話飛ぶけど
ユーザーIDとして任意の乱数を使って、
「IPアドレスと日付を結合してハッシュとった奴」からユーザーIDを引けるようにするっていう素朴な方式は
どうなんだろう。
つまり、まず最初に書き込みたい人がDHTにIPアドレスと日付からなるキーに対し適当に決めたユーザーIDを登録して、
その日に書き込むたびにそのユーザーIDを用いる。
分散DBの側は、キーからユーザーIDが引けることを確認した上でその後の処理を行う。
といった具合。
もしユーザーIDに違う値を使おうとしたらDHTの情報と食い違うからreject出来て、連投も弾けて
割と良さそうに見えるんだけども。
自分のキーを自分が担当してユーザーID発行し放題、が出来ないように
キーを元に違うキーを作って(kademliaなら反転、chordなら半回転等)、その新しく作ったキーに対しても同じユーザーIDを登録する
とかその手の小技は必要になるだろうけど。 もう全体的に多重化して多数決でやったらいいんじゃないかって気がしてきた。
>>179
自分で任意のID決める形だと、他人のIDと同じ値を登録してなりすましができそうな気がする。
荒らし判定受けて道連れにするくらいしか攻撃法思いつかないけど。 >>180
> もう全体的に多重化して多数決でやったらいいんじゃないかって気がしてきた。
ほんとこれ。
疎なネットワークで多数決を取るやり方がちょっと思いつかないから
別方向からアプローチ掛けてるけども。
> 自分で任意のID決める形だと、他人のIDと同じ値を登録してなりすましができそうな気がする。
じゃあハッシュからユーザーIDへの変換とその逆変換を両方DHTに登録したらどうだろう。
つまり、任意のIDを決めれるんだけど、それを使えるのは最初の一人だけって形。 具体化しつつ色々考えてたら長くなりすぎたのでgistに書くことにしたよ
https://gist.github.com/pixie-grasper/35a43d0c15d9fe49814b
まぁ新しい所は荒らしの判定ににもっと計算量の小さい簡単な方法が使えるんじゃね?
って事くらいだけど。
簡単に言うと、
今まではユーザーIDとメッセージから同じメッセージIDが作れるか?って問題で解決してて
ちょっと重かったんだけど、ブルームフィルタの考え方を応用したら
もっと簡単に検出出来ることに思い至ったって話。 この形だと書き込みにユーザーIDとか記録しとく必要がないんだね。
匿名性がかなり高まったかも。 ひっそりと最終セクション追加したよ
>>183
> 匿名性がかなり高まったかも。
まぁわざわざIDをレスに含めるような実装をこの仕様の上に構築することも出来るし、
「匿名性」が何を意味しているのかにも依るんだけどね。
# だれか実装してくれないかなぁ >>184
理解できてなくて申し訳ないんですが、
究極的にはIPアドレスで連投確認してる、ということでしょうか? >>185
究極的にはそう。
連投の判定でユーザーIDを使ってて、
こいつはその時点のネットワーク上ではIPアドレスと一対一対応になっている。
ただし、
・ユーザーIDからIPアドレスのダイジェストを、又はその逆を計算出来ないように実装出来る
・ダイジェストからIPアドレス引くのもちょっと面倒
・そもそもユーザーIDやIPアドレスなんかの余計な情報が掲示板に残らない
といった理由から、問題ないんじゃね?って思ってる アホみたいに勢いあったのにぱったり止まるのってなんなのよ
どっかのサークルが打ち合わせして書き込んでたけど解散したとか? ■ このスレッドは過去ログ倉庫に格納されています