書き込みログのIP&リモホを見た目わからなくする方法を考えよう

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

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

誰か方法考えてちょ

MD5->base64変換


非現実的だけど

3偽FOX ★NGNG
可逆的なのよろしくー

base64変換だけなら可逆だよ
MD5までやっちゃうと難しいけど

・別ユーザのデーモンで暗号する
・復号は別のサーバーで行う

非対称鍵

付与するキーを、別鯖から取得して暗号化。
復号時にも同じく別鯖から取得して復号化。

・・・かなぁ。。。

クラッカーホイホイですね。分かります。

公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

復号鍵は、どこのサーバ内にも保存せず、作業時に自分のPCから毎回送信するとか。
あるいは復号作業を自分のPCでやるとか。

復号鍵をおいちゃんのPCにだけ置いておくほうがいいと思う
でも鯖に侵入されたらログをみてIPやリモホは分からなくても、ログを消去される可能性が残るということをお忘れなく。

>>11
削除要請で裁判所からのIP開示に対応しないと駄目だから
個人のPCに復号鍵を置くのは、ちょっと。。

>>12
じゃぁ芋掘り出来る人全員に鍵持を持ってもらうってのはどうなのよ。
実際に芋堀りできる人がどれくらいいるのか分からないからなんとも言えないけど。
・・・この場合だと、「ある人から芋掘り権を剥奪する」という操作が不可能だな。鍵は全員同一のものになってしまうから。

あるいは、復号化鍵はqb7あたりにおいておいて、qb7の窓口から芋掘り。
qb7にはいられたら終わりだけど、qb7は堅牢だという前提で・・・。
  芋掘り人
指示↓ ↑芋
   qb7鯖 ←復号処理
指示↓ ↑暗号化芋
  掲示板鯖

削除要請や裁判所がどう関係するのかわからない。
作業するのは1人だけじゃないって意味?
これは、IPアド閲覧権限者で復号鍵を共有することになるね。
この点は従来のアクセスパスワードを共有しているのと同じ。

まあ、ウェブサーバと個人PC、どちらが安全性が高いかっていうと、
色々な考え方ができるんだろうけども。
ただこれもパスワードのメモを保存するのと同じか。

確かに剥奪時の問題はあるんだけど、暗号化ログを取得するにも
何らかのアクセスパスワードがかかるはずだから、そこで制御するとか、
1年とか一定期間ごとに鍵を変えるとか。

ログ保存も永遠じゃないしな。

>>13
それなら、大丈夫かな。

>>14
IP開示をする作業は一人だけじゃないんだな。
http://qb5.2ch.net/test/read.cgi/sec2ch/1293072067/

削除要請でこのような作業があるのよ。

qb7に鍵を置くのはいいんですけど
その鍵は一定時間ごとに変更される仕組みも必要では?

>>16
うん。
作業者が複数って端的に言えば済むところを、削除要請や裁判所を
持ち出すのは何か別の意味があるのかなと思っただけ。

>>18
書き方が悪かったかな。。ごめん。
まぁ、そういう事なんで複数の人が使う事を前提に考えなきゃ駄目なんだよ。
複数といっても、そんなに多くは無いと思う。

>>17
いっその事ワンタイムパスを(ry

>>17
一定期間ごとに自動で鍵を作り直す・・・とか?

22名無しさん@お腹いっぱい。NGNG
別サーバーで、登録したMACアドレスのみアクセスできるようにするとかはダメ?

MACアドレスは参照しない方がいい。
MACアドレスは絶対にユニークな値ではないよ。
書きかえられるし。

macアドレスはいくらでも偽装出来るよ。

MACアドレスの書き換えは可能だけどほぼ生IPになる

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

やらないよりはやった方がマシなレベル

MACアドレスはユニークでないのはもちろん、どのレイヤーのものかを考えると……

PIE外に設置してる鯖とのやり取りが不可能になるか。
MACアドレスは忘れてくれ。

>>9
> 公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね

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

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

・それ以前の問題として、IPアドレスなんて有限通り(32ビット)しかないんだし、しかも、ほとんど
 日本発信のアドレスレンジはもっと狭い → カギ公開してたらブルートフォースで作表されてしまう。

よく考えたら、これって公開鍵暗号方式だけの問題じゃないね。

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

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

つうことで

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

これってそもそも不可能じゃね

絶対なんて幻想にとらわれてどうするんだと^^;

いや「絶対」とかそういう次元の問題じゃなくて

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

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


詰んだ

そもそも平文の母集団が少ないのは前提であって、それに対してイカに復号化を難しくするかってとこだろ


いやここでv6アドレスを使えば…

そもそもPIE内でMACアドレスが重複した事件とか忘れたわけじゃないよねみんな

>>32

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

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

文字列乱数は、毎回変えれば、母集団は無限大になるので、作表は不可能。
他方、復号化したあと「人間ならば」見りゃどこがIP・リモホなのかはわかる。
どうだ?w

>>34
それならログに残る本文(の一部)を使えばいいと思うの。

>>35
うむ。日付と時間含むだけでも相当散るよねw

IPアドレスの母集団が少なくて、暗号化してあってもログが流出すると総当りで解読されるって言うなら、
まずIPアドレス鍵をランダムに作り、これでIPアドレス・ホスト名を暗号化する。
そのあと、別の公開鍵(固定)でIPアドレス鍵を暗号化して、暗号化IPアドレス・ホストと一緒に記録。

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

>>37
> 芋掘り時には、秘密鍵(おいちゃんと一部の削除人保有)

結局、これって、現在のパスワード方式による芋掘りとリスクレベルはおんなじなんだよね。
暗号設計の問題じゃなくて、「体制」の問題と思う。
複数人で共通鍵を共有したら、クラッカーの攻撃で漏れるのは時間の問題。

>>38
最初の趣旨が何であったか思い返しましょう。

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

芋掘り作業のパス漏洩とかはまた別レベルの話だと思います。

>>39
なるほど。

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

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

こんなとこか?

しかし生ログが漏れた時点で時間さえかければどうにでもなっちゃうよね。

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

>>34みたいに、表に公開しないランダム固定長文字列をログに付けて暗号化したほうが良くない?
別に可変長でもいいけど十分長ければいいわけで、スクリプト上での扱いが固定長のほうが楽だから。
で、ログを表に公開するときもこのランダム文字列は公開しない(掘って復号した後に除く)。

User-Agent、●、P2、の情報もあるよ。
まあ、ランダムデータを混ぜる方が安全ってのはあるね。

>>41
暗号の安全性ってのは、現実的な時間で解読できなければ、
それは安全ってことなのよ。

【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

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

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

■ 復号鍵を作業者が各自で保有する場合
・作業スクリプトで、作業者を認証管理した上で、復号鍵を作業スクリプトに送信する。
・掲示板サーバや復号作業サーバで侵入や漏洩が起きても、暗号は安全。
・同じ復号鍵を、作業者全員が保有する。
・各作業者の情報管理が頼り。
└> ウェブサーバと個人PC、どちらが安全か。
・権限抹消された作業者から復号鍵を取りあげることができない。
├> 定期的な鍵の変更が必要か。
└> 作業スクリプトの認証で足りるか。

暗号化の負荷ってどうなんだろう。

>>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。

【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。

【方法その2】
IPアド公開掲示板へと生まれ変わる。
開示訴訟にさようなら。

siberiaの時代到来ですね

>>34-35の組み合わせがいい予感

>>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう?

とりあえず、
復号鍵を、サーバに、作業者の数だけ別個に暗号化して置いておき、
作業者は、自分用の「暗号化された復号鍵」の復号鍵を持つ、とすればいいのか。
権限抹消時は、その人用の「暗号化された復号鍵」を削除すると。
2段階あるだけに、面倒といえば面倒だし、安全といえば安全。

>>34って独立した案なの?どれかの補足?

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

IPアドレスだけじゃ、総当りで暗号化して暗号データの比較で
正解を見つけられるって懸念への補足なら、付加するのは
ランダムデータでいいんじゃないの。

>>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵(これは非対称鍵)で暗号化して、一緒に記録。

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

つまり、普通に非対称鍵で暗号化するにあたり、IPアドレスだけだと255^4しかなくてテーブルを生成するのが
容易だから、長い文字列を作ってからにすればいいじゃんってことだろ。
「適当な乱数とかめちゃくちゃな文字列」って書いてあるけど要するにランダムデータだろ。

非対称鍵暗号を採用するとしても、2ch程度の機密性なら
復号鍵を作業サーバにおいといても良いとは思うんだけどね。

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

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

その程度で十分なんじゃないかなーと。

書き込みログ見れる人は
・2ちゃんねる ★ (裁判などのログ開示)
・削ジェンヌ ★
・FOX ★(の中の人 ログ堀キャップいっぱい所有)
・boo (串焼きスクリプト)

>>52
ハッシュでxor取ってそのあと煮るなり焼くなりすれば
同じIPからの投稿でも書き込み内容によって暗号化されたものは変わってくる

あーIPアドレス鍵がやっとわかった。
IPアドレスをごまかすのに、
ランダムデータを付加するか、
鍵をランダムにして更に鍵を暗号化するか、
の違いということか。
比べると、手間のわりに利益が少ないかなあ。

自分でランダム鍵を更に暗号化の案を出しておいてアレですが、
ランダムデータ付与のほうでいいような気がします。

ランダムデータを付与して、普通に非対称な鍵で暗号化する場合は>>45の方法その1にあたる。
あとは復号化鍵をどう扱うか、だが・・・

非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

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

ただ、Logの暗号化をbbs.cgiでやろうとするとやっかいな点が1つ。
複数起動するbbs.cgiがそれぞれ異なる鍵(乱数)でLogを暗号化すると、
鍵の扱いがとても大変になる可能性があります。
Logを暗号化して保存するデーモンのようなものを作る必要があるかも。

logbufferとかいうのがいたと思うからそれに手を加える事になるのかな

やっぱ重いのかあ。

こないだでたCPUはAESなら馬鹿みたいに速いんだよね。
専用ハードウェア内蔵だから

>>57
> 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
> というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
> 処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。

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

だから、とりあえずは生ログか、簡易な共通鍵暗号化しておいて、負荷の低い時間帯(朝5時〜9時くらい?)
に一気に暗号化すればよい。

「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

ログ堀するんだから最低限 書き込み日時・IDは暗号化無しで格納する必要がある
この板は発信元とあるけどログには他の板で使われてるIDが書き込まれてる

>>62
> 「IP・リモホだけの暗号化」と「ログ全体の暗号化」が混在してる気がする

それ、お前だけだw

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

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

・・・というのがここまでのあらすじw

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

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

>>63
暗号化して分からなくすると言う意味であって
暗号化の元にするとは書いて無い

>57なんてIP・リモホだけじゃなくログ全体を暗号化しようとしてるじゃないか

>>64
> で、鯖に入り込んで完全な暗号文を得ると鍵って解読されちゃうんじゃないの?

されない(一般的には)

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

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




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

それを避けるためには、暗号前の文章を予測不能な平文にしておく必要がある。
それがここでのメインテーマ(昨日来)。

これで同じ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欄に書き出す

問題点はこのスレの住人なら暗号化方法が分かってしまってる

一般的なISPって長くてどれぐらいの期間ログ持ってるんだっけ、
その間割れない程度の強度があればいいのかな。

いわゆるプロバイダ責任制限法では規定は無いそうだけど、一般的には90日程度
は保存して欲しいと言う要請はあるらしい。

だから最低3ヶ月分はどこでも持ってるんだろうな。

刑事訴訟法改正案で90日ってことになっているからね。

どっかしらに妥協点はおくことになるんだけど、
侵入が前提の安全策を考えるってとき、ソース見りゃ分かる程度の
暗号だと、簡単すぎないかな。
ソースは最初に狙われるでしょ。

軽い時間帯にまとめて暗号化するとすると、
その時までの最大24時間くらいは、
軽い暗号をかけるか、
生を許容するか。

>>71
ハッキングした人がどれだけのスキルがあるかだよ

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

大抵の場合
1つのファイル(URL)流出 -> ファイル解析 -> 他のファイル
こんな流れ
最初から全てのファイルがある場所が分かる人なんていない

>>72
それなら1時間毎にログファイル変えるとか?
この時間なら 2011011219.log のファイル名で保存
20〜21時にファイル全体を暗号化

■ 暗号方式
(A) 難読化
 ・ソースを見られると解読
 ・軽い
(B) 共通鍵暗号
 ・暗号化と復号が同じ鍵なので、鍵を保存できない
  └> 常駐プロセスがメモリ上で鍵作成、暗号化処理
   ├> それでも鍵は確保する必要
   └> メモリの機密性
 ・比較的軽い
(C) 非対称鍵暗号
 ・暗号化と復号が別の鍵なので、暗号化鍵の扱いは杜撰でいい
 ・比較的重い

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

■ 復号鍵の保存場所
(A) 各サーバ内に生
 ・侵入時にはログと同時に漏洩
(B) 各サーバ内に非対称鍵暗号化
 ・その復号鍵の保存場所で再帰
(C) 拠点サーバに保存
 ・拠点サーバの侵入で漏洩
(D) 作業者が各自で保有
 ・個人環境の信頼性は
 ・作業のたびに送信
 ・権限抹消された作業者から復号鍵を取りあげることができない
  ├> 鍵は適宜変わる
  ├> 作業時の認証はある
  └> (a) 復号鍵は作業者別に暗号化して鯖保存、この復号鍵を持つ (b) 放置

一番堅牢っぽいのは、C-A-Da かな。
費用対効果は悪そう。

そもそも個人的には、2ch程度にログ暗号化なんていらないだろ
くらいに思ってるけど、それでも暗号化の必要があるとするなら、
B-Ba-C かな。

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

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

拠点サーバは各掲示板サーバより少し気を使う。
鯖パスはとにかく長くとか、qb6/7みたいな掲示板との混在はやめるとか、
全面basic認証とか。

>>75
■暗号化時期については祭りが起きた時などに暗号化のピーク負荷が跳ね上がる気がします
あとサーバー乗っ取られたという想定なので
■ 暗号化時期は(A) 逐次しかないんじゃないでしょうか
同じく■ 復号鍵の保存場所についても(A)(B)は選択肢から外れ
消去法でC-A-CまたはC-A-D

A-A の後 C-Bでいいんじゃね?

3番目はノータッチ

まあそうなんだけど、1日くらいいいかな、って。

ところで、非対称鍵は重いから鯖が軽い時にまとめて、という話(>>57-61)
だったのに、>>77では軽い時に共通鍵で、ということになっているのは、
まとめてやるなら鍵を常時持っておく必要がないから、そのとき限りの
共通鍵でいいやと思ったからなんだけど、でもどうせ軽い時間にやるし、
重い処理でも負荷がピークを超えることはないだろうから、鍵1つで扱いが
楽な非対称鍵でいいか、とふりだしに戻って思い直してみたり。

>>80
非対称鍵を採用すれば、片側は鍵自体も見ることを不可能にしてる製品も既に売られている。

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

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

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

すればかなりセキュア

問題は、通常

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

と称するので、「公開鍵」って聞いた途端に心理的に緩んじゃうんだよね。「まーバレてもいいか」的なw
ここがネック。

>暗号方式 (共通鍵暗号・非対称鍵暗号)
cgi(perl)内で使えなければダメ

なんて前提を忘れてる気がする

>>82
そんな前提(「絶対的必須」条件)ねーよ。

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

でもおk
そりゃ、perlに実装できりゃいろいろ選択肢/応用増えるが、要件(要求仕様)ではない。

>>82
「まとめて非ピーク時間にcron」って前提じゃんか

>>84
おちつけw

どうせならさ
IP・リモホは別鯖で保存すればいいんじゃね?

そうすれば鯖別にログ内にIP保存して暗号化なんてことしないで済む

Perlでできないかは知らないけど、Perlである必要はないんじゃないの。
Cプログラムはいくつも動いているし。

新鮮なものが漏れてたら全然意味が無いわけでやるならlogbufferの段階でやるべき。
今のlogbufferって何で書いてあるか良く知らないけど。

>>87
言い出しっぺがやる法則

>>89
がんばって

C言語で書かれてるのをperlにするのは難しくない
perlで書かれてるものをC言語にするのは難しい

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

>>90
C言語で書くと書き込んでるのは>87

えーと、
過去にbbs.cgiをCで書くような提案があったけど
却下された経緯がある

ひ(ryがソースよめない(弄れない?)から なんて理由だった気がする

つまり今ならその障害はクリアされてると

>>93
FOX ★の中の人がC言語扱えれば移行されるかもしれない

注意として
>87が流出したbbs.cgiをC言語で書く必要がある

>>66
> 暗号前の文章を予測不能な平文にしておく必要がある。
「投稿番号と投降者名とメール欄と書き込み日時+IPアドレス」ではだめかしら?
投稿番号はなくてもいいと思うけど。
「板の名前・投稿日時・IPアドレス」だったら板の名前を工夫すれば文字数も揃えられる気がするけど・・

>>94
FOXはC言語はできるはずだよ
read.cgiいじってたりするし

read.cgi、offlaw.cgi、anydat.so、bbsd

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

別に元管理人もC言語できなかったわけじゃないし…
http://qb5.2ch.net/test/read.cgi/operate/1196560836/752

なんでここの連中は、perl から C の任意のプログラムを spawn できるの知らないんだろ?

>>97
それは暗号化してあるデータがどのスレの何番目の書き込みかが分かっているって前提ですよね?

新着レスの表示
レスを投稿する