P2P型の完全匿名掲示板はまだ出来ないの？その4
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2014/01/23(木) 23:14:13.01http://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/
0153デフォルトの名無しさん
2014/03/10(月) 02:25:35.970154デフォルトの名無しさん
2014/03/10(月) 02:33:01.05freenet, lair, perfect dark など匿名性が高いネットワークでは匿名ネット内での個人を特定できるようにしているね
新月は匿名性が前者と比べると無いようなものなのでスパム元のIPを特定できるし本気で荒らす人がいない
0155デフォルトの名無しさん
2014/03/10(月) 02:37:53.82＞匿名ネット内での個人を特定できるようにしているね
それは公開鍵の改変をチェックできる仕組みかな？
0156デフォルトの名無しさん
2014/03/10(月) 06:54:33.59海外のやつはたいていIDまではわかるんだよ。
ユーザーに対して一つ（もしくは複数）のIDが割り当てられ
書き込みに対して、どのIDが書き込んだかがわかる。
IDから個人を特定する方法を用意していないっていうのが
匿名という意味の本質。
IDまではわかるんで、もし仮にこのIDは俺のですと発表すれば
当然、ある書き込みが俺の書き込みかどうか調べることが出来る。
IDもなにもかもわからないようにしようとするからダメで
逆に言えばIDが分かることを認めてしまえば、中間者攻撃を
防止しながら匿名性を保てる。
もっとも俺は複数のIDを持てるわけで、
AというID ＝ 俺 と判明しても
BというID ＝ 俺？ かどうかはわからないんだけどね。
つまりAとBというIDを使い分けて、自作自演は可能ということ。
0157デフォルトの名無しさん
2014/03/10(月) 12:45:51.33署名すりゃいいじゃん。簡単なことを・・・
0158デフォルトの名無しさん
2014/03/10(月) 13:19:51.030159デフォルトの名無しさん
2014/03/10(月) 13:50:07.550160デフォルトの名無しさん
2014/03/10(月) 19:02:33.45すまんがその署名が正しいかどうかはどうやって判断する？結構悩ましいと思うけれども
0161デフォルトの名無しさん
2014/03/10(月) 19:05:54.12だめか？
0162デフォルトの名無しさん
2014/03/10(月) 19:14:53.09公開鍵の改変をチェックとか正しい署名とかは特定の個人やIPと対応させたいということなのかな
それは当然、匿名性を失なうことになる
0163デフォルトの名無しさん
2014/03/10(月) 19:20:38.20改変ものが増殖するのは仕方がないとして、オリジナルが消えない工夫はどうすればいい？
0164デフォルトの名無しさん
2014/03/10(月) 20:06:34.67それが、レベル低いっちゅうてんねん
0165デフォルトの名無しさん
2014/03/10(月) 20:08:27.35>>160=>>163
0166デフォルトの名無しさん
2014/03/10(月) 20:08:59.83防げるよ。低脳
0167デフォルトの名無しさん
2014/03/10(月) 21:33:07.77できるだけ広く拡散して、多くのノードで保持するしかないんじゃないかな。
掲示板のレスなんて容量小さいんだから、全ノードが全レス保持するくらいの勢いで。
0168646@3
2014/03/11(火) 03:25:15.56自分自身の同一性を証明するのは簡単だよ、極端なことを言えば本文に手でPGPかなんかの署名するだけ
>>152
いくつか誤解がある
書き込みの改変は、投稿後の改変と投稿時の改変の2つがある
投稿後の改変は追記型のネットワークDBにしておけば、データ保持者全員が結託して改変・消去しない限り問題ないし、
そのうえで投稿単位のデータについて名を値のハッシュにしておけば、名の一覧以外は結託しても消去しか出来ない状態にできる
別の署名をしたコピペを逐一ポストされると区別が難しくなるけど、署名を先行して送信するとかで回避できんこともない
投稿時の改変については受信者の公開鍵を正しく入手さえ出来れば、投稿時の改変はできなくなる
中間者は投稿文を読めないので破壊や消去しかできないから、単なる不達が起きるだけで済む
送信者としての公開鍵は自分から同一性を証明するために必要なだけだから、破棄したければ破棄すればいい
あと>>100のやり方だと実質IPが全部筒抜けだからあんま意味ねぇんだよな…
>>163
単純送信なら送信先の公開鍵で暗号化して送れば変造不能
情報取得なら、自分の使い捨て公開鍵と要求情報を最終相手先の公開鍵で暗号化して送れば変造不能
不達や消滅は起こりえるけど、変造それ自体は防げるよ
0169デフォルトの名無しさん
2014/03/11(火) 04:23:19.00ネットワークDB ですか‥‥当方には新しい概念だから少し調べてみる
後半
＞単純送信なら送信先の公開鍵で暗号化して送れば変造不能
その送信先が改変意図を持っていたら‥‥
前提として多数のノード間での単純なバケツリレー（あるいは投稿単位交換）を想定していた
投稿者の最初の送信先が悪意をもったクローラで、そこで改変して次のバケツに渡すとき、次のバケツでは改変を検出できないものかと
投稿者が秘密鍵で投稿単位(かそのハッシュ）を暗号化、それと一所にオリジナルのＩＤ＝公開鍵を渡すのであれば、バケツリレーの先でもチェックは可能かな
公開鍵すら変えると成りすましが成立しなくなるから。
>>100 は送信経路の撹乱と接続先でのIDの付与が目的だから、目的の送信先にIPが筒抜けてるのもやむを得ない。
目的の送信先が悪意を持ち、IPとID=公開鍵の紐付けを謀ったり出来る可能性が生まれるのは認める。それを他のバケツに記入改変して転送、とはいかないだろうが
となると、改変された投稿単位をどうするか、だが、悪意を含む可能性のある投稿単位消すか‥‥オリジナルは失われるな‥‥
0170デフォルトの名無しさん
2014/03/11(火) 04:50:40.87■暗号学的ハッシュ関数
元の文章からハッシュ値を求める関数
与えられたハッシュ値から元の文章の特定が困難
与えられたハッシュ値と同一のハッシュ値を持つ別の文章の作成が困難
同一のハッシュ値を持つ複数の文章の作成も困難(現在、MD5はこれを満たせない)
■共通鍵暗号
暗号化と平文化に使う鍵が同一、処理が早い
■公開鍵暗号または電子署名
暗号化と平文化に使う鍵が同一ではなく、暗号化鍵と平文化鍵のペアを使う
通常は処理が遅いので、ハッシュ値や使い捨ての共通鍵暗号の暗号鍵を対象文の代わりに使用することで高速化するが以下略
■公開鍵暗号
暗号化鍵から平文化鍵が求められない場合は、公開鍵暗号として使用できる
通常は、暗号化鍵を公開鍵として公開して、平文化鍵を秘密鍵として保持する
送信者は公開鍵を何らかの手段で入手・検証し、公開鍵で暗号化した文章を受信者に渡し、受信者が秘密鍵で平文化する
高速化のために実際は共通鍵暗号を使い以下略
■電子署名
平文化鍵から暗号化鍵が求められない場合は、電子署名として使用できる
通常は、平文化鍵を公開鍵として公開して、暗号化鍵を秘密鍵として保持する
送信者は秘密鍵で文章を暗号化し、受信者は何らかの手段で入手・検証した公開鍵でそれを平文化することで検証とする
なお電子署名の場合は暗号化の処理を署名と呼ぶ事が多い
高速化のために実際はハッシュ値を使い以下略
■認証局
公開鍵暗号や電子署名を補助するシステム
公開鍵に付随する何らかの情報について記した文章を認証局の電子署名秘密鍵で署名して配布する
利用者は何らかの手段で入手・検証した認証局の公開鍵を使い、証明書に記された内容が認証局に認められているかを検証できる
■証明書
何らかの内容を何らかの電子署名で署名したもの
通常は文章ではなく、何らかの署名とそれに付随する内容が記されている
検証する者にとって未知の認証局の署名しか行われていないものをオレオレ詐欺と同様にオレオレ証明書と呼ぶ
0171デフォルトの名無しさん
2014/03/11(火) 06:29:57.21> その送信先が改変意図を持っていたら‥‥
もちろん変造されうる、けれどそれは実質消去された(不達が起きた)上で同じ時刻に送信先が直接投稿したのと同じ
投稿文の識別番号に本文ハッシュを含めれば変造された投稿を元の投稿と誤認させる事もできず不達しか起こせない
最初から複数に送ればいいし、送信先から新着取得して握りつぶしていることを確認したらその送信先は捨てればいい
> 次のバケツでは改変を検出できないものか
投稿文を識別するID(識別番号、投稿者識別のIDでは無い)の一部にハッシュを使うだけで大丈夫、暗号化は不要
成り済ましの防止は最悪GnuPGとかで本文の中に署名を打てばいいだけだから伝送のレイヤで考える必要はない
0172デフォルトの名無しさん
2014/03/11(火) 08:54:46.050173デフォルトの名無しさん
2014/03/11(火) 09:06:11.470174デフォルトの名無しさん
2014/03/11(火) 09:12:05.00普通のハッシュテーブルと同じく連結リストの後ろに追加で良いんじゃね
その場合キー＝ハッシュだと不都合があるからサブキーも持たせといたほうがいいかも知れん
DHTのノードID(≒ハッシュ)が衝突したら>>173ほどじゃないけど残念な事になるだろうな
0175デフォルトの名無しさん
2014/03/11(火) 09:44:53.91スレッドを特定するのがUUIDで
UUID＋メッセージNo + MAC
を電子署名するでなんら問題ないと思うけど
0176デフォルトの名無しさん
2014/03/11(火) 09:46:52.910177デフォルトの名無しさん
2014/03/11(火) 09:49:33.03H( UUID + メッセージNo + UnixTime(書き込み時間) + PrivateKey(書き込み者のRSA秘密鍵 ≠SecretKey ) )
を署名すりゃ良い
0178デフォルトの名無しさん
2014/03/11(火) 09:50:21.07ちみの言っているのは、
Media Access Control
俺が言っているのは
Message Authentication Code
0179デフォルトの名無しさん
2014/03/11(火) 18:38:58.91どうだろ
0180175
2014/03/11(火) 19:53:07.48そういう仕組みは既にある
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 )
みたいな
0181デフォルトの名無しさん
2014/03/12(水) 00:30:16.40ID:sV0NfGMp＞電子署名
＞GnuPG
これは送信元がはっきりしており、「いつでも」送信元から公開鍵を入手できる場合に実力を出すと考えたいね
今は匿名下、または部分的に匿名な状況で、それでもバケツリレーの中で投稿単位の改変を検出して捨てることを考えている
＞投稿文の識別番号に本文ハッシュを含めれば変造された投稿を元の投稿と誤認させる事もできず
投稿文の識別番号も改変されたら結局オリジナルは失われる、
が、結局
＞投稿文の識別番号
＞最初から複数に送ればいい
まあそういうことか、「最初から複数」かな。
0182デフォルトの名無しさん
2014/03/12(水) 01:02:43.38ID:QIz6tpDE考えるべきは、ＩＤが正当なものは低コストで済み、ＩＤの乗っ取りを企てる者には馬鹿高いコストの仕組み。
そこの現実的な解が無い状態。
というか、匿名なんだからＩＤ無しでもおｋじゃね？
0183デフォルトの名無しさん
2014/03/12(水) 01:06:53.59ID:sV0NfGMpSPAM は専用ブラウザ機能で、でいいから弾きたいねえ、ID を使って
0184デフォルトの名無しさん
2014/03/12(水) 01:08:05.09ID:QIz6tpDEそれは普通にベイジアンフィルタでいいでそ
0185デフォルトの名無しさん
2014/03/12(水) 03:04:53.92ID:+FPX7RuE匿名かつ、可能な限り、IDを保持させることは可能だろ。
IPアドレス、接続名がそのままIDになったらバレてるがそれはIDではない。
0187デフォルトの名無しさん
2014/03/12(水) 03:14:57.47ID:+FPX7RuE荒らしもそれで弾けばいいんでは。
MACアドレスとは、個々のネットワーク機器を識別するための装置固有の物理アドレスです。
個々のネットワークアダプタに割り振られており、またこれは世界で一つしかないアドレスです。
同じマックアドレスのネットワーク機器は存在しません。IEEE（※参照1）により管理されています。
http://www2.chuo-u.ac.jp/com/support_qa/yougo/yougo3.htm
0188デフォルトの名無しさん
2014/03/12(水) 03:16:29.55ID:v3f2809c0189デフォルトの名無しさん
2014/03/12(水) 03:19:06.71ID:sV0NfGMp>>68 で指摘されている、つまり IP(+日付）のハッシュならレインボーテーブルで一発でIPを特定できる、と
なにかいい ID の生成方法はないものか？
0190デフォルトの名無しさん
2014/03/12(水) 03:19:18.07ID:+FPX7RuE0191デフォルトの名無しさん
2014/03/12(水) 03:21:52.01ID:sV0NfGMp実は MAC なんて自由に変えることができるのです
realtek RTL8019 とかはそうだし、Windows のデバドラでも変えられるように作っているものも多いし
0192デフォルトの名無しさん
2014/03/12(水) 03:22:49.22ID:sV0NfGMp送信側の申告は信用しない
0193デフォルトの名無しさん
2014/03/12(水) 03:25:31.24ID:+FPX7RuE日付+IP+MACくらいにしたら桁増えるが。
0194デフォルトの名無しさん
2014/03/12(水) 03:28:37.40ID:+FPX7RuE1割、MACかハッシュ偽装だったら9割は弾ける。
0195デフォルトの名無しさん
2014/03/12(水) 03:31:08.40ID:+FPX7RuE偽装できるから使えないんだったら、これを導入し続ける意味は無いはず。
0196デフォルトの名無しさん
2014/03/12(水) 03:35:36.76ID:v3f2809c0197デフォルトの名無しさん
2014/03/12(水) 03:46:54.86ID:Ep3X8sbh忍法帳システムが有効なのは、
サーバーに書き込みが行われて（つまりP2Pではない）
プロキシサーバー経由の書き込みを弾いている（つまりIPアドレスチェック）
からなんです。
特に「プロキシサーバーを弾く＝本当のIPアドレスを知ろうとしている」という機能は
IPアドレスをわからなくするという匿名と組み合わせるのは不可能なんです。
0198デフォルトの名無しさん
2014/03/12(水) 03:48:49.35ID:sV0NfGMpSPAM 屋さんだったら自動で MAC をコロコロ変えるプログラムを作ると思うよ‥‥
1割、というのが投稿数のことだったら、その見積もりは甘いと思う‥‥
忍法帳のクッキーはお上からの賜りものだろう？つまりサーバーの存在が前提だから P2P ではないと思うんだ
0199デフォルトの名無しさん
2014/03/12(水) 03:52:20.16ID:sV0NfGMpでも IPの偽装は困難だから ID の生成法としては有望なんです
ネットワークにソルトを浮遊させる、とかはどうでしょうかね
一列射撃問題、みたいなのはないかなあ
0200デフォルトの名無しさん
2014/03/12(水) 03:56:45.13ID:Ep3X8sbhプライベートIPアドレスのことだよね？
簡単だけど？
グローバルIPアドレスは、IDを生成する側はわからない。（ルータが持っていたりする）
サーバー側でならわかるから、２ちゃんねるはプロキシサーバーを禁止して上で
アクセス元IPアドレスを取得しているんだ。
でも、匿名＝プロ機西によるIPアドレス隠蔽を使うならば、
サーバー側でさえもIPアドレスは取得不可能になってしまう。
0201デフォルトの名無しさん
2014/03/12(水) 04:20:17.78ID:+FPX7RuE荒らしや違法な書き込みをするやつ、一般人のIPはばれてもいい、
データ保持してるやつのIPはばれては駄目というのは可能では。
初回書き込みで、ネットワーク上の少なくとも1台がIP見ながら忍法帳データのようなものを発行。
P2Pネットワークを監視し続ければ書き込みとIPが特定できたとしても、
過去レスに対してはIPがばれたり、発信しているPCがばれないようにはできるだろ?
0202デフォルトの名無しさん
2014/03/12(水) 04:28:58.43ID:Ep3X8sbhまず、プロキシによるIP匿名化を行うのであれば、
どのマシンもIPアドレスはわからない。
> 荒らしや違法な書き込みをするやつ、一般人のIPはばれてもいい、
コンピュータが書き込み内容を違法かどうかなんて判断できないので
つまり、全員のIPアドレスはばれるということになるね。
> データ保持してるやつのIPはばれては駄目というのは可能では。
データ保持するには、適当なダミーデータを保持すればいいだけ。
データを保持しているという偽装は簡単。
匿名化をやめるという前提でIPアドレスはわかるとしよう。
（その時点でスレタイの完全匿名掲示板は無理ということだが）
> 初回書き込みで、ネットワーク上の少なくとも1台がIP見ながら忍法帳データのようなものを発行。
その1台が嵐の仲間だったらどうする？
> 過去レスに対してはIPがばれたり、発信しているPCがばれないようにはできるだろ?
過去レスのIPアドレスがわからないってこと？ ならば過去レスを監視することは出来ないってことだね。
0203デフォルトの名無しさん
2014/03/12(水) 04:32:05.96ID:Ep3X8sbhそれと同じものを搭載すればいい。で
思考停止しないでくれ。
それとは別のものなんだから。
「P2P型の完全匿名掲示板」という条件があるために
既存の○○システムを取り入れるのは
不可能か困難になるんだからさ。
0204175
2014/03/12(水) 08:50:12.45ID:MYUfcuak＞これは送信元がはっきりしており、「いつでも」送信元から公開鍵を入手できる場合に実力を出すと考えたいね
＞今は匿名下、または部分的に匿名な状況で、それでもバケツリレーの中で投稿単位の改変を検出して捨てることを考えている
勘違いしてないかい？
公開鍵を入手する経路は、たとえそれが信頼を置けないノードであっても構わないんだよ
＞投稿文の識別番号も改変されたら結局オリジナルは失われる、
>>177 をよく読め
＞まあそういうことか、「最初から複数」かな。
これも勘違いしてないかい？
保証したいのは、ノードではなく、メッセージなんだけど？
>>182
うん、
投稿者が、唯一のその投稿内容を、その時に、その人だけが作成でき、証拠がのこれば、IDを保証する意味は無い
>>191
つか、俺の知っている限り、MACを変えられないOSを知らんがなｗ
SolarisだってBeOSだってMacOS Xだって、漢字talkだって変えられる>>199
>>199
＞ IPの偽装
容易だよ
0205デフォルトの名無しさん
2014/03/12(水) 09:32:51.17ID:BZHSr6bQ不完全伝送こそが完全な匿名である。
なんでエラーチェックとかするの？なんで中身を復帰したあとに
確実に戻せたかチェックできるの？
0206デフォルトの名無しさん
2014/03/12(水) 09:47:00.84ID:MYUfcuakそうでもないよ
0207646@3
2014/03/12(水) 11:14:31.97ID:AM85Ao7IDHTはノードIDとキーの2つがあって、どちらもハッシュ長でハッシュと絡めて生成する値なんだ
DHTではキーやノードIDに生の値を使うと破綻しやすくなり攻撃耐性下がるから、生値はあまり使えない
値のハッシュ値をキーにするような構成の場合値中の一部をサブキーとして持たせるとかってのが前半
後半はピュアなハッシュ値ノードIDのDHTの場合で、部分的に生IPをエンコードするとかの対策に繋がるネタ
>>177
最後の項が物凄く不穏なんだけど…署名ってことはその項は検算用に公開しちゃうんだよな？
>>181
掲示板上の投稿としての成り済ましに対しては、トリップと同じで同一性さえ示せばいいかなと
>>182
トリップ的に電子署名を使えば乗っ取りは簡単に防げる
匿名のために署名を乗り換えた時や新規参加時にどう信用を獲得するかは課題だけども…
>>187
自由に変更できるし実は結構被っている(不正なベンダIDや、古いMACの再利用が有るらしい)
ルータ境界を越えられないって制限があるからまず問題が表面化しないというだけ
0208デフォルトの名無しさん
2014/03/12(水) 11:15:18.61ID:AM85Ao7I現代暗号とかはわりとそういうところがあるんだが、または信用出来ない事を前提に設計するしかないね
>>194
それも当初は有効だと思うけれど、どーせそのうち不正改造版が出回るって想定した方がいい
>>199
>>91も最終手段的にそういうアイディアだし、ID生成サーバみたいなのを設置するのは有りだけど
常時それにしか頼れない仕組みではそのサーバの運営者が匿名性を保証しないと駄目なんよ…
上手く適用できる秘匿計算アルゴリズムがあればいいんだけど
>>200
ローカル計算に依存してたら只の自称でMACアドレスと同じで無意味じゃない？
IPアドレスを使う場合、外部(相手や認証局)から観測することでそれを保証するしか無いと思う
>>201
忍法帖云々とか関係なく、データ所有者を隠蔽するのは独立して実現できる
それと、その方法でIDを保証する場合「少なくともN台」ノードをエミュレーションすれば幾らでもIDを偽造できる
N台をネットワーク上のN%とかにすると、小数のクローラを設置するだけで全ID-IP対応をロギングできてしまう
0209デフォルトの名無しさん
2014/03/12(水) 11:23:32.16ID:MYUfcuak＞最後の項が物凄く不穏なんだけど…
大したリスクにはならんよ。それがMD5だとしても
0210デフォルトの名無しさん
2014/03/12(水) 12:24:00.60ID:sV0NfGMp＞公開鍵を入手する経路は、たとえそれが信頼を置けないノードであっても構わないんだよ
今は匿名性に比重を置いているのだから、公開鍵の入手先はどうするか、という問題はどうするか？
＞＞ IPの偽装
＞容易だよ
winny にプロキシをかまして偽装する、とかは聞いたことがないんだが。
ブラウザのIP偽装は簡単だが、プロキシ対応していないアプリがごにょごにょやるとき、そいつのグローバルIP を偽装する方法はあるのか？
0211デフォルトの名無しさん
2014/03/12(水) 12:44:42.78ID:MYUfcuakは〜あ・・・
＞今は匿名性に比重を置いているのだから、公開鍵の入手先はどうするか、という問題はどうするか？
別に持ってくる必要があんのか？
言っても分からんと思うけど・・・
電子署名 ≠ 署名
だかんね。
0212デフォルトの名無しさん
2014/03/12(水) 12:45:22.51ID:MYUfcuak＞そいつのグローバルIP を偽装する方法はあるのか？
いくらでもある
0213デフォルトの名無しさん
2014/03/12(水) 21:37:36.44ID:Ecp3hakT☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
☆電子署名には幾つかの手法があるが、PGPなどの自己署名する形式の署名は幾らでも作成でき複数の投稿を複数の署名で行うことにより自演できてしまう。
☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
0214デフォルトの名無しさん
2014/03/12(水) 22:06:28.16ID:Ep3X8sbhある書き込みに署名Aと書いており、
別の書き込みにも署名Aと書いている。
どちらも署名Aだから同一人物であることはわかる。
なぜなら赤の他人が署名Aを作ることは不可能だから
☆ID（署名）でできないこと
ある書き込みに署名Aと書いており、
別の書き込みにも署名Bと書いている。
この二つの書き込みをした人が別人かどうかはわからない。
なぜなら、一人が複数の署名を持つことは可能だから。
0215デフォルトの名無しさん
2014/03/12(水) 22:17:36.01ID:Ep3X8sbhに関して、２ちゃんねるとの違い。
2ちゃんねるでは、このスレでもそうだが、IDがでてる。
このIDによって、２ちゃんねるでは自作自演が難しくなっている。
たとえば、俺の今のIDとは違うIDにしたければ、
回線を複数持つか、一旦回線を切ってIPアドレスを変えないといけない。
この２ちゃんねるの仕組みと同じことをP2P型完全匿名掲示板でも出来るかといえば、できない。
なぜなら、２ちゃんねるはIDを発行するのは２ちゃんねるのサーバーであり、
P2P型完全匿名掲示板では、IDを発行するものがいない。
誰かがやるとしても、その「誰か」を自分自身がやることで好きなIDを作れる。
ID発行サーバーを作るならば、それはP2Pの完全匿名掲示板にはならない。
また、２ちゃんねるのIDは、IPアドレスを元に算出しているが、
P2P型完全匿名掲示板はIPアドレスが隠蔽（別の人のIPアドレスになる）される。
ID発行サーバーへはIPアドレスを隠蔽してはならないという制約をつけると、やっぱりP2P完全匿名掲示板にはならない。
だから２ちゃんねると同じ仕組はできず、自作自演を防ぐ効果は著しく低くなる。
0216デフォルトの名無しさん
2014/03/12(水) 22:23:05.29ID:Ep3X8sbh> winny にプロキシをかまして偽装する、とかは聞いたことがないんだが。
winny の「中継」という機能は「プロキシをかまして偽装する」行為そのもの
Winnyの匿名性というのは、プロキシ機能によるもの。
相手のグローバルIPがわかってしまえば、匿名性が無くなる
だから中継（＝プロキシ）によって匿名性を保つっていうのが
匿名技術の本質。Torも同じ仕組。
だから、相手のグローバルIPアドレスはわからない。
偽装以前に、相手のグローバルIPアドレスは、わからないんだよ。
だから２ちゃんねるは、相手のグローバルIPアドレスをなるべく確実に見つけるために
プロキシサーバーの利用を禁止して、匿名（IPを知らせない）での書き込みを禁止している。
0217デフォルトの名無しさん
2014/03/13(木) 00:07:33.64ID:g1sRHDdX時間同期型のトークンを無作為生成するだけで対処できると思うが
発行サーバーはいらない
問題はこのトークンが改変されない仕組みを作り出せるかどうかだけ
IP依存にする必要がなくなる
極めて低確率でトークンが同一になる可能性はあるがそれは仕方ない
おそらくトークンのジェネレータを不定期に変更する権限を開発者が持つ必要がある
そしてそれが実行されたか知られないようにしなければいけない
0218デフォルトの名無しさん
2014/03/13(木) 00:31:51.78ID:2uVCIEWCそれはID発行システムをブラックボックスにするという発想だと思うけど、そういうのは下策だと思う
匿名だと信じていたら実は解析されていた、なんてことになると今の2ちゃんと同じ状況になる
0219デフォルトの名無しさん
2014/03/13(木) 01:12:01.54ID:+lIKaSU4たとえば新しく生成されて自分が見たことのない秘密鍵で署名された、
署名チェインのないレスを送ってきたノードへの接続を制限するとか。
他人のレスに署名チェインを追加して転送する回数が増えるにつれ信用を上げていく感じ。
0220デフォルトの名無しさん
2014/03/13(木) 01:42:12.97ID:2uVCIEWCそこをどうするかということを模索することになると思うけど、ベストな方法は無いと思う
複数の方法を実装できれば荒らされたときに慌てずに済むんじゃないかな
0221デフォルトの名無しさん
2014/03/13(木) 03:54:12.43ID:g1sRHDdX解析される可能性があるのはやむを得ない
匿名性を守ろうとすればどうしてもそのリスクは受け入れざるを得なくなる
解析されるかもしれないから却下ではなく
解析がとてつもなく厳しいものになればいい
あるいは解析されたとしてもお手上げになるように
具体的にはP2Pコネクションを行っているプロセスA
トークン管理をしているプロセスB
そして第三者のプロセスC
A-B,B-C,C-Aでプロセス間通信で監視しあい、誤った暗号ブロック（クラックされた可能性がある）が送られた場合は即時停止
リポートを流し開発者に伝える
0222デフォルトの名無しさん
2014/03/13(木) 05:04:45.81ID:obdyzpxjどこが整理やねんｗ
なんもわかっとらんし
＞☆レスの改竄を防ぐためには電子署名が必要(一番確実性がある)。
うんにゃ
MICでもMACでも電子署名でもハッシュだけでも可能
＞☆電子署名には幾つかの手法があるが、
＞PGPなどの自己署名する形式の署名は幾らでも作成でき
＞複数の投稿を複数の署名で行うことにより自演できてしまう。
CA建てるならP2Pじゃなくなるね。
＞☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
PKIじゃなくてもOK
＞☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
うんにゃ
ネットワークに参加しているメンバーのIPが特定されても実現は可能だよ
＞☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
そうなん？？？
改ざんが検出されたものは転送せずに破棄すりゃいいじゃん
正しいデータを読み出せる必要は無い
0223デフォルトの名無しさん
2014/03/13(木) 05:08:30.64ID:obdyzpxj>>177
0224デフォルトの名無しさん
2014/03/13(木) 06:03:19.06ID:j0o71mYX＞うんにゃ
＞MICでもMACでも電子署名でもハッシュだけでも可能
確かにそうです
至らない点がありました
＞＞☆電子署名には幾つかの手法があるが、
＞＞PGPなどの自己署名する形式の署名は幾らでも作成でき
＞＞複数の投稿を複数の署名で行うことにより自演できてしまう。
＞CA建てるならP2Pじゃなくなるね。
P2P上で、あくまで自動化された鍵の生成と認証をするのみにとどまります。
＞＞☆鍵の証明書を発行するべくP2Pネットワークで成り立つPKIが必要になる。
＞PKIじゃなくてもOK
何かありますか？
＞＞☆匿名性も考慮に入れる。IPアドレスが特定されるべきではない。
＞うんにゃ
＞ネットワークに参加しているメンバーのIPが特定されても実現は可能だよ
書き込んだ人のIPアドレスの話をしています。
＞＞☆改竄を防ぐのはもとより、いやしくも改竄が発生した場合に正しいデータを読み出せなければならない。
＞そうなん？？？
＞改ざんが検出されたものは転送せずに破棄すりゃいいじゃん
＞正しいデータを読み出せる必要は無い
可用性は出来るだけ上げるべきではありませんか。分散保存される場合は改竄を破棄するとかなりの打撃になります。
0225デフォルトの名無しさん
2014/03/13(木) 10:58:42.23ID:obdyzpxj何を認証するのかが不明瞭なんだよ
話の流れでは、メッセージを認証しようとしているけど、
ここではIDを認証しようとしている
ちぐはぐ
＞何かありますか？
無理にCAを建てることもあるまい
＞書き込んだ人のIPアドレスの話をしています。
今でも十分書き込んだ人のIPアドレスかどうか分からなくなっているだろ？
なぜ、それでも、分かるんだ？
・転送した記録が各ノードに残る
・要求内容とIPアドレスに紐付けがされる
・転送内容をノードが理解できてる
・フルキャッシュを持っているノードが特定できる
だろ。
あとは良く考えろ
＞可用性は出来るだけ上げるべきではありませんか。分散保存される場合は改竄を破棄するとかなりの打撃になります。
ナンセンス
改ざんされたデータは、ゴミ以外の何者でもないので、即時破棄の方が可用性は向上する
0226デフォルトの名無しさん
2014/03/13(木) 11:01:09.71ID:4kUzoZI/新しく登場した署名は暫く信用しないってだけで十分だと思うというか、
そこにノードの接続性まで絡めるのはなんか違う気がしてならない
ノードの信用(及び署名+公開(暗号化)鍵)と
投稿者の信用(及び署名+公開(暗号化)鍵)は
分けて考えたほうが良くないか？
>>221
いずれ解析される前提で考えないと不味いって話でしょ
解析されるまでの間は有効に機能するとしても、
解析された後に全滅するしか無いシステムじゃ不味い
>>223>>177
ちょっと式の意味をもうちょい詳しく頼む
秘密鍵(SecretKey)≠SecretKeyとかPrivateKey関数の意味とかよく分からん
0227デフォルトの名無しさん
2014/03/13(木) 11:14:00.71ID:obdyzpxj>>177で話されていた内容は、メッセージのIDをどう作るか
Secret ： 秘密情報
SecretKey ： 共通鍵方式における秘密鍵
PublicKey ： 公開鍵方式における公開鍵
PrivateKey ： 公開鍵方式における秘密鍵
秘密情報(Secret)やユニークなID と メッセージを関係付けるのは、良い考えかただが、
公開鍵の持ち主との関係が希薄になる。
重要なのは、
○そのとき
○そのスレで
○そのメッセージが
○その公開鍵ペアを持っている人
のみ、IDを作れられなければならない
H( ) はハッシュ関数の意味
0228デフォルトの名無しさん
2014/03/13(木) 11:27:26.12ID:4kUzoZI/>>213
> ☆1
署名が要るのは成り済まし防止(同一性の証明)の時
> ☆2
実装や認証のツリーが違うだけで仕組みは大差ない
> ☆3
署名の複数所持を認めるなら不要
>>224
> 書き込んだ人のIPアドレスの話
ネットワーク構成レイヤでの参加者IPアドレスは隠したら通信できないので不可能
参加者IPアドレスの中で投稿やデータ交換したIPアドレスを隠すのはオニオンルーティングなどで可能
投稿者IDないし署名の複数所持を認めずその為にIPアドレスを使う場合、上手く設計しないと匿名性が薄れる
> 改竄を破棄するとかなりの打撃
改竄された領域は通常本来のデータを意味しないので、そこから意味有るデータを読み取ろうとしても無駄
改竄に参加していないノードから情報を回復した方が良いし、それにはできるだけ早く破棄したほうが良い
0229デフォルトの名無しさん
2014/03/13(木) 11:51:48.62ID:4kUzoZI/キーを>>175の生値にするとDHTが機能不全を起こすし、>>177だと結局ハッシュが衝突しうるよね？
あと、そのキーが正しいもので有ることを検証するためには(DoS的スパム(≠投稿スパム)の排除)、
ハッシュ関数の入力をそのデータ内で公開する必要があるから検証してる場合には使えない気が
ストレージとしてのDHTは恣意的なキーを使うと容易に死ぬし、
ハッシュだから念のために衝突対策(例：リスト)が必要になる
衝突時の区別に使うサブキーは…ぶっちゃけ何でもいいけど
なんだけど、DHTに格納するキーとしてはその値を署名云々とか何の意味があるのかよく分からんのよ
0230461
2014/03/13(木) 13:19:29.74ID:j0o71mYX> 改竄に参加していないノードから情報を回復した方が良い
すみません、そういう意味で言っていました。
>>229
値が変動すればキーも変わらなければならないのですが、たまに同じハッシュが生成されてしまう場合があるのです。
DHTではデータが多数のノードに分散されて配置される。
データを担当するノードはそのデータに手を出すこともできる。
それを検出する機構が必要になるってことですね。
0231デフォルトの名無しさん
2014/03/13(木) 13:23:59.80ID:obdyzpxjコリジョンが発生するのは、同一スレッド内だけだから、
死ぬまで使ってもコリジョンしないよ。
0232デフォルトの名無しさん
2014/03/13(木) 13:35:11.61ID:meCkOYxs同時性は大事と思うが。
あるPCには見えるものが、離れてるPCでは見えないとか。
0233デフォルトの名無しさん
2014/03/13(木) 13:40:15.66ID:obdyzpxjユーザ側の「勝手な」要望としては、そうだろうね。
ただ、P2Pの性質としては、同一スレッドを参照書き込みしている人達にはより早く
そうでない人にはそれなりに、
ってなっちまうと予測
スレを収集するフェーズで、よりプロバイダとの距離が近い者ほど早く
ってな実装にすると、パフォーマンスと要望が満たせる
んが、同時性は明らかに損なわれる
ところで、読んでさえいない2chのスレッドに同時性を求めるのかい？
0234デフォルトの名無しさん
2014/03/13(木) 14:15:32.22ID:meCkOYxs0235デフォルトの名無しさん
2014/03/13(木) 16:17:21.14ID:4kUzoZI/それはつまりスレッドごとにDHTネットワークを構築するってこと？
それならコリジョンはまず起きないだろうけど…
0236デフォルトの名無しさん
2014/03/13(木) 17:28:42.04ID:obdyzpxjスレッドのメッセージIDの話をしてんだから、それで問題ないだろ。
そもそも、だ、
自分に関係のないスレッドのメッセージを一意に特定する意味があんのか？
欲しい情報は、
このスレッドの、このメッセージ
じゃね？
スレッド一覧は、ShareやWinnyのようにハッシュで管理すりゃいいだろうし、
分散ハッシュテーブルでも構わんと思うよ。
その中のメッセージがシステムWideで一意のハッシュ値である必要性がどこにある？
0237デフォルトの名無しさん
2014/03/13(木) 17:37:41.50ID:obdyzpxj無茶苦茶起こると思うよ
実装次第だけど、俺の頭ん中の実装だと、過疎スレは非常にレスポンスが悪い
逆によい傾向じゃあねぇか
0238デフォルトの名無しさん
2014/03/13(木) 18:08:37.29ID:4kUzoZI/DHTネットワークのモデルって単層のキーバリューストアだから、
それをスレッド数だけ多重化するとは思わなかったんだよ・・・
DHTネットワークを多重に構成する場合のコストって何十と稼働させても平気だっけ？
0239デフォルトの名無しさん
2014/03/13(木) 18:24:12.63ID:obdyzpxjなんか問題ある？
「多重にうんぬん」の時点で分かってない気がするのは俺だけかな？
多重に云々 が起きる事態なら、それを捨て置けば良いんでなくて？
そうすれば、人気のあるハッシュがより拡散するんでなくて？
どうしてもレアなものをゲットしたいのなら、そのノードが頑張るんじゃないの？
0240デフォルトの名無しさん
2014/03/13(木) 18:28:50.44ID:V8jBRZJrお前が一番わかってないから他の人の話と合わないんだろ
0241デフォルトの名無しさん
2014/03/13(木) 18:38:41.46ID:4kUzoZI/んん？スレッド単位でDHTに格納してく場合のスレッド内でのメッセージIDの話で、
メッセージ単位でDHTに格納してく場合のメッセージIDの話ではないって事？
読み返したら>>236でDHT前提にしない事も考えてるみたいだけど、
>>229でも書いたように元はDHT格納時の衝突の話だから、
衝突を考慮するID振り当て対象はDHT格納単位の筈なんだが…
0242デフォルトの名無しさん
2014/03/13(木) 18:48:36.48ID:obdyzpxjハッシュに秘密鍵を入れる理由が理解できないお前がアフォなんだとよくわかるレスだわ。
どうぞ、セキュ板だろうと、ネットワーク板だろうと、拡散してくださいwww
0243デフォルトの名無しさん
2014/03/13(木) 19:03:18.92ID:obdyzpxjなぜにスレッド単位にしない？
UUID+メッセージIDで充分だろ？
0244デフォルトの名無しさん
2014/03/13(木) 19:03:43.57ID:j0o71mYX0245デフォルトの名無しさん
2014/03/13(木) 19:33:48.71ID:obdyzpxj0246デフォルトの名無しさん
2014/03/13(木) 20:25:08.49ID:aSwmjniWこれでそんなことをする意味がないことがわかりるだろう
0248デフォルトの名無しさん
2014/03/13(木) 21:35:09.78ID:meCkOYxs追記とリードのみ対応。
各記録ブロックは5-10台程度で保持。
さらにおまけでP2P上にビットコイン採掘を同時に行い電気代回収。
0249デフォルトの名無しさん
2014/03/13(木) 21:58:19.12ID:Slx1TmTlPKI は論外。アングラ世界で「信用の輪」を広げようったって駄目。原理的に無理。
「とりあえず○○さんを名乗る人からこの書き込みを受け付けました。責任は持てません」ということを多数決で事実確認するのが関の山。
どうせ保障も責任なんて誰も何も取りようがない。
降水確率よろしく、「この書き込みが○○さんである信頼性は××％です。なお、東アジアのノードには改竄警報が出ています」ってくらいでいいんじゃない？
クソみたいにアバウトにやった方がいい気がしてきた。
0250デフォルトの名無しさん
2014/03/13(木) 22:01:40.58ID:9sS6Jz5v（その100人は、すべて○○さんが作ったアカウントです）
匿名である以上、一人が複数の人を演じることは防ぎようがないからね。
0251デフォルトの名無しさん
2014/03/13(木) 22:15:12.44ID:aSwmjniW0252デフォルトの名無しさん
2014/03/13(木) 22:36:49.30ID:Slx1TmTlそのノリでいいんじゃない？
第三者に拠り所を敢えて求めないならそのノリしか無いと思う。
ていうか、マロユキの「嘘を嘘と…」という言葉は結構名言だわ。
あいつ大嫌いだけど、匿名性を求めるなら何らかの妥協は必要だ。
「完全」「匿名」「IDの一貫性」のどこかで何かをある程度で捨てなきゃならんはずなんだが…。
何をどの程度、となるとスレで合意が得られるものでもあるまい。匿名性の限界は色んな意味でそこにある。
>>251
ねーよ。てめーこそ論外だ。
保証人のいない PKI なんか存在しない。逆に、保証人がいるからこその PKI だ。何のための公開鍵「基盤」なんだよ？
多数決制は主にアングラ面でしか発達してない。
政治的にせよ、経済的にせよ、信頼や保証を得られるものを拠り所にするのは変わらん。
久々の頭悪杉。
あ、「事実確認」は「事実認定」のミスね。意味分かる？
■ このスレッドは過去ログ倉庫に格納されています