• ベストアンサー

短いハッシュの作り方

特に言語には関係がないのでこのカテゴリに。 md5やsha1でハッシュを作ると、32桁か40桁で大文字小文字の区別がないものとなります。 以下のような短いハッシュはどのように作るのでしょうか。 http://am6.jp/asRleJ http://twitpic.com/12zs0a http://bit.ly/axe7hu

質問者が選んだベストアンサー

  • ベストアンサー
  • mtaka2
  • ベストアンサー率73% (867/1179)
回答No.4

いくらでも方法はあるので、質問者さんが挙げられているサイトが実際にどうやっているかはわかりませんが、 6文字程度の文字列では、「衝突しないハッシュ関数」を作るのは非常に困難であり、「衝突が発生する」ことがあるのを前提にして設計しないとといけません。 こういう場合、「ハッシュテーブル」におけるハッシュの取り扱いが参考になるでしょう。 ハッシュテーブルにおけるハッシュ関数は、名前が同じ「ハッシュ」でも、取り扱い方はmd5やsha1などとは異なります。 ハッシュテーブル用のハッシュ関数にはいろいろありますが、 中でもKnuth のアルゴリズムが有名です。 そういったハッシュ関数を使って最大値[62^6]のハッシュを生成し、それを 62進数に6桁に変換して、それを文字列化すればいいでしょう。 Knuth のハッシュ関数: http://d.hatena.ne.jp/yamanetoshi/20090517/p1 ハッシュが衝突した場合の処理: http://tortoise1.math.ryukoku.ac.jp/~takataka/cpro/doc/hash.html#hash2 (62^6は32bitより大きいですから、64bit整数で計算する必要がありますので要注意) 以上が文字列から短いハッシュを生成する方法の定番ですが、 短縮URLのようなシステムの場合、そもそも「ハッシュ関数」を使う必要すらないです。 そういうシステムでは、「URL→短縮文字列」および「短縮文字列→URL」の変換を、データベースに登録して行いますから、そもそも「URLから短縮文字列が算出できる」必要はどこにもありません。 乱数で適当なランダム文字列を生成し、それがデータベースに登録されていなければ採用、 DBに登録済みだったら、登録されていない文字列が出来るまでランダム生成を繰り返し、 で、出来た文字列と、元のURLの組をデータベースに登録 でOKです。 あるいは、もっと単純に、登録順に振られた番号から、それをそのまま62進変換するだけ、という方法でも実現できます。 (回答3の方法ですね)

helonpa
質問者

補足

ご回答ありがとうございます。 > 乱数で適当なランダム文字列を生成し、それがデータベースに登録されていなければ採用、 DBに登録済みだったら、登録されていない文字列が出来るまでランダム生成を繰り返し 最大値(≒桁数)と増加割合の問題だとは思いますが、ある程度の登録が発生した後(例えば最大値の半分とか)では「DBに登録済みだったら、登録されていない文字列が出来るまでランダム生成を繰り返し」のコストが勿体無いのではないかと考えておりました。 ハッシュを使用しつつ、衝突時には回避策を取るのがバランスが良さそうですね。 > あるいは、もっと単純に、登録順に振られた番号から、それをそのまま62進変換するだけ、という方法でも実現できます。 用途によりますが、類推が出来ない方が良い場合が多いと思いますので、連番以外の方法を知りたいと思っていました。 いくつかご回答を頂いてみると、6桁のハッシュというのは言語共通などで実装された一般的な関数などではなく、みな独自実装されているという事のようですね。 特に最近、短縮URLに限らず、6桁程度のハッシュに見える値を見かける事が多かったためにこのような質問をさせて頂きました。

その他の回答 (5)

  • osamuy
  • ベストアンサー率42% (1231/2878)
回答No.6

>DBのカウンタ値を元に「短いURLを生成」という処理は、つまりはハッシュと同じではないでしょうか。 ハッシュ関数は、入力が一緒なら返値は常に同じですが、 カウンタはそうじゃないです。同じURLでも異なる値を返しても問題ないからです。 カウンタであれば、 ・計算が楽(+1すればよい。というかたいていのDBMSはオートインクリメントをサポートしてる)。 ・衝突しない。 ・元のURLを導くのが楽(バイナリサーチあるいは、配列添え字アクセス)。 ――というメリットがあります(実際には、カウントするデータベースが1つだけだとスケールしないだろうから、負荷分散のための名前空間的なものを含んでるでしょうが)。

参考URL:
http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0
helonpa
質問者

補足

回答ありがとうございます。 > カウンタであれば、 > ・計算が楽 > ・衝突しない。 そうなのですが、他のURLが類推できない方が望ましいため、連番をそのまま使う事ができないという事です。

  • notnot
  • ベストアンサー率47% (4848/10262)
回答No.5

#1です。 >41bitというのはどのような計算でしょうか。 すいません。何故か間違えて62の7乗を計算してました。 >MD5よりもだいぶ範囲が狭まる状況で適当に切り出してしまうと、さらに衝突可能性を高めるなどの問題が考えられますでしょうか。 どういうハッシュ関数を作るにせよ、短ければ短いほど衝突する可能性が高まるのは当然ですよね。衝突したら、タイムスタンプやプロセス番号を加えるなどして、衝突しなくなるまで繰り返す。認証や検証のためのハッシュと違って、あくまで、まんべんなく散らばったキーの作成のため(他のキーを推測されにくくするため)なので、最初に衝突しても問題ありません。 他の方が書いているように、ハッシュである必要すらなく、乱数でもいいですよね。ただ、高トラフィックの場合、マルチタスクでキーを発番するということを考えると、ハッシュの方が楽な気がします。疑似乱数だと前回値の保存が面倒。ハードウェアの乱数発生器を使うと却って時間がかかったり。

  • osamuy
  • ベストアンサー率42% (1231/2878)
回答No.3

> axe7hu この手の短いURLは、一方向ハッシュ関数を使ってないのでは。 単にひとつカウンタを持っていて、入力されたURLにそのときのカウンタの値をデータベースに登録。紐付けたカウンタ値を元に短いURLを生成して返す――というだけのような。

helonpa
質問者

補足

> 単にひとつカウンタを持っていて、入力されたURLにそのときのカウンタの値をデータベースに登録。紐付けたカウンタ値を元に短いURLを生成して返す――というだけのような。 DBのカウンタ値を元に「短いURLを生成」という処理は、つまりはハッシュと同じではないでしょうか。 DBのカウンタ値を元にするか、入力値を元にするかという違いだけな気がします。

  • kmee
  • ベストアンサー率55% (1857/3366)
回答No.2

MD5等は (1)入力(文字列等)のハッシュ(値)を求める (2)求めたハッシュ値を一定の法則で文字列にして人間が扱いやすいようにする という2段階で処理されています。 (1)はハッシュ関数と呼ばれるもので ・入力の特徴をなんらかの値で表わす(ハッシュ値) ・入力が違う時は値も違うことが望ましい というものです。 MD5の場合は、入力からMD5独自の計算方法で128bitの整数を求めます。 プログラム中では、この値のまま使用することも多いです。 (2)は(1)の値を1対1に相互変換できる文字列にするもので、MD5,SHA1等は単純に16進数文字列にしています。 例えば、MD5(128bit)を 0~9a~zの36種の文字を使って36進数 で表現すれば 36^24 < 2^128 < 36^25 なので25文字で表現できます。0~9A~Za~zの62進数なら22文字です。 前置きが長くなりしたが、例にあるような短いハッシュの作り方です ・(2)で使う文字の種類と文字列の長さを決める。 例示されたものは、0~9A~Za~zの62種で6文字と予想されます。 ・↑でハッシュ値の範囲が解る( 0 ~ (文字種^文字数)-1 )ので、ハッシュ値がその範囲になるようなハッシュ関数を作る。 例示されたものは、62種6文字とするなら0~(62^6)-1までの値になるように計算しています。 2^35<62^6<2^36なので、コンピュータで扱いやすいように35bitや32bitの値にしているかもしれません。 難しいのはこのハッシュ関数で、これが正解、というものがありません。 MD5とSHA1とでも違います。

helonpa
質問者

補足

回答ありがとうございます。 > 難しいのはこのハッシュ関数で、これが正解、というものがありません。 > MD5とSHA1とでも違います。 長さ(範囲)や表現に使用する文字種を指定可能なハッシュ関数などがあるのかと思ったのですが、特に無いという事ですね。

  • notnot
  • ベストアンサー率47% (4848/10262)
回答No.1

独自のハッシュ関数を作ればどうにでも出来ます。 英大文字+小文字+数字で、6文字とすると、62進数(26+26+10)で6桁なので、約41ビットに縮めればいいことがわかります。 手抜きをするなら、MD5アルゴリズムで128ビットにして、その中の末尾なり先頭なり途中なりの41ビットを取りだして文字化すればいい。

helonpa
質問者

補足

回答ありがとうございます。 > 独自のハッシュ関数を作ればどうにでも出来ます。 一般的な一般的はハッシュy関数は無いという事ですね。 > 英大文字+小文字+数字で、6文字とすると、62進数(26+26+10)で6桁なので、約41ビットに縮めればいいことがわかります。 41bitというのはどのような計算でしょうか。 35bit < 62^6 < 36bit という計算とは違いますか? > 手抜きをするなら、MD5アルゴリズムで128ビットにして、その中の末尾なり先頭なり途中なりの41ビットを取りだして文字化すればいい。 MD5よりもだいぶ範囲が狭まる状況で適当に切り出してしまうと、さらに衝突可能性を高めるなどの問題が考えられますでしょうか。

関連するQ&A

  • パスワードのハッシュ化について

    ユーザー登録させるようなwebサイトを作ることになりました。 ググッたところパスワードはハッシュ化させDBへ、っていうのが通常らしいんで、 sha256を使って変換しようと思います。 質問(1)ハッシュ化させる元の文字列には文字数など何か制限はないんでしょうか。 質問(2)ハッシュ化させるときにくっつけるsaltは何桁くらいにするのが一般的なんでしょうか。 教えてください。

  • MessageDigestについて

    JavaではMessageDigestを利用して"MD5"や"SHA1"のような暗号化を行う事が出来ますが、これらで作成したハッシュ値はbyte[]型になっていて、表示するにはちょと問題があるかと思います。 そこでご質問ですが、MessageDigestで作成したハッシュ値を表示に適した文字に変えるようなAPIは存在するのでしょうか? よく"md5=990e8673jy8328968hu…"のような形になっているのですが、どのように文字列を作成しているのかが分かりません。 ご存知の方がおられましたら、ご回答お願いいたします。

    • ベストアンサー
    • Java
  • ハッシュ化で元の文字列の方が長くても大丈夫ですか?

    例えば1000桁の文字列をphpのhash()でsha512を用いてハッシュ化した場合、重複の危険性は 無視出来る程度なのでしょうか。 ご存知のかた、お手数をおかけいたしますがご回答のほどよろしくお願い致します。

  • ハッシュを使った擬似乱数

    予測不能な擬似乱数列を生成する際に、よく一方向ハッシュの性質を利用する 場合があります。一方向ハッシュの生成源として内部状態が与えられますが、 内部状態のbitサイズはどの程度にしたらよいでしょうか?   [種(カウンタの初期値)]        |        |        ↓ ┌→[内部状態(カウンタ)]―┬―→(一方向ハッシュ)――→擬似乱数列 |                 | |                 ↓ |               [1増加] |                 | └―――――――――――┘ ※ 暗号技術入門 秘密の国のアリス 結城 浩 著      ――第12章 乱数 Fig.12.5 より 極端な例として鍵(種)のサイズを32bit(C言語でunsigned long型)、値を0とします。 |0000 0000|0000 0000|0000 0000|0000 0000| 上記の値でハッシュ値を取ります。ハッシュアルゴリズムがSHA1の場合、 以下のような値が得られます(と思います)。 a = -1099956234 b = -343932961 c = -1287651379 d = -84150665 e = -1099170433 これらの値から鍵の値を得ることは困難なので、ハッシュ値によって生成された 擬似乱数は予測不能であるといえます。また、鍵の値を1だけ加算させて次の擬似乱数 を生成します。一般的にこのようにして乱数列は生成されます。 上記の例では32bitのとり得る値は0~4294967295です。鍵の値を一つずつ試し ていけば、それほど時間をかけることなく乱数の予測不能性は破られてしまいます。 ここで鍵の値を256bitとしました。 |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| しかしこれだと1加算しただけではビット全体に対して変化が少なすぎます。 |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0000| |0000 0000|0000 0000|0000 0000|0000 0001|← 2005年に中国の大学の研究チームによってSHA1の弱衝突耐性が破られてしまいました。 現段階ではSHA1に変わる新しいアルゴリズムは発見されていません。(SHA2が作られましたが、 これはSHA1のbit数を拡張しただけで基本設計は変わっていません)なのでハッシュ値を 生成させる値もなるべく変化に富んだ値を与えることが推奨されています。 まとめると、   ・鍵(種)を総当り攻撃されないようにbit数を大きくしなけらばならない。   ・bit数を大きくすると1加算したときに変化が小さすぎる。   ・最初の図の手法は同記の文献に書いてあったもので、なるべく変えたくない。    (実際に使われる手法はある程度保障されているから) の制約があります。なので”bit数をどの程度にしたら適当か???”というのが質問です。 また、これらの問題を打開する方法もあればよいのですが、、、

  • パスワードの最良な決め方について(長文)

    パスワードを最大限に複雑に決めたいとします。 当然、覚えられないので、適当な言葉で決めて、seedを付けてハッシュ関数へ入力し、出力をそのままパスワードとして使うとします。 (ハッシュ関数の出力は16進数ですが、文字数を少なくしたいので、使える文字を全て使用して、文字へ割り当てます。) seedは秘匿し、適当な言葉にあたる部分はブログ等に公開でもいいからメモっておくとします。 例えば、この質問サイト(OKWaveからログインしてます)であれば、 OKWavePassword_change#_0 といったような言葉を決めて、SNSのプロフに載っけておくとかです。 実際に使う際には、頭に(どこでもいいのですが)seedを付けて、 myseedOKWavePassword_change#_0 のようにして、ハッシュ値を取り、文字割り当てしてクリップボードへコピーして パスワード欄に貼り付けるかんじです。 ここからが質問です。 【質問1.ハッシュ関数はどれを使えば良いでしょうか?】 SHA-2シリーズはlength-extension攻撃に弱いので、HMACの形式にして使わなければならず、またその場合、Windowsのコマンドプロンプトで使える手軽な実装が見つからないのもあって(コマンドプロンプトにこだわる訳は要望があれば補足で説明したいと思います)、使用は避けたいです。 そこで、SHA-3シリーズが策定されてるようなので、この中で最大のビット数のものを選べば良いと思っていたのですが、Wikipediaを見たら、SHAKE128、同256というのがあり、読んでみると、 出力長を、任意に設定できる そうですが、だとすると、SHA-3の最大ビット数(SHA-3 512)と比べて、上述の使い方で考えると、どちらが良いでしょうか? もしくは、他により良いハッシュ関数がありますか? というのは、SHA-3 512では(というか、SHAKE以外のSHA-3では)出力長は固定なので、必要であれば(ほぼ全てのケースだと思いますが) そのパスワードで使用できる最大文字数にしなければならず、 その方法としては、文字割り当てまで終わってから、ただ単に頭から文字数分取るとか、間の文字を抜いて詰めるくらいしか思いつかないので、 それでどの程度、一様性が下がって(偏りが生じて)、危険になるかは、良く分からないのですが、 それであれば、512ビットより落ちる256ビットであるとしても、SHAKEであれば、ハッシュ値が得られた時点で過不足の少ない(0にはならないみたいですが、実装のせい?)情報量に収まっているので扱いやすいこともあり、いいかなと思っているのですが、どうでしょうか? 要するに、512ビット固定長のハッシュ値を文字割り当てしてから(16進表現の時点では難しそうなので)、頭から一定の大きさまで削った場合と、 SHAKE256で最初から過不足の少ないハッシュ値を得て文字割り当てした場合とで、どちらがよりマシかということになると思いますが…… 例えば、例としてGmailのパスワードで考えると、確か、ASCII印字文字95種フルフルで使えて最長64文字だったと思いますが、 この場合だと512ビット固定長のがマシになりそうですが…… (512ビットを95進数表現すると78文字(桁)だから、78文字の先頭から文字を取るなり、間を詰めるなりして64文字にするほうが、256ビット分(95進数で39桁)を無理に引き伸ばすより安全そうというのが理由) ↑のようなパスワードを使うことが多ければ、というか多くなくても今後10年くらいは変えたくないので(SHA-1やSHA-2の寿命から;2はまだ死んでませんが)後々の事を考えればSHA-3 512で統一しておいたほうが結局無難でしょうか。 或いは、どっちもダメということもあるのでしょうか…… そもそも、ハッシュ関数を使うという考え方自体がダメだったりするのでしょうか…… 【質問2.仮にSHAKE256を使うとすると、出力長はどうやって求めれば良いでしょうか?】 例えば、OKWaveでは、パスワードの文字条件が、 使える文字がa~z, A~Z, 0~9, -, _で、文字数が最大10文字だそうですが、 この場合、パスワードの総パターン数を16進数で表した文字数にすればいいのでしょうか。 具体的には、総パターン数は64の10乗通りで1152921504606846976個、 16進数にすると1000000000000000で16文字で合ってますか? また、多くの実装では、出力値が0起算のため、例えば今の例だと実際に取り得る値は 0~((64の10乗)-1) の範囲になるかと思いますが、つまり、 000000000000000~FFFFFFFFFFFFFFF が実際に出てくる値の最小~最大となるため、15文字で設定すれば良いということでしょうか? 【質問3.具体的な例で確認したいのですが?】 SHAKE256で15文字として、seedはなしとすると、 OKWavePassword_change#_0 のハッシュ値は 911C7E7009C307 と出ましたが合ってますか。(HashSum使用←バイト単位でしか設定できないので、8byteだと文字割り当て後、11文字になるパターンが有り得るので7バイトで設定(1byteは16進数2文字)) またこれを64進数に変換すると、 02 17 07 07 57 48 02 28 12 07 になると思いますが合ってますか。 またこれを文字割り当て(ASCII文字コード表の通りの順番で、使用できる文字だけ拾って割り当て)すると、 1G66tk1RB6 となりましたが、合っているでしょうか。一応10文字にはなりましたが。 あと、HashSumがバイト単位の設定なので7バイトにしましたがこれだと9文字になるパターンも有り得ますよね。 その場合は10文字になるまで、入力値のOKWavePassword_change#_0の最後の0を1とか2とかに変えていけばいいかと思ってますが。 まぁそれ用に項目を置いてOKWavePassword_dummy#0_change#_0とかにしてこの場合dummy#の直後の数字を変えるという決めにするとかしとけば、パスワードを今まで何回変更したか知りたい(そんな要望あるのかはともかく)ときにゴッチャにならないで済むけど。 みたいな細かい問題は出てくると思いますが、このように柔軟に対応できると思っていますが、何か他に対応の難しい問題はありそうですか? 【質問4.全体的にどうでしょうか?】 みたいな。 なんか結局、今まで考えていた通りにSHA-3 512でやっとけば良さそうな気がしてきましたが、全体通して総評ください。 以上、よろしくご回答の程、お願いいたします。

  • 一意(ユニーク)かつ、ソートに対してランダムなIDの発行方法

    随時増加するあるデータに対して、一意なIDを割り当ててゆきます。 通常は、1, 2, 3, … と連番を割り当てて行けば一意なIDになると思います。 その上で、IDでソートした時に発行順に並ぶのではなく、順番がランダムになるようにしたいのです。 (アルゴリズムを知らない人から、発行順を推測されないようにしたい。) そこで考えたのが、"1", "2", "3", …という文字列に対するハッシュ(SHA1やMD5)ですが、sha1("1"), sha1("2"), sha1("3"), …とIDを発行していった場合、IDが重複してしまう可能性を心配しています。(とても低い確率ではあることは分かっていますが、皆無ではありません。) ハッシュ関数を利用する他に、「一意」で「ランダム」で「衝突の可能性がゼロ」である文字列の生成方法はありませんでしょうか?(可能性がゼロというのは物理的に不可能だと思うので、例えばSHA-1であれば、160bitのハッシュが生成されますが、2^160個のIDを発行しても重複しない、ということを考えます。) 一応、規模は1000万ID程度を考えていますが、もっと大きなオーダーでも衝突しないに越したことはありません。

  • あらゆる種類の情報をハッシュで一定量に揃えれるなら

    0バイトの情報(情報が無いという情報)でもデータセンター1棟丸ごとの情報でも、もし仮にハッシュ関数を通すことができれば、一定のビット数で要約ができるのなら(他の情報と区別がつけられるのなら)、情報の表す意味と、その情報の特定性は、切り離す方向で考えたほうがいいのでしょうか。 例1 プログラムの作成時、関数名を決めたいが文字数制限があってうまく決められない→ 自分で充分に満足するような関数名をまずメモ帳にでも書いてみて、プログラムソース上はそのハッシュ値で関数名を決めてしまう。(当然、読みづらいソースになるので、HTMLのブラウザのような専用ビューワやエディターで閲覧編集する) 例2 あるWebサービスである名前でIDを取りたいが既に他人に取られていて自分のものとして使えない→諦めてハッシュをIDとする(それでも取られていたら変更回数として0でも末尾につけてまたハッシュする) そのWebサービスで取りたかったID名との対応表みたいのもまたネットに置いておく(オンラインブックマークにコメント記入するなど)

  • Visual Studio 2008 評価版イメージのハッシュ

    毎度のことながら OKWave のカテゴライゼーションが変で適切なカテゴリがないことと、質問に出てくる用語も知らない人に別カテゴリで変レスされてしまいましたので、ここで質問させてください。 下記 2 つのファイルをいくつかのダウンロード マネージャで何度かダウンロードしたのですが、ダウンロード途上でファイルが壊れてしまいます。回線品質が悪いのか、なぜ壊れるかはとりあえずおいといて質問です。 インストールやその後の試用で問題ない方、複数回ダウンロードされた方でそれぞれの回のハッシュが一致した方など、状況的に壊れていないであろうと推定されるファイルの SHA1、ないし MD5 ハッシュをそれぞれのイメージについて教えてください。もしくは、Microsoft がハッシュをどこかで公開しているなら、その場所でもよいです (見つかりませんでした; Microsoft がなぜそのくらいしてくれないのか不思議です)。 VS2008ProEdition90dayTrialJPNX1435988.iso Visual Studio 2008 Professional Edition (90 日間評価版) http://www.microsoft.com/downloads/details.aspx?FamilyId=83C3A1EC-ED72-4A79-8961-25635DB0192B&displaylang=ja VS2008MSDNLibraryJPNX1425418.iso MSDN Library for Visual Studio 2008 http://www.microsoft.com/downloads/details.aspx?familyid=6FF3BC60-32C8-4C22-8591-A20BF8DFF1A2&displaylang=ja

  • Visual Studio 2008 評価版イメージのハッシュ

    毎度のことながら、OKWave のカテゴライゼーションが変で適切なカテゴリがないので、ここで質問させてください。 下記 2 つのファイルをいくつかのダウンロード マネージャで何度かダウンロードしたのですが、ダウンロードした後のファイルが壊れているようです。 インストールやその後の試用で問題ない方、複数回ダウンロードされた方でそれぞれの回のハッシュが一致した方など、状況的に壊れていないであろうと推定されるファイルの SHA1、ないし MD5 ハッシュをそれぞれのイメージについて教えてください。もしくは、Microsoft がハッシュを公開しているなら、その場所でもよいです (見つかりませんでした; Microsoft がなぜそのくらいしてくれないのか不思議です)。 VS2008ProEdition90dayTrialJPNX1435988.iso Visual Studio 2008 Professional Edition (90 日間評価版) http://www.microsoft.com/downloads/details.aspx?FamilyId=83C3A1EC-ED72-4A79-8961-25635DB0192B&displaylang=ja VS2008MSDNLibraryJPNX1425418.iso MSDN Library for Visual Studio 2008 http://www.microsoft.com/downloads/details.aspx?familyid=6FF3BC60-32C8-4C22-8591-A20BF8DFF1A2&displaylang=ja

  • パスワードの決め方について(SHA3orHMAC)

    パスワードの決め方や保管の方法について、分からなくなってきたので基本から質問させてください。 1.パスワードをホームページ等でネットに公開したら危険ですか? 2.1.はただそのまま公開したら危険なのでやってはいけないと思いますが、暗号化して、パスワードのパスワードがないと解けない状態にして公開しておけば安全ですか? 3.2.の暗号化の手法として、暗号学的ハッシュ関数を用いて、ハッシュ値 h をパスワードにすれば、暗号化したパスワードを公開しても安全ですか? 4.3.について、パスワードにしたハッシュ値 h を公開したのではパスワードをそのまま公開していることになり、危険なため、ハッシュ値 h を算出する暗号学的ハッシュ関数の実行コマンドをホームページ等で公開し、パスワードを確認したいときにはこのコマンドを実行してハッシュ値を得ることにすれば、安全ですか? 5.4.について、暗号学的ハッシュ関数はSHAシリーズなどがありますが、この実行コマンドは広く一般に利用できる状態で提供されているため(ハッシュ計算するソフトウェアやWebサイトなど)、SHAなど既存の暗号学的ハッシュ関数を用いるのではなく、自分で専用に暗号学的ハッシュ関数を考案し、また実行コマンドやソフトウェアを作成する必要がありますか? 6.5.が大変な場合、SHAなど既存の暗号学的ハッシュ関数を用いて4.を実現するにはどうしたらいいですか? 7.4.について、コマンドがパスワードの数だけ存在すると管理が大変です。コマンドは共通にして、オプションスイッチで区別することはできませんか? 8.7.について、コマンドは既存のソフトウェアをあらかじめインストールしておき、オプションスイッチを含む実行コマンド文のみをHP等で公開しておくことはできませんか? 9.6.7.8を実現するには、オプションスイッチのうちのひとつをパスワードのパスワードとして、このスイッチのみを非公開とすれば良いですか? 10.9.について、コマンド文はどのように記述すれば良いですか?たとえばハッシュ関数H()、出力h、パスワードの対となる文字列(IDとかファイル名等)m、パスワードのパスワードをk、||は結合とした場合、 H(k||m)=h と書けると思いますがこれをH(m)として公開し、kはあらかじめPC等コマンドを実行する環境で設定しておけば良いですか? 11.10について、暗号学的ハッシュ関数SHA2シリーズ(256bit等)を用いた場合、Merkle-Damgård 構造であるため、length-extension 攻撃され、危険ですか? 12.10.11.について、暗号学的ハッシュ関数SHA3シリーズを用いた場合、SHA2シリーズのハッシュ関数と異なりスポンジ構造であるため、length-extension 攻撃は成り立たず、安全ですか? 13.12について、length-extension 攻撃以外の危険性はありますか?