K.Maebashi's BBS

>>最近Ｃ言語を始めたのですが、この問題がどうしても解けません。誰かといてください。お願いします（＞＿＜） > >　宿題は自分でやるべきでしょう。 初めまして、どぅと申します。 前橋さまの「C言語 ポインタ完全制覇」と「Java謎+落とし穴徹底解明」によって蒙を啓かれた者です。まだ理解できていないところもありますが、この二冊には大変お世話になっております（現在進行形）。 さて、本題ですが、宿題は自分でやるべきで、それがマキバオーさんの為だと思いますし、それゆえ(ぱ)さまは流石思いやりのある対応をされたなぁと思うのですが、残念ながら私は利己的で、マキバオーさんの為にはならないと知りながら、申し訳ないけど自分の興味の為に課題をやってしまいました。情けは人の為ならず（←ダブルミーニング！）。尤も正しい答えに到達しているかは分かりませんが。 この手の問題は、半分数学ですね。より正確に言うと、ドコまで数学で解いて、ドコからプログラムにやらせるか。これは連続的にスペクトルをなしていて、一方の端が、「全部人間様が数学を駆使して計算する」反対側の端が「全部プログラムにしてコンピュータが計算する」になってます。つまり大ざっぱにいうと、 １．全部数学で人間様がやる。 ２．半分数学で人間様がやって、半分プログラムにしてコンピュータがやる。 ３．全部プログラムにしてでコンピュータがやる。 の３パターンに分かれると思います。おそらく出題者は２を期待してるんじゃないかなーと思いますが、どうなんでしょ？１で解くと多分ダメなんでしょうね＾＾；とりあえず「おそらくこんな解が期待されてるんだろうなぁ」てな２の解を示して、その次に３の解を書いてみます。 ■パターン２ まず、n期目で残高があれば良い。そんで、n期目の残高は、nとmとb（と利率1.05)で決まりますね。つまりn期目の残高はn, m, bの関数になるので Z(n, m, b)と書けると。それが残っていると言うことは、 Z(n, m, b) > 0 となると。この不等式をbについて解けば良いわけですね。じゃあZ(n, m, b)って何なのよ？ こういうのはとりあえず普通１期目、２期目、３期目、ぐらいまで具体的に求めてみると何か見えてくる可能性があります。と言うわけで、各期の残高を求めてみると。。。 １期目：1.05(b - m) = 1.05b - 1.05m ２期目：1.05(1.05b - 1.05m - m) = 1.05^2b - 1.05(2.05)m ３期目：1.05(1.05^2b - 1.05(2.05)m - m) = 1.05^3b - 1.05(1.05(2.05) + 1)m ここら辺までくると何かが見えてきますね！？つまりi期目の残高は、 1.05^ib - ???m となりそうです。???のところをよーく見ると、 ???は、前期の???に1を足して、1.05倍する となってそうです。つまり、i期の???をY(i)とすると、 Y(i+1) = 1.05(Y(i) + 1) Y(1) = 1.05 と言えそうです。これ、漸化式ってやつだけど、どうやら解くのは面倒そうですね。。 ＃根性入れれば解けるので、そうすれば「１」のパターンになる！！ とりあえず、Y(i)はそのまま（1から順番にやれば求まりそうだし）とすると、i期における残高は、 X(i)b - Y(i)m ただし、X(i) ,Y(i)は次の通り、 X(i) = 1.05^i Y(i)は、次の漸化式を満たす Y(i+1) = 1.05(Y(i) + 1) Y(1) = 1.05 で表されます。これがn期で残っていると言うことは、 X(n)b - Y(n)m > 0 と言うことになりますので、bについて解くと(X(n) > 0に注意して) b > Y(n)m / X(n) となります。Y(n)は漸化式にしたがって1から順番に計算していけば求まりますが、めんどいなぁ。誰かやってくれないかなぁ。。。人間様が考えるのはここまで。あとはコンピュータにやってもらいまひょ。ついでにX(n) = 1.05^nも計算してもらいます。 で、プログラムは次の通り。解に自信がなかったので、求まったbの値で本当に良いのか、各期残高を順に表示して検算もしてます。求まるbはぎりぎりの値なので、n年目には残高が0円になってしまいますが、bはそれより大きければ良いということで。。。 ちなみに、銀行でどの有効桁数で情報を持っているのか、つまり0.1銭とかにも利子が付くのか！？は気にしてません。doubleの有効桁数の範囲で計算してます。 あと、math.hが入ってますので、コンパイル時に-lmを忘れずに！（←なんて親切なんだ！？） #include <stdio.h> #include <math.h> #include <stdlib.h> int main(int argc, char** argv){ int n = 0; int m = 0; double x_n = 0.0; double y_n = 1.05; double b = 0.0; double zandaka = 0.0; int ii; /* パラメータチェック */ if ( argc != 3 ){ printf("usage %s n m\nn:期間 m:引き出し額\n", argv[0]); return 0; } /* パラメータ取得 */ n = atoi(argv[1]); /* 期間 n */ m = atoi(argv[2]); /* 引き出し額 m */ /* i期における残高: ( X(i) * b ) - ( Y(i) * m ) * ただし、 * X(i) = 1.05^i, * Y(i) : Y(i+1) = 1.05 * ( Y(i) + 1 ), Y(1) = 1.05 * n期において0円以上あるためには * (X(n) * b) - (Y(n) * m) > 0 * これを bについて解くと、 * b > Y(n) * m / X(n) */ /* X(n)を求める */ x_n = pow(1.05, n ); /* Y(n)を求める。ここがキモ */ for ( ii = 2; ii <= n; ii++ ){ y_n = 1.05 * ( y_n + 1 ); } /* b(の下限)を求める */ b = (y_n * m) / x_n; /* 残高の変化の様子を表示(検算) */ zandaka = b; for (ii = 1 ; ii <= n; ii++){ zandaka = 1.05 * ( zandaka - m ); printf("%3d: %f\n", ii, zandaka); } /* 表示 */ /* printf("X(n) = %f\n", x_n); */ /* printf("Y(n) = %f\n", y_n); */ printf("n = %d\n", n); printf("m = %d\n", m); printf("b > %f\n", b); return 0; } ■パターン３ 次に、人間様は何も考えないで、全部プログラムでコンピュータにやらせるパターンをやってみます。 b=1万円から初めて、n期目でも残高が残っているまで、bを1万円ずつインクリメントしていきます。なので、精度が1万円単位になってます。1円単位の精度が欲しい場合は0.0001万円から初めて0.0001ずつインクリメントすれば良いでしょう。10000倍遅くなりますが・・・ 言うまでもなく、このアルゴリズムは余りにバカ正直で（特に1円単位なると影響大）、普通はちょっと工夫すると思いますが、「人間様は何も考えない」パターンということで。 これをどうやって高速化するか（スペクトルをちょっと人間様寄りにする）は、マキバオーさんの宿題と言うことで。。。もしかしたらそれが求められている解かも？ #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv){ double b = 0; int n = 0; int m = 0; double zandaka; int ii; if ( argc != 3 ){ printf("usage %s n m\nn:期間 m:引き出し額\n", argv[0]); return 0; } n = atoi(argv[1]); /* 期間 n */ m = atoi(argv[2]); /* 引き出し額 m */ /* n期目でも残高が残るまでbをインクリメントしていく */ for ( b = 1 ;zandaka <= 0 ; b += 1){ /* 残高を、残っている限り、最大n期目まで求める*/ zandaka = b; for (ii = 1 ; ii <= n && zandaka > 0; ii++){ zandaka = 1.05 * ( zandaka - m ); } } /* 残高の変化の様子を表示(検算) */ zandaka = b; for (ii = 1 ; ii <= n && zandaka > 0; ii++){ zandaka = 1.05 * ( zandaka - m ); printf("%3d:%f\n", ii, zandaka); } /* 表示 */ printf("n = %d\n", n); printf("m = %d\n", m); printf("b > %f\n", b); return 0; } ソースは無保証です！！！ ただ、バグのご指摘、ご批評など頂ければ幸いです。

>>これを気にするのであれば、salt とプログラム埋め込みのsecret >>の両方を使うのが良いと思います。どちらか片方だけであれば、 >>salt の方を選ぶのが良い習慣だと思います。 > >両方使うようにして、今までの分はsaltを空文字にしておけば、 >今までの投稿については、以前のパスワードが変わらず使えるかなあ、と >一瞬考えたのですが、D/B流出の時にパスワードがばれる危険性を考えて >いるのだからそれじゃ本末転倒ですね (^^; > >今までの投稿が削除できなくなってもおそらく誰も困らないでしょうから >(いまさら「しくじったので書き直し」はないでしょうから)、今度時間が >できたときに修正しておきます。 ほとんど文脈無視ですが_o_、salt として本文を使うってのはどうですかね？ 管理者による本文の修正は出来なくなりますけどね。

>最近Ｃ言語を始めたのですが、この問題がどうしても解けません。誰かといてください。お願いします（＞＿＜） 　宿題は自分でやるべきでしょう。

最近Ｃ言語を始めたのですが、この問題がどうしても解けません。誰かといてください。お願いします（＞＿＜） １．ある銀行では毎期末に預金残高に対して５％の利率で利息がつく．この銀行に，例えばa万円を一期間預金すると，期末には1.05×a万円の預金残高になる． 第1期の初めに，Ａさんはこの銀行にb万円の預金を持っている．Ａさんは，まずb万円から第1期分m万円を引き出す．残りの預金に対し第1期末に５％の利息がつく．ここで，b > mとする．第２期目からも毎期初めにこの預金からm万円ずつを引き出す．ただし，預金残高がm万円に満たないときには，その全額を引き出すものとする． Ａさんの預金残高がn期間にわたって0円とならないために必要な第1期初めの預金額「b」を計算したい．期間「n」と毎期の引き出し額「m」を入力して，上の条件を満たす最小の「b」を求めるプログラムを作れ．なお，単位は「万円」とする．また，n ＞＝ 2 とする．

　kitさんのご指摘を受けまして、パスワード認証にsaltを使うようプログラムを 修正しました。 　これに伴い、この投稿以前に設定した削除用パスワードは使えなくなっています。 あしからずご了承ください。 # ここで力尽きたので、解説記事の修正はまだ…

>MYSQLのことで、ご質問させて頂きます。 >インストール後に、コマンドプロンプトで >パスを通そうとしたところ、以下のエラーが表示されてしまいました。 > >ERROR 2003: Can't connect to MYSQL server on 'localhost' >(10061) Windowsでパスを通すとき通常コマンドプロンプトは使わないと思うし、 パスを通そうとして、上記エラーが出ることはないはずです。 mysqlのクライアントを立ち上げようとした時にこのエラーが出るのなら わかりますが。 もし、コマンドプロンプトから「mysql」とタイプして上記メッセージが出るのなら、 MySQLのサーバが起動していないのでしょう。サービスに登録するか、 mysqldを実行する必要があります。 >10061というポート番号は存在しないのは、理解しています。 ウェルノウンポートでないだけで、65535までのポート番号は存在しうるでしょう。

MYSQLのことで、ご質問させて頂きます。 インストール後に、コマンドプロンプトで パスを通そうとしたところ、以下のエラーが表示されてしまいました。 ERROR 2003: Can't connect to MYSQL server on 'localhost' (10061) 10061というポート番号は存在しないのは、理解しています。 なるべく具体的にどこのファイルをどう変更すると助言頂けると 助かります。 宜しくお願い致します。

>僕は大学生なのですが、プログラムの先生がhogeを多様していました。 ひょっとして WIDE 関係のネットワークの先生だったりしません？ >それどころかfugaなるものをも使用していました。 hoge, fuga は結構よく見ます。 hoge, huga という変種もあるようです。 google で探すと hoge, piyo より多いです。 hoge のページに記載してもいいですよねえ。

はじめまして。 むつかしい議論をしている最中恐縮ではありますが・・・ 僕は大学生なのですが、プログラムの先生がhogeを多様していました。 それどころかfugaなるものをも使用していました。 これはほげ学に新風を巻き起こすのでは、と思い、書き込みをしました。 よければ参考にしてください。

>で、そーいう入門段階を既に過ぎた人でないと >| 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 >| と化していることが多いようです。 >なんて議論は理解できないでしょう。 これはそう思います。 ># 今この場では「入門」の話に限定、していい？のですよね。 了解です。 ちょうどoosquare-mlで継承の話が出てたので[283]のように書きましたけど、 「継承の問題点」のような話は入門者にわかりにくいのは確かだと思いますので、 そういう話は別スレ立てることにして、今この場は「入門」の話に限定、しておきましょう。 まあ入門者相手でも、継承が「ソースの再利用のためのテクニック」だと言われれば それは変だと思いますが、774RRさんの出されている >「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 という例は、継承の使い方としてまっとうだと思いますし。

仕事中の現実逃避で、前橋さんが紹介されたoosquare-mlを読んでました。 読んだ感想なんですが、僕の中では、ただ単に「手抜きのために継承は使うな」って いうだけのような気がします。（考えなさ過ぎ？） 委譲を使ったとしても、やたらと関連が集中しているクラスを作ってしまったら、 結局ごみ置き場になってしまいますし。 > 「ぴゅあＯＯ」を学んでも、それが明日役立つか、って言われるとキツイものがあります。 > 「入門者でも即、目に見える価値」が無いと教える側としては困るのです。 僕はそれほど教える立場にはいないんですけど、確かにそれは感じますね。 2年ほど前にあったSun Super Tech DaysのBOFを覗いた時、どなたかが 「インドではプログラマを養成する際、UMLなどを使用して、まずオブジェクト指向から 叩き込む。実際のプログラムを教えるのはその後。日本のIT業界もそうでなければ。」 といった趣旨の発言をされていました。 その時は、「あー、そーなんだー。」ぐらいに思っていたんですけど、今になって 思えば、全然そんな事はないんじゃないかと。プログラマなんだから、まずプログラムを 覚えろと。 オブジェクト指向が有効かどうかという判断は、その後なんじゃないかと、最近では 思います。 例えばデザインパターンなんて教えるものじゃなくて、試行錯誤や見よう見真似で、 「気が付いたら使ってた」ぐらいが理想だよなぁ、なんて思ったりします。 で、教える側は、そこに到ることの出来る基礎を身につけさせてあげれば良いのでは、 そしてその基礎というものは、オブジェクト指向というよりも、「プログラムを組む ための地力」となる知識と経験なのでは、と思います。

飴と鞭、って鞭ぢゃないですけど、既に kei さまが [278] で述べられているとおり > 結局、「それが出来ると何がうれしいのか」ってことを実感してからじゃないと、 これが端的に直感できるのが「使うほうは基底クラス、実装するほうは派生クラス」 だと *個人的には* 思います。 飴が無ければ、鞭で叩かれないと新しい知識の勉強なんてしないでしょ？ # そーいうのに興味が無い人の場合。放っておいていい子は教えなくても勝手にやってるし。 C++ の場合 <algorithm> だけでも学ぶ価値＆即戦力になる実力があるのですが 「ぴゅあＯＯ」を学んでも、それが明日役立つか、って言われるとキツイものがあります。 「入門者でも即、目に見える価値」が無いと教える側としては困るのです。 で、そーいう入門段階を既に過ぎた人でないと | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 なんて議論は理解できないでしょう。 # 今この場では「入門」の話に限定、していい？のですよね。

>従って、あらかじめ辞書を記憶媒体に作成するのは不可能で、全ての >メッセージについて、試行するしかありません。 >これに要する計算コストは、O(M*D) となり、M が大きければ、 >O(N) や O(D) よりも有意に大きな値になります。 納得しました。計算量はM倍ですよね。 うちの掲示板ではMがそんなに大きくないので、「全てのsaltに対応する 辞書を作成する」というのが現実的と思えず、「探索空間が salt のビット数分 広がる」のところで混乱していました。 丁寧な説明ありがとうございました。

>とりあえず俺的には入門者に最初に教えたいのが継承派生です。 ちょうど今、oosquare-mlで継承の是非に関する議論が白熱しています。 http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/thread.html なんかもう、「言葉の上だけの議論は空しい」状態になってる気もしますが… まあ継承には色々な問題があると私も思うんですが、一連の議論の中で、 http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200501.month/4468.html | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 これ、具体的にはどういう例なんだろう… あるクラス群が共通に使うメソッドを、それらのクラスのスーパークラスに 山ほど押し込んでいる、ってことかなあ。 スーパークラスには「外から見て」そのクラスに必要なメソッドが入っていれば よいわけで、サブクラスが共通に使うメソッドなんか持つ必要はないと 思うんですが。共通処理があるのなら、Utility.javaみたいな「関数」を 書けばいい。 >「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 >ある程度プログラム経験がある人だと、これで結構ぐらぐらしてくれます。 これはJavaならinterfaceですよね。 ただ、interfaceには実装がまったく書けないので、やっぱりデフォルトの挙動が 欲しい、とか思ったときに、DefaultHogeとかSimpleHogeとかAbstractHogeとか 作っちゃうわけで… これがよいのかどうか。 http://struts.apache.org/api/org/apache/struts/action/Action.html これなんかはどうなんだろう。私なら、こういうのは反射的にinterfaceにしますが。 クラスにした結果、結構ごみ置き場になってるような気も。

> また、異なるメッセージであっても、同一ユーザーは同じパスワードを > 使い回すと仮定します。 この仮定は本質的ではないので、N==M とおいて、 Sとして十分大きなビット数を用いると、辞書攻撃に必要な計算量が、 min(M*D/M, M*D/D) == min(D, M) 倍程度になるわけです。 と書いた方が分かりやすかったですね。

> saltがばれてる状態では、「探索空間が salt のビット数分広がる」 > ことはないように思いますが…まだ何か勘違いしてますでしょうか。 D: 辞書のサイズ S: salt のビット数 N: ユーザ数 M: メッセージ数 とします。 ここで、一つのMD5ハッシュ値から辞書を引いてパスワードを得るコスト を O(1) とします。 また、異なるメッセージであっても、同一ユーザーは同じパスワードを 使い回すと仮定します。 なお、2^S は、M より有意に大きいため、ほぼ全てのメッセージについて、 異なる salt が使われているものとします。 ここで、salt なしの場合、辞書作成に必要なコストは O(D)、辞書攻撃に 必要なコストは O(N) です。 では、salt ありの場合は、どうでしょう。 全てのありうる salt に対して辞書を作成するのに必要な計算コスト および記憶コストは O(D * 2^S) ですが、これは S が十分大きければ (例えば S=64) 計算量的にも、あるいは記憶容量的にも実現不能になります。 従って、あらかじめ辞書を記憶媒体に作成するのは不可能で、全ての メッセージについて、試行するしかありません。 これに要する計算コストは、O(M*D) となり、M が大きければ、 O(N) や O(D) よりも有意に大きな値になります。 すなわち、Sとして十分大きなビット数を用いると、辞書攻撃に必要な 計算量が、min(M*D/N, M*D/D) == min(M*D/N, M) 倍程度になるわけです。

なんだかすごく初心者な発言をしている気がしますが、聞くは一時の恥ということで。 >データベース中には複数のMD5化されたパスワードが存在する >わけですが、salt がないと、単一の辞書を使って、全ての >パスワードに対する試行を行うことができます。これに対し、 >salt があると、2 の salt のビット数乗 の辞書が必要になる >わけです。 つまりこういうことでしょうか。 ・パスワード候補となりうる文字列に「秘密」を連結し、MD5ハッシュ値を算出する。 　大量の文字列に対してこれを行い、辞書を作る。 ・辞書が何らかの記憶媒体に載るとしたら、ハッシュ値がばれればパスワードもばれる。 　ハッシュ値の方から逆引きできるようなしかけにしておけば一瞬。 ・辞書を作るにはひとつのパスワードを抜くのと同じ計算量が必要だけど、 　「秘密」方式では、その計算量で、全てのパスワードがばれる。 うーん、でも、 >salt があると、探索空間が salt のビット数分広がるため、 saltがばれてる状態では、「探索空間が salt のビット数分広がる」ことはない ように思いますが…まだ何か勘違いしてますでしょうか。 >これを気にするのであれば、salt とプログラム埋め込みのsecret >の両方を使うのが良いと思います。どちらか片方だけであれば、 >salt の方を選ぶのが良い習慣だと思います。 両方使うようにして、今までの分はsaltを空文字にしておけば、 今までの投稿については、以前のパスワードが変わらず使えるかなあ、と 一瞬考えたのですが、D/B流出の時にパスワードがばれる危険性を考えて いるのだからそれじゃ本末転倒ですね (^^; 今までの投稿が削除できなくなってもおそらく誰も困らないでしょうから (いまさら「しくじったので書き直し」はないでしょうから)、今度時間が できたときに修正しておきます。

http://cpan.org/ に行って「PDF」で検索してみるのもよいかも。

# どこにぶら下げようか迷いました。。 僕の職場の新人研修は、いきなりJavaです。 会社的には「今はJavaの案件が一番多いから」ぐらいの理由で選んでいるんだと 思います（情けない。。） で、そんな新人研修をしてきた後輩を見る限り、「オブジェクト指向から入れば 簡単」ということでは無さそうです。 確かに、概念的な部分の吸収は早いように感じます。 でもそれって、ただ単に「何も疑問を持たないから」ってだけなんですよね。 しかも、実際のコードでは、オブジェクト指向を「使えない or 使わない」んです。 結局、「それが出来ると何がうれしいのか」ってことを実感してからじゃないと、 使いこなすことが出来ないんじゃないかと思います。

>とりあえず俺的には入門者に最初に教えたいのが継承派生です。 あ、ここでの「入門者」は「プログラム経験があって、でもオブジェクト指向は入門者」です。 今年の新入社員君がプログラム経験無いようなら、いきなり C++ など逝ってみたいと思います。

ウチは組み込み屋さんなのでアセンブラ経験はほぼ全員が、C 経験は半数が、もっています。 C++ を本格的に使っているのは俺だけです。 次のプロジェクトでは後輩君に C を飛ばして C++ をいきなり使わせようとたくらみ中です。 # どうなることやら... とりあえず俺的には入門者に最初に教えたいのが継承派生です。 「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 ある程度プログラム経験がある人だと、これで結構ぐらぐらしてくれます。

あら、私のネタ振りから別スレッドに。 前橋さん> 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 前橋さん> 見てきた人の経験を聞いてみたいです。 サンプルが少なくて申し訳ないですが、友人に 1 人、Java から本格的にプログラミングを始めた人がおります。 それ以前も C 言語を触ったことがあるのですが、"Hello, World." 程度でした。 私>「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 私> 何しろ邪魔する前知識が無いですから。 実はこれ、その友人のことなんです。 今度彼と会う機会があるので、もっと詳しくインタビューしてみますね。

> これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して > いますでしょうか。それとも、既にテーブル内容が流出していることを > 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 テーブル内容が流出していることを前提にしています。 > 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 そうです。 > これは、ひとつのパスワードがばれても、同じハッシュになっている他の > パスワードが芋づる式にばれることはない、ということでしょうか? 違います。辞書攻撃に必要な計算量が増えるという意味です。 > 同時間で、ほぼ同数のパスワードが抜かれてしまいそうに思う > のですが。 salt があると、探索空間が salt のビット数分広がるため、 辞書攻撃に要する時間が長くなります。以下のページにも、 同様な示唆があります。 http://www.itmedia.co.jp/enterprise/0307/24/epn09.html http://www.microsoft.com/japan/msdn/library/ja/f_and_m/html/vxconprotectingpasswordcredentials.asp データベース中には複数のMD5化されたパスワードが存在する わけですが、salt がないと、単一の辞書を使って、全ての パスワードに対する試行を行うことができます。これに対し、 salt があると、2 の salt のビット数乗 の辞書が必要になる わけです。 > 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 これを気にするのであれば、salt とプログラム埋め込みのsecret の両方を使うのが良いと思います。どちらか片方だけであれば、 salt の方を選ぶのが良い習慣だと思います。

すみません、風呂の中で考えてたらちょっとわからなくなりました。 >今のやり方だと、仮に異なるユーザが同一のパス >ワードを利用していた場合、その事実を管理者は >知ることができるわけですが、salt を使えばその >心配もありません。 これはその通りだと思います。また、クラッカーにD/Bを継続的に監視されて いる場合、いろいろなパスワードで書き込んでみることで、パスワードを 推測することもできることになります。 >また、仮に "秘密" や salt が洩れた場合に、辞書 >攻撃への耐性が若干高くなります。(salt があると、 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して いますでしょうか。それとも、既にテーブル内容が流出していることを 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 前者だとすると、"秘密"やsaltが漏れていようがいまいが関係なさそうですし (そもそもレンタルサーバ業者にプロセス止められそうですが)、 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これは、ひとつのパスワードがばれても、同じハッシュになっている他の パスワードが芋づる式にばれることはない、ということでしょうか? しかし、実際問題こんな掲示板の投稿が消されてもさしたる実害はないわけで、 問題は「お金が絡むようなところと共通のパスワードを使う人がいたケース」だと 思っています。 そんなユーザは投稿ごとにパスワードを変えたりしそうにないですし(そんな ユーザに限らずともそうなんじゃないかと思いますが)、同一ハンドルの人は 1回しか調べない、程度のことで、同時間で、ほぼ同数のパスワードが抜かれて しまいそうに思うのですが。 どちらが安全か、という問題以前に、まず私の認識は合ってますでしょうか?

便乗して・・・ Javaを教えるほうにC言語などを知らないで育った方が 一体どれくらいいるのかも知りたいかも。 （あくまで参考として）

まったく違う話題にシフトします。件名とスレッド変えました。 >「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 >何しろ邪魔する前知識が無いですから。 「Cなどの言語を知っている人は、今までの知識が邪魔をしてオブジェクト指向の習得が 難しいけど、最初からオブジェクト指向を覚えるのなら簡単だ」 とたまに聞きますけど、これはどの程度事実なんでしょうか。 たまに、上の言葉の後ろに「なにしろオブジェクト指向は自然だから～」というのが 続いたりすると、どうも眉に唾をつけたくなります。私の場合。 古い知識が邪魔をするという傾向はもちろんありますが(FORTRAN屋やCOBOL屋が設計した Cプログラムにどれほど泣かされたことか)、じゃあまったくの初心者がJavaから 入門したとして、最初に動かすプログラムがhello, world. だったら、結局のところ 手続き指向→オブジェクト指向の流れで習得することになるように思います。 Javaの場合、hello, world.といってもアプレットから入るんでしょうか。 その場合、#include <stdio.h>なんかとは比べ物にならないくらい「とりあえず こう書いとけ」的な記述が増えてしまいますが、まあ、それは「いずれ分かる」と 言っておけばよいでしょう。 んで、ただブラウザにhello, world.と表示されるだけのプログラムから 順次発展していく場合、どの辺で「オブジェクト指向」を意識することになるんでしょうか。 クラスがアプレットしかなければ、メソッドも単なる関数ですし、インスタンスフィールドは グローバル変数と同じです。 GUIのボタンを作ったりするところは、「決まり文句」としか思ってもらえない気も するんですが、こういうところから、だんだんオブジェクト指向になじんでいったり するのかな。 私自身はBASICから入ったクチですし、新人にJavaを教えたことは何度となくありますが うちの会社では新人はまずCの研修を受けてくるので、「オブジェクト指向から入門」 した人の観察例が私にはほとんどありません。 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 見てきた人の経験を聞いてみたいです。

>つまり、"秘密" はソース埋め込みにせず、メッ >セージごとに乱数で生成することにし、salt 自体も >message表に記録しておくわけです。 毎度ながらご指摘ありがとうございます。 掲示板のパスワードとしてどこまでの仕様が必要であるかはさておき、 この記事を読んで「パスワードの暗号化はこうすれば万全なんだ」と思ってしまう人が いるとまずいので、取り急ぎ注釈をつけました。

PHPとMySQLで掲示板を作る / 削除 / 削除系ソース の hash_user_password() ですが、"秘密" は、 UNIX パスワードなどで使われている salt の やり方にするのはどうですか？ つまり、"秘密" はソース埋め込みにせず、メッ セージごとに乱数で生成することにし、salt 自体も message表に記録しておくわけです。 今のやり方だと、仮に異なるユーザが同一のパス ワードを利用していた場合、その事実を管理者は 知ることができるわけですが、salt を使えばその 心配もありません。 また、仮に "秘密" や salt が洩れた場合に、辞書 攻撃への耐性が若干高くなります。(salt があると、 同じ辞書は一つのメッセージにしか使えないため、 探索空間が広くなる)

私も横からすんません。 norge さんは「プログラミング自体初めての人」と「オブジェクト指向は初めての人」を一緒くたにしちゃって るんだと思うんですけど。推測ですが。 まぁ、「Java (オブジェクト指向言語) を学ぶ前に、C 言語 (手続き指向言語) で得た知識は一度きれいに忘れ てください」って入門書もあったりしますし、私も読んだことがあります。 そういうやり方も、アリかなぁとは思うのですが。一応書けるようにはなるし。 でもですねぇ…、Java で得た知識と C 言語で得た知識がきれいに結びつかないのは苦痛でした。 入門書を読み、サンプルをグジグジいじくっては、覚えているだけで 3 回は挫折してしまいました。 とにかく、自分が何をやっているのかを、感覚としてさっぱり捕まえられなかった。 # こういう感覚はプログラマとして「まっとう」だと思ってます。 # 挫折しといてナンですが…。 「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 何しろ邪魔する前知識が無いですから。 かと言って、C 言語経験者を「古い知識に縛られたロートル」だとも思いません。 低レベルな概念と高レベルな概念がきれいに結びついた知識体系を獲得した時、飛躍的に応用が利くようになる からです (ちょっと大げさかな…)。 # アセンブラ上がりの高級言語プログラマであれば、また違ったセンスや発想を持っているように思います。 知識というのは、互いに結び付けられて意識下で体系化されてこそ意味を持ちうるわけで、その結びつきを強化 したり手繰り寄せたりしないと、新しい知識や発想に行き着けないと思ってます。私。 あれ、これ、前橋さんの意見の要約にしかなってないかも…。

>プログラムを始めたばかりのものです。 >Perlで作成する事になりました。 >PDFを表示する仕様があります。 >どの様にすればよいかわかりません。 >教えて頂ければありがたいです。 私はPerlにもPDFにも詳しくないですが… PerlとPDFをキーワードに、Googleで検索しました(日本語限定)。 http://www.google.co.jp/search?hl=ja&q=Perl+PDF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja 1件目がこれ。 http://www.warpstream.co.jp/package_pdfserver.html?afl=cgirescue1 商品のようです。 お金を出すのが嫌なら、2件目がこれ。 http://hp1.jonex.ne.jp/~nakajima.yasushi/ PDFJというモジュールがあるようです。 PDFJでGoogleすると、結構有名なようですね。 ただ、ざっと見て、ライセンスの規定がよくわかりませんが… また、1件目のページの中に >PDFLibなどのライブラリで作成することはできますが、 とありますから、PDFLibとPerlでGoogleするのも手です。これも商品のようですが。