書き込みログのIP&リモホを見た目わからなくする方法を考えよう (202ﾚｽ)
上下前次1-新
33: 名無しさん＠お腹いっぱい。 2011/01/11(火)11:21 HOST:202.212.71.18 AAS
そもそもPIE内でMACアドレスが重複した事件とか忘れたわけじゃないよねみんな
34(5): 名無しさん＠お腹いっぱい。 2011/01/11(火)11:45 HOST:58.138.21.205 AAS
>>32
"＜適当な乱数とかめちゃくちゃな文字列＞。ここからリモホ→<>i118-16-76-46.s10.a027.ap.plala.or.jp<>
118.16.76.4<>←ここまでリモホ。＜適当な乱数とかめちゃくちゃな文字列＞"
という超長い文字列を作ってからハッシュかける。
文字列乱数は、毎回変えれば、母集団は無限大になるので、作表は不可能。
他方、復号化したあと「人間ならば」見りゃどこがIP・リモホなのかはわかる。
どうだ？ｗ
35(2): !omikuji!dama 株価【E】 2011/01/11(火)14:47 HOST:118.0.123.202 AAS
>>34
それならログに残る本文(の一部)を使えばいいと思うの。
36: 名無しさん＠お腹いっぱい。 2011/01/11(火)15:01 HOST:220.210.177.1 AAS
>>35
うむ。日付と時間含むだけでも相当散るよねｗ
37(2): 名無しさん＠お腹いっぱい。 2011/01/11(火)16:45 HOST:116.83.131.21 AAS
IPアドレスの母集団が少なくて、暗号化してあってもログが流出すると総当りで解読されるって言うなら、
まずIPアドレス鍵をランダムに作り、これでIPアドレス・ホスト名を暗号化する。
そのあと、別の公開鍵（固定）でIPアドレス鍵を暗号化して、暗号化IPアドレス・ホストと一緒に記録。
芋掘り時には、秘密鍵（おいちゃんと一部の削除人保有）で、IPアドレス鍵を復号化して、
これでIPアドレス・ホストを復号化。
IPアドレス鍵はランダム生成なので十分大きい母集団を持つ。これでどうよ
38(1): 名無しさん＠お腹いっぱい。 2011/01/11(火)17:03 HOST:58.138.31.54 AAS
>>37
> 芋掘り時には、秘密鍵（おいちゃんと一部の削除人保有）
結局、これって、現在のパスワード方式による芋掘りとリスクレベルはおんなじなんだよね。
暗号設計の問題じゃなくて、「体制」の問題と思う。
複数人で共通鍵を共有したら、クラッカーの攻撃で漏れるのは時間の問題。
39(1): 名無しさん＠お腹いっぱい。 2011/01/11(火)17:12 HOST:210.130.52.122 AAS
>>38
最初の趣旨が何であったか思い返しましょう。
今回の話は、芋掘りしていない書き込みログそのものが見られても大丈夫な様に、
という所がスタートです。
芋掘り作業のパス漏洩とかはまた別レベルの話だと思います。
40(1): 名無しさん＠お腹いっぱい。 2011/01/11(火)17:18 HOST:58.138.31.54 AAS
>>39
なるほど。
じゃあ、鍵ペア（ふつうなら、秘密鍵・公開鍵だが、今回は母集団問題があるので両方公開しない。鍵A・鍵B）
作って、
? ログ作成時に鍵Aで暗号化（したがって、鍵Aは鯖／CGI内においてある）
? IPアドレスやリモホ文字列だと母集団問題が如実に出るので、ヘッダーとか本文の最初の２行くらいをコミコミ
で暗号化
? 鍵Bは、おいちゃんと一部削除人がローカルにもつ。鯖にはおかない。
? 必要に応じて、鍵Bを使って復号化
こんなとこか？
41(1): 名無しさん＠お腹いっぱい。 2011/01/11(火)17:32 HOST:202.212.71.18 AAS
しかし生ログが漏れた時点で時間さえかければどうにでもなっちゃうよね。
42: 名無しさん＠お腹いっぱい。 2011/01/11(火)17:36 HOST:116.83.131.21 AAS
>>40
でもログの形式も判明しているのだし、書き込みの何バイトがログに入るのかも分かっている。
そうするとやっぱりIPアドレスとホストぐらいしか未知要素が入り込まないわけで、尚且つIPアドレスからホスト名は
大抵の場合求めることができる。すると、1つの書き込みの、ログのバリエーションはIPアドレスの数とだいたい同じ。
>>34みたいに、表に公開しないランダム固定長文字列をログに付けて暗号化したほうが良くない？
別に可変長でもいいけど十分長ければいいわけで、スクリプト上での扱いが固定長のほうが楽だから。
で、ログを表に公開するときもこのランダム文字列は公開しない（掘って復号した後に除く）。
43: 名無しさん＠お腹いっぱい。 2011/01/11(火)17:53 HOST:210.135.98.43 AAS
User-Agent、●、P2、の情報もあるよ。
まあ、ランダムデータを混ぜる方が安全ってのはあるね。
44: 名無しさん＠お腹いっぱい。 2011/01/11(火)17:55 HOST:210.135.98.43 AAS
>>41
暗号の安全性ってのは、現実的な時間で解読できなければ、
それは安全ってことなのよ。
45(2): 名無しさん＠お腹いっぱい。 2011/01/11(火)18:34 HOST:210.135.98.43 AAS
AA省
46: 名無しさん＠お腹いっぱい。 2011/01/11(火)18:37 HOST:210.135.98.43 AAS
暗号化の負荷ってどうなんだろう。
47(2): 名無しさん＠お腹いっぱい。 2011/01/11(火)18:41 HOST:116.83.131.21 AAS
>>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。
48: 名無しさん＠お腹いっぱい。 2011/01/11(火)18:41 HOST:210.135.98.43 AAS
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。
【方法その2】
IPアド公開掲示板へと生まれ変わる。
開示訴訟にさようなら。
49: 名無しさん＠お腹いっぱい。 2011/01/11(火)18:46 HOST:219.30.41.43 AAS
siberiaの時代到来ですね
>>34-35の組み合わせがいい予感
50: 名無しさん＠お腹いっぱい。 2011/01/11(火)18:57 HOST:210.135.98.43 AAS
>>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう？
とりあえず、
復号鍵を、サーバに、作業者の数だけ別個に暗号化して置いておき、
作業者は、自分用の「暗号化された復号鍵」の復号鍵を持つ、とすればいいのか。
権限抹消時は、その人用の「暗号化された復号鍵」を削除すると。
2段階あるだけに、面倒といえば面倒だし、安全といえば安全。
51(1): 名無しさん＠お腹いっぱい。 2011/01/11(火)19:11 HOST:210.135.98.43 AAS
>>34って独立した案なの？どれかの補足？
案なら、ハッシュの復号をどうするつもりかわからない。
IPアドレスだけじゃ、総当りで暗号化して暗号データの比較で
正解を見つけられるって懸念への補足なら、付加するのは
ランダムデータでいいんじゃないの。
52(1): 名無しさん＠お腹いっぱい。 2011/01/11(火)19:45 HOST:116.83.131.21 AAS
>>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵（これは非対称鍵）で暗号化して、一緒に記録。
>>51
普通「ハッシュ」っていうと不可逆なやつだよね。多分そこを誤解して>>34は書いてるんだと思う。
つまり、普通に非対称鍵で暗号化するにあたり、IPアドレスだけだと255^4しかなくてテーブルを生成するのが
容易だから、長い文字列を作ってからにすればいいじゃんってことだろ。
「適当な乱数とかめちゃくちゃな文字列」って書いてあるけど要するにランダムデータだろ。
上下前次1-新書関写板覧索設栞歴
あと 150 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.009s