X



トップページ開発室
202コメント86KB
書き込みログのIP&リモホを見た目わからなくする方法を考えよう
0001偽FOX ★NGNG
サーバ乗っ取られて書き込みログを見られてもokにしよう。
IPアドレスとかリモホり部分っすね、

これが出来たら、乗っ取られたっていいジャン! になる。

誰か方法考えてちょ
0003偽FOX ★NGNG
可逆的なのよろしくー
0007未承諾広告※ ◆bbq.muteQGCV NGNG
付与するキーを、別鯖から取得して暗号化。
復号時にも同じく別鯖から取得して復号化。

・・・かなぁ。。。
0010名無しさん@お腹いっぱい。NGNG
復号鍵は、どこのサーバ内にも保存せず、作業時に自分のPCから毎回送信するとか。
あるいは復号作業を自分のPCでやるとか。
0011名無しさん@お腹いっぱい。NGNG
復号鍵をおいちゃんのPCにだけ置いておくほうがいいと思う
でも鯖に侵入されたらログをみてIPやリモホは分からなくても、ログを消去される可能性が残るということをお忘れなく。
0012◆ANGLERlqvM NGNG
>>11
削除要請で裁判所からのIP開示に対応しないと駄目だから
個人のPCに復号鍵を置くのは、ちょっと。。
0013名無しさん@お腹いっぱい。NGNG
>>12
じゃぁ芋掘り出来る人全員に鍵持を持ってもらうってのはどうなのよ。
実際に芋堀りできる人がどれくらいいるのか分からないからなんとも言えないけど。
・・・この場合だと、「ある人から芋掘り権を剥奪する」という操作が不可能だな。鍵は全員同一のものになってしまうから。

あるいは、復号化鍵はqb7あたりにおいておいて、qb7の窓口から芋掘り。
qb7にはいられたら終わりだけど、qb7は堅牢だという前提で・・・。
  芋掘り人
指示↓ ↑芋
   qb7鯖 ←復号処理
指示↓ ↑暗号化芋
  掲示板鯖
0014名無しさん@お腹いっぱい。NGNG
削除要請や裁判所がどう関係するのかわからない。
作業するのは1人だけじゃないって意味?
これは、IPアド閲覧権限者で復号鍵を共有することになるね。
この点は従来のアクセスパスワードを共有しているのと同じ。

まあ、ウェブサーバと個人PC、どちらが安全性が高いかっていうと、
色々な考え方ができるんだろうけども。
ただこれもパスワードのメモを保存するのと同じか。
0015名無しさん@お腹いっぱい。NGNG
確かに剥奪時の問題はあるんだけど、暗号化ログを取得するにも
何らかのアクセスパスワードがかかるはずだから、そこで制御するとか、
1年とか一定期間ごとに鍵を変えるとか。

ログ保存も永遠じゃないしな。
0018名無しさん@お腹いっぱい。NGNG
>>16
うん。
作業者が複数って端的に言えば済むところを、削除要請や裁判所を
持ち出すのは何か別の意味があるのかなと思っただけ。
0019◆ANGLERlqvM NGNG
>>18
書き方が悪かったかな。。ごめん。
まぁ、そういう事なんで複数の人が使う事を前提に考えなきゃ駄目なんだよ。
複数といっても、そんなに多くは無いと思う。
0022名無しさん@お腹いっぱい。NGNG
別サーバーで、登録したMACアドレスのみアクセスできるようにするとかはダメ?
0023◆ANGLERlqvM NGNG
MACアドレスは参照しない方がいい。
MACアドレスは絶対にユニークな値ではないよ。
書きかえられるし。
0025名無しさん@お腹いっぱい。NGNG
MACアドレスの書き換えは可能だけどほぼ生IPになる

proxy使用 -> proxy鯖のMACアドレスに置き換わる
ソケット串 -> proxy同様

やらないよりはやった方がマシなレベル
0028名無しさん@お腹いっぱい。NGNG
>>9
> 公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

あらゆる意味でダメだろw

・ハックされて、秘密鍵側をとられたらおしまい。

・それ以前の問題として、IPアドレスなんて有限通り(32ビット)しかないんだし、しかも、ほとんど
 日本発信のアドレスレンジはもっと狭い → カギ公開してたらブルートフォースで作表されてしまう。
0029名無しさん@お腹いっぱい。NGNG
よく考えたら、これって公開鍵暗号方式だけの問題じゃないね。

(可逆・不可逆を問わず)ハッシュ関数的なルーチン(ファンクション)かましたって、
いずれ作表されてしまう。

関数(鍵)を変えていく、としても、「そのログに対応した関数(鍵)」は一意に決まって
しまうので、逃げようがない(時間かければいずれ解かれる)。

つうことで

  サーバ乗っ取られて書き込みログを見られてもokにしよう。
  IPアドレスとかリモホり部分っすね

これってそもそも不可能じゃね
0031名無しさん@お腹いっぱい。NGNG
いや「絶対」とかそういう次元の問題じゃなくて

・復号側→複数の人がIP復号化作業をする必要性があるらしいので(芋掘り、裁判所対応)
 結局、パスワードで作業管理している現状とリスクレベルあんまかわらない。

・せめてログ上、IPアドレス(リモホ文字列)だけでも暗号化できないか→母集団が少なすぎて
 ブルートフォースで作表できてしまう。表さえできれば、逆引きは一瞬w


詰んだ
0032名無しさん@お腹いっぱい。NGNG
そもそも平文の母集団が少ないのは前提であって、それに対してイカに復号化を難しくするかってとこだろ


いやここでv6アドレスを使えば…
0034名無しさん@お腹いっぱい。NGNG
>>32

"<適当な乱数とかめちゃくちゃな文字列>。ここからリモホ→<>i118-16-76-46.s10.a027.ap.plala.or.jp<>
118.16.76.4<>←ここまでリモホ。<適当な乱数とかめちゃくちゃな文字列>"

という超長い文字列を作ってからハッシュかける。

文字列乱数は、毎回変えれば、母集団は無限大になるので、作表は不可能。
他方、復号化したあと「人間ならば」見りゃどこがIP・リモホなのかはわかる。
どうだ?w
0037名無しさん@お腹いっぱい。NGNG
IPアドレスの母集団が少なくて、暗号化してあってもログが流出すると総当りで解読されるって言うなら、
まずIPアドレス鍵をランダムに作り、これでIPアドレス・ホスト名を暗号化する。
そのあと、別の公開鍵(固定)でIPアドレス鍵を暗号化して、暗号化IPアドレス・ホストと一緒に記録。

芋掘り時には、秘密鍵(おいちゃんと一部の削除人保有)で、IPアドレス鍵を復号化して、
これでIPアドレス・ホストを復号化。
IPアドレス鍵はランダム生成なので十分大きい母集団を持つ。これでどうよ
0038名無しさん@お腹いっぱい。NGNG
>>37
> 芋掘り時には、秘密鍵(おいちゃんと一部の削除人保有)

結局、これって、現在のパスワード方式による芋掘りとリスクレベルはおんなじなんだよね。
暗号設計の問題じゃなくて、「体制」の問題と思う。
複数人で共通鍵を共有したら、クラッカーの攻撃で漏れるのは時間の問題。
0039名無しさん@お腹いっぱい。NGNG
>>38
最初の趣旨が何であったか思い返しましょう。

今回の話は、芋掘りしていない書き込みログそのものが見られても大丈夫な様に、
という所がスタートです。

芋掘り作業のパス漏洩とかはまた別レベルの話だと思います。
0040名無しさん@お腹いっぱい。NGNG
>>39
なるほど。

じゃあ、鍵ペア(ふつうなら、秘密鍵・公開鍵だが、今回は母集団問題があるので両方公開しない。鍵A・鍵B)
作って、

@ ログ作成時に鍵Aで暗号化(したがって、鍵Aは鯖/CGI内においてある)
A IPアドレスやリモホ文字列だと母集団問題が如実に出るので、ヘッダーとか本文の最初の2行くらいをコミコミ
  で暗号化
B 鍵Bは、おいちゃんと一部削除人がローカルにもつ。鯖にはおかない。
C 必要に応じて、鍵Bを使って復号化

こんなとこか?
0042名無しさん@お腹いっぱい。NGNG
>>40
でもログの形式も判明しているのだし、書き込みの何バイトがログに入るのかも分かっている。
そうするとやっぱりIPアドレスとホストぐらいしか未知要素が入り込まないわけで、尚且つIPアドレスからホスト名は
大抵の場合求めることができる。すると、1つの書き込みの、ログのバリエーションはIPアドレスの数とだいたい同じ。

>>34みたいに、表に公開しないランダム固定長文字列をログに付けて暗号化したほうが良くない?
別に可変長でもいいけど十分長ければいいわけで、スクリプト上での扱いが固定長のほうが楽だから。
で、ログを表に公開するときもこのランダム文字列は公開しない(掘って復号した後に除く)。
0045名無しさん@お腹いっぱい。NGNG
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

【方法その1】
非対称鍵で暗号化する。

■ 復号鍵をサーバに置く場合
・作業スクリプトで、作業者を認証管理する。
・復号鍵を置いているサーバや作業スクリプトの安全性が頼り。
└> サーバの侵入や漏洩を前提にした暗号化に対して、復号作業サーバの安全性は前提にできるかどうか。

■ 復号鍵を作業者が各自で保有する場合
・作業スクリプトで、作業者を認証管理した上で、復号鍵を作業スクリプトに送信する。
・掲示板サーバや復号作業サーバで侵入や漏洩が起きても、暗号は安全。
・同じ復号鍵を、作業者全員が保有する。
・各作業者の情報管理が頼り。
└> ウェブサーバと個人PC、どちらが安全か。
・権限抹消された作業者から復号鍵を取りあげることができない。
├> 定期的な鍵の変更が必要か。
└> 作業スクリプトの認証で足りるか。
0047名無しさん@お腹いっぱい。NGNG
>>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。
0048名無しさん@お腹いっぱい。NGNG
【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

【方法その2】
IPアド公開掲示板へと生まれ変わる。
開示訴訟にさようなら。
0050名無しさん@お腹いっぱい。NGNG
>>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう?

とりあえず、
復号鍵を、サーバに、作業者の数だけ別個に暗号化して置いておき、
作業者は、自分用の「暗号化された復号鍵」の復号鍵を持つ、とすればいいのか。
権限抹消時は、その人用の「暗号化された復号鍵」を削除すると。
2段階あるだけに、面倒といえば面倒だし、安全といえば安全。
0051名無しさん@お腹いっぱい。NGNG
>>34って独立した案なの?どれかの補足?

案なら、ハッシュの復号をどうするつもりかわからない。

IPアドレスだけじゃ、総当りで暗号化して暗号データの比較で
正解を見つけられるって懸念への補足なら、付加するのは
ランダムデータでいいんじゃないの。
0052名無しさん@お腹いっぱい。NGNG
>>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵(これは非対称鍵)で暗号化して、一緒に記録。

>>51
普通「ハッシュ」っていうと不可逆なやつだよね。多分そこを誤解して>>34は書いてるんだと思う。

つまり、普通に非対称鍵で暗号化するにあたり、IPアドレスだけだと255^4しかなくてテーブルを生成するのが
容易だから、長い文字列を作ってからにすればいいじゃんってことだろ。
「適当な乱数とかめちゃくちゃな文字列」って書いてあるけど要するにランダムデータだろ。
0053名無しさん@お腹いっぱい。NGNG
非対称鍵暗号を採用するとしても、2ch程度の機密性なら
復号鍵を作業サーバにおいといても良いとは思うんだけどね。

侵入が前提って点は、掲示板サーバと復号作業サーバとで、
サーバパスワードは違うものを使う、
掲示板サーバと同じスクリプトを置かない、
とすれば、危険性の度合いも変わるでしょ。

削除やキャップも拠点サーバで作業するって方向みたいだし、
そういう作業用サーバは全体をbasic認証でもかけておけば、
今回の事件みたいな丸見えの危険性も低減される。

その程度で十分なんじゃないかなーと。
0054名無しさん@お腹いっぱい。NGNG
書き込みログ見れる人は
・2ちゃんねる ★ (裁判などのログ開示)
・削ジェンヌ ★
・FOX ★(の中の人 ログ堀キャップいっぱい所有)
・boo (串焼きスクリプト)

>>52
ハッシュでxor取ってそのあと煮るなり焼くなりすれば
同じIPからの投稿でも書き込み内容によって暗号化されたものは変わってくる
0055名無しさん@お腹いっぱい。NGNG
あーIPアドレス鍵がやっとわかった。
IPアドレスをごまかすのに、
ランダムデータを付加するか、
鍵をランダムにして更に鍵を暗号化するか、
の違いということか。
比べると、手間のわりに利益が少ないかなあ。
0056名無しさん@お腹いっぱい。NGNG
自分でランダム鍵を更に暗号化の案を出しておいてアレですが、
ランダムデータ付与のほうでいいような気がします。

ランダムデータを付与して、普通に非対称な鍵で暗号化する場合は>>45の方法その1にあたる。
あとは復号化鍵をどう扱うか、だが・・・
0057名無しさん@お腹いっぱい。NGNG
非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

なので、Log自体は共通鍵暗号で暗号化して、その鍵を公開鍵暗号で暗号化して
保存する方法しかないだろうと思います。(SSLのような感じ。)

ただ、Logの暗号化をbbs.cgiでやろうとするとやっかいな点が1つ。
複数起動するbbs.cgiがそれぞれ異なる鍵(乱数)でLogを暗号化すると、
鍵の扱いがとても大変になる可能性があります。
Logを暗号化して保存するデーモンのようなものを作る必要があるかも。
0061名無しさん@お腹いっぱい。NGNG
>>57
> 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
> というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
> 処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

そもそも「書いた瞬間に裁判所から仮処分」とか「直ちに芋掘り」とかありえない。

だから、とりあえずは生ログか、簡易な共通鍵暗号化しておいて、負荷の低い時間帯(朝5時〜9時くらい?)
に一気に暗号化すればよい。
0062名無しさん@お腹いっぱい。NGNG
「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

ログ堀するんだから最低限 書き込み日時・IDは暗号化無しで格納する必要がある
この板は発信元とあるけどログには他の板で使われてるIDが書き込まれてる
0063名無しさん@お腹いっぱい。NGNG
>>62
> 「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

それ、お前だけだw

「IP・リモホだけの暗号化」やると、母集団が小さすぎて、力技で作表されてしまうおそれがある、
というので、「暗号前に適当な文字列を混ぜる」というアイディアが出てる。

文字列自体が乱数でもいいのだが、最大行数までの整数Nを発生させて、「ランダムに本文N行
含めて暗号化する」というのが暗号としては堅牢。

・・・というのがここまでのあらすじw
0064名無しさん@お腹いっぱい。NGNG
>>63
> 文字列自体が乱数でもいいのだが、最大行数までの整数Nを発生させて、「ランダムに本文N行
> 含めて暗号化する」というのが暗号としては堅牢。
本当?
例えばいま、「あ」と1行だけ書かれた本文があったとすると、ログに含まれる本文は「あ」以外に考えられないから、
日時、名前、UA、IPアドレス、ホスト名、本文を合わせて、完全な平文が手に入る。
で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの?

「同じ鍵で暗号化された、平文と暗号文の組み合わせを無数に入手しても、
 鍵の長さとアルゴリズムから考えて、復号化鍵を予測するのは不可能である」というならいいけど。
0065名無しさん@お腹いっぱい。NGNG
>>63
暗号化して分からなくすると言う意味であって
暗号化の元にするとは書いて無い

>57なんてIP・リモホだけじゃなくログ全体を暗号化しようとしてるじゃないか
0066名無しさん@お腹いっぱい。NGNG
>>64
> で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの?

されない(一般的には)

> 「同じ鍵で暗号化された、平文と暗号文の組み合わせを無数に入手しても、
>  鍵の長さとアルゴリズムから考えて、復号化鍵を予測するのは不可能である」というならいいけど。

そのとおり(一般的には)




ここで、「一般的には」というのは平文の内容が十分散らばっていて予測不能なとき、であって、
平文のパターンが2の32乗以下、実査、日本初のアドレスだと大したレンジ幅ない、となると、
「クラックされて暗号化関数が奪われた場合(これは鯖側においてあるのでその可能性は高い)」
考えられる値→暗号化した後の文字列、の表を作られてしまう、ってこと。

それを避けるためには、暗号前の文章を予測不能な平文にしておく必要がある。
それがここでのメインテーマ(昨日来)。
0067名無しさん@お腹いっぱい。NGNG
これで同じIPからの書き込みでも書き込み日時によって可変になる (逆をやれば複合化可能)
リモホは誰かやってくれ

$id = "xxxxxxxx0"; #書き込みID
$btime = pack("L1",$time); #書き込み日時 unixtime
$ip = "192.168.11.2"; #書き込みIP

($ip1,$ip2,$ip3,$ip4) = split /\./,$ip;
$ip32bitbin = pack("C4",$ip4,$ip3,$ip2,$ip1);
$ip32bitstr = uc(unpack("H2",substr($ip32bitbin,3,1))).unpack("H2",substr($ip32bitbin,2,1)).uc(unpack("H2",substr($ip32bitbin,1,1))).unpack("H2",substr($ip32bitbin,0,1));
$xorip = $ip32bitstr ^ $id;
$xorip = $xorip ^ $btime;
$ipstr = unpack("H2",substr($xorip,3,1)).uc(unpack("H2",substr($xorip,2,1))).unpack("H2",substr($xorip,1,1)).uc(unpack("H2",substr($xorip,0,1)));

$ipstrをログのIP欄に書き出す

問題点はこのスレの住人なら暗号化方法が分かってしまってる
0068名無しさん@お腹いっぱい。NGNG
一般的なISPって長くてどれぐらいの期間ログ持ってるんだっけ、
その間割れない程度の強度があればいいのかな。
0069名無しさん@お腹いっぱい。NGNG
いわゆるプロバイダ責任制限法では規定は無いそうだけど、一般的には90日程度
は保存して欲しいと言う要請はあるらしい。

だから最低3ヶ月分はどこでも持ってるんだろうな。
0071名無しさん@お腹いっぱい。NGNG
どっかしらに妥協点はおくことになるんだけど、
侵入が前提の安全策を考えるってとき、ソース見りゃ分かる程度の
暗号だと、簡単すぎないかな。
ソースは最初に狙われるでしょ。
0072名無しさん@お腹いっぱい。NGNG
軽い時間帯にまとめて暗号化するとすると、
その時までの最大24時間くらいは、
軽い暗号をかけるか、
生を許容するか。
0073名無しさん@お腹いっぱい。NGNG
>>71
ハッキングした人がどれだけのスキルがあるかだよ

●ハッキングには詳しいけどプログラム読めない・(C言語からperl等)変換できない・プログラム書けない
●プログラム読める・書ける・変換できるけどハッキング知識無し
とか普通にいても変じゃない

大抵の場合
1つのファイル(URL)流出 -> ファイル解析 -> 他のファイル
こんな流れ
最初から全てのファイルがある場所が分かる人なんていない
0074名無しさん@お腹いっぱい。NGNG
>>72
それなら1時間毎にログファイル変えるとか?
この時間なら 2011011219.log のファイル名で保存
20〜21時にファイル全体を暗号化
0075名無しさん@お腹いっぱい。NGNG
■ 暗号方式
(A) 難読化
 ・ソースを見られると解読
 ・軽い
(B) 共通鍵暗号
 ・暗号化と復号が同じ鍵なので、鍵を保存できない
  └> 常駐プロセスがメモリ上で鍵作成、暗号化処理
   ├> それでも鍵は確保する必要
   └> メモリの機密性
 ・比較的軽い
(C) 非対称鍵暗号
 ・暗号化と復号が別の鍵なので、暗号化鍵の扱いは杜撰でいい
 ・比較的重い

■ 暗号化時期
(A) 逐次
 ・ピーク負荷が上昇
(B) 鯖が軽い時にまとめて
 ・負荷分散
 ・暗号化まで最大24時間
  └> それまでは (a) 生 (b) 別の軽い暗号化

■ 復号鍵の保存場所
(A) 各サーバ内に生
 ・侵入時にはログと同時に漏洩
(B) 各サーバ内に非対称鍵暗号化
 ・その復号鍵の保存場所で再帰
(C) 拠点サーバに保存
 ・拠点サーバの侵入で漏洩
(D) 作業者が各自で保有
 ・個人環境の信頼性は
 ・作業のたびに送信
 ・権限抹消された作業者から復号鍵を取りあげることができない
  ├> 鍵は適宜変わる
  ├> 作業時の認証はある
  └> (a) 復号鍵は作業者別に暗号化して鯖保存、この復号鍵を持つ (b) 放置
0077名無しさん@お腹いっぱい。NGNG
そもそも個人的には、2ch程度にログ暗号化なんていらないだろ
くらいに思ってるけど、それでも暗号化の必要があるとするなら、
B-Ba-C かな。

1日1回、毎回作る共通鍵で暗号化。常駐不要。
鍵は拠点サーバに送信。
暗号化までは生で妥協。
拠点サーバに置かれる鍵の数は、鯖数×保存日数。

ログ掘り作業は、拠点サーバで認証、各サーバから暗号化ログを取得し、
鯖・日に対応する鍵で復号、煮るなり焼くなり。

拠点サーバは各掲示板サーバより少し気を使う。
鯖パスはとにかく長くとか、qb6/7みたいな掲示板との混在はやめるとか、
全面basic認証とか。
0078名無しさん@お腹いっぱい。NGNG
>>75
■暗号化時期については祭りが起きた時などに暗号化のピーク負荷が跳ね上がる気がします
あとサーバー乗っ取られたという想定なので
■ 暗号化時期は(A) 逐次しかないんじゃないでしょうか
同じく■ 復号鍵の保存場所についても(A)(B)は選択肢から外れ
消去法でC-A-CまたはC-A-D
0080名無しさん@お腹いっぱい。NGNG
まあそうなんだけど、1日くらいいいかな、って。

ところで、非対称鍵は重いから鯖が軽い時にまとめて、という話(>>57-61)
だったのに、>>77では軽い時に共通鍵で、ということになっているのは、
まとめてやるなら鍵を常時持っておく必要がないから、そのとき限りの
共通鍵でいいやと思ったからなんだけど、でもどうせ軽い時間にやるし、
重い処理でも負荷がピークを超えることはないだろうから、鍵1つで扱いが
楽な非対称鍵でいいか、とふりだしに戻って思い直してみたり。
0081名無しさん@お腹いっぱい。NGNG
>>80
非対称鍵を採用すれば、片側は鍵自体も見ることを不可能にしてる製品も既に売られている。

鍵ペアをA・Bとして、Aは物理的に見ることができない(ハードとしてUSB経由でもらった平文を
暗号化/署名して返すだけ。鍵の値は誰も見ることができない)

鍵Bは通常の数値だから、見たり、コピーしたり可能だけど、今回はこっちも公開しない。

そして、完全秘密の鍵Aを使って暗号化
 ↓
おいちゃん以下数人だけが知ってる鍵Bで復号化

すればかなりセキュア

問題は、通常

 鍵A→秘密鍵
 鍵B→公開鍵

と称するので、「公開鍵」って聞いた途端に心理的に緩んじゃうんだよね。「まーバレてもいいか」的なw
ここがネック。
0083名無しさん@お腹いっぱい。NGNG
>>82
そんな前提(「絶対的必須」条件)ねーよ。

 暗号化→まとめて非ピーク時間にcron
 復号化→ローカルで処理、

でもおk
そりゃ、perlに実装できりゃいろいろ選択肢/応用増えるが、要件(要求仕様)ではない。
0086名無しさん@お腹いっぱい。NGNG
どうせならさ
IP・リモホは別鯖で保存すればいいんじゃね?

そうすれば鯖別にログ内にIP保存して暗号化なんてことしないで済む
0087名無しさん@お腹いっぱい。NGNG
Perlでできないかは知らないけど、Perlである必要はないんじゃないの。
Cプログラムはいくつも動いているし。
0088名無しさん@お腹いっぱい。NGNG
新鮮なものが漏れてたら全然意味が無いわけでやるならlogbufferの段階でやるべき。
今のlogbufferって何で書いてあるか良く知らないけど。
0091名無しさん@お腹いっぱい。NGNG
C言語で書かれてるのをperlにするのは難しくない
perlで書かれてるものをC言語にするのは難しい

perl固有の特徴
・宣言無しで変数が使用可能 (もう1つあるけど略)
・仮想配列 ( $temp{$tmp} なんてもの 他の言語だと代用は可能だけど著しく面倒)

>>90
C言語で書くと書き込んでるのは>87
0092名無しさん@お腹いっぱい。NGNG
えーと、
過去にbbs.cgiをCで書くような提案があったけど
却下された経緯がある

ひ(ryがソースよめない(弄れない?)から なんて理由だった気がする
0095名無しさん@お腹いっぱい。NGNG
>>66
> 暗号前の文章を予測不能な平文にしておく必要がある。
「投稿番号と投降者名とメール欄と書き込み日時+IPアドレス」ではだめかしら?
投稿番号はなくてもいいと思うけど。
「板の名前・投稿日時・IPアドレス」だったら板の名前を工夫すれば文字数も揃えられる気がするけど・・
0097名無しさん@お腹いっぱい。NGNG
read.cgi、offlaw.cgi、anydat.so、bbsd

>>95
本文等はスレ上に出ちゃってるというわけで、ランダムデータを混ぜようってな
話になっているわけだね。
暗号化が、投稿1件ずつか、ファイルごとか、というような部分でも事情は
違ってくるけど。
レスを投稿する


ニューススポーツなんでも実況