- 締切済み
暗号学的ハッシュ関数でbit長が適切って作れますか
SHA256が(224かもですが)最小bit長で、 入力に1bitでも、また2bit以上入力値全体まで、異なれば、 出力のうちほぼ半数のbitが反転する、かつその 反転するbit位置は複数の入力値に対して法則性はなく、 ほぼランダムである。 という暗号学的ハッシュ関数であるのは、正しいですか? また、データの暗号化に使われるパスワードは4096bitを推奨との 事ですが、 SHA4096などその時に合った暗号学的ハッシュ関数を 作るのは難しいのですか? 素人考えでは、今256bitで衝突が見つかってないなら 4096bitならbit長大きいのだから作れそうな気もしますが やはりそういう問題ではないのでしょうか? もし作れるとしたら、データの暗号化に使うパスワードを SHAなんとか・・・の出力そのまま使っては、危険でしょうか? というかデータに限らず認証のパスワードでも SHAなんとかの出力そのままを使うのは何かまずいのでしょうか? もしできたらパスワードを覚えなくてよいのでいいかと思ったのですが。 パスワードは「IDのパスワード」をSHAなんとかに通した値ということで。 IDは「種パスワード+なんとかのサイト」をSHAなんとかに通した値ということで。 種パスワードはしょうがないからネットをパスワードの決め方とかで検索して 出てきた方法を見て理解して自分なりにアレンジして、最後にちゃんと頭に記憶して。 とりあえずここまで、どうでしょうか。
- みんなの回答 (3)
- 専門家の回答
関連するQ&A
- ハッシュ関数について質問です。
プログラミング・数学? 初心者です。 IDやパスワード管理によく出てくる一次方向(ハッシュ)関数ですが、 よくパスワードとSALTを一緒にしてハッシュ関数を通してハッシュ値を取得しますよね。 そしてその結果(データベースなどに記録済み)とログイン時に入力した値とを照らし合わせるわけですが、 昔まだ若いころ、これとは別のタイプのハッシュ関数を使用したことがあります。 それはある(パスワードなどの)値をハッシュ関数で処理すると「いろんなハッシュ値」が生成され、 そのハッシュ値から当然パスワードは予測できないのですが、 しかしその複数のハッシュ値は全て、そのパスワードから生成されたハッシュ値だということは分かる、という関数を使用したことがあります。 その時はperlのcpanモジュール(名前を覚えていません。すいません。)を使ったのですが、この別のタイプのハッシュ関数はどういう仕組みで作られているのでしょうか? SALTが複数あり、そのそれぞれについて照合している?だけでしょうか? それとも私が無知で、そんな関数がそもそも存在するだけでしょうか? わかりません。教えてください。
- ベストアンサー
- その他(プログラミング・開発)
- ハッシュを使った擬似乱数
予測不能な擬似乱数列を生成する際に、よく一方向ハッシュの性質を利用する 場合があります。一方向ハッシュの生成源として内部状態が与えられますが、 内部状態の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数をどの程度にしたら適当か???”というのが質問です。 また、これらの問題を打開する方法もあればよいのですが、、、
- ベストアンサー
- ネットワーク
- ハッシュ関数について
例えば32ビットのデータなら32ビットのハッシュ値を、64ビットのデータなら64ビットのハッシュ値を作り出してくれるハッシュ関数はないでしょうか?できればそのようなハッシュ関数があったとして、Cのソースを公開しているようなホームページがありましたら教えてください。よろしくお願いします。
- 締切済み
- C・C++・C#
- パスワードの決め方について(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 攻撃以外の危険性はありますか?
- 締切済み
- ネットワーク
- データの暗号化に使うパスワードは何ビットが良い?
TrueCryptなどデータを暗号化するソフトがありますが そこで使うパスワードは、Webサービスのログインに使う IDと対になるようなパスワードとは違って、 もっと大きいbitでないといけないと言われたのですが、 ・・・本当ですか? 仮に本当だとすると、何ビットくらいが良いのですか? ちなみに全部256bitでそろえています・・・ もちろん使えないときもあるので その場合は先頭から使えるだけ使ってますから 完全に全て256bitというわけではないのですが・・・
- 締切済み
- Windows 7
- なんでハッシュ関数はユーザーに直接活用されない?
何故でしょう? 一番根本のハッシュというか種パスワードみたいのはそりゃ秘匿に充分気を使うから大変かもですが しかしひとつだけに絞れるわけだし 電卓みたいなデバイスを考えてもいいし せっかくインターネットという真の意味でグローバルな(アメリカ一極化という意味でなく)ネットワークがあるのに URLのところにハッシュ値を入れれば即対応する内容が表示されればそれでいいのでは? 認証させたけりゃIDパスワードの2要素で充分だし そのIDパス自体もハッシュで決めればいいし 上流でハッシュ変更したら自動的にIDでもパスでも順番に変更が反映されていくような プロトコルでも開発して全Webサービスが実装すればいいし ハッシュ関数なんてすごいものがありながら何で活用されていないのでしょうか?? 単純に不思議です 一昔前なら誰かがチラとこういうアイデア出せば飛びついて無理やりにでも実装したのに 少し時期がすぎると誰も見向きもしないし、で今熱いのはアンドロイドとかみたいですが 相変わらず情報セキュリティみたいのはダメダメだし もうあきらめてハッシュ電卓にしたらどうですか???
- ベストアンサー
- ネットワーク
- データ暗号化のパスワードをネットに置いていいのか
データ暗号化に4096bitの鍵を用いたとして その鍵をネット上に置いておいたら 全体として(通信経路など含めて)4096bitの強度は 実質かなり落ちるので無意味ですか? 256ibtならASCII印刷可能文字で39文字なので 無意味な文字列でも何とか覚えていられますが (SHA256を使った種パスワード方式にして、IDやEメールアドレスなど も含めて全部統一してしまえば、39文字自体は覚えづらくても それ1個だけ覚えればいいので何とかやれそうなのですが) 4096bitとなると624文字なのでちょっと無理なので・・・ なるべく全部ネットに置いておきたいのですが・・・ これはやはりどうにもならないでしょうか。
- ベストアンサー
- その他([技術者向] コンピューター)
- セキュリティ証明書のハッシュ値について
セキュリティ証明書(SSL通信時などに利用する証明書)には 拇印情報があり、ここは証明書自身のハッシュ値が記録されていると聞きました。 証明書から作成されたハッシュ値を再びハッシュ値に記載したら 元の証明書を書き換えているため、次回ハッシュ値を求めたら別のハッシュ値になりませんか? 1.証明書 -> [ハッシュ関数] -> ハッシュ値 2.ハッシュ値を証明書に記述記載 3.証明書(ハッシュ値付き)-> [ハッシュ関数] -> ハッシュ値 1と3の結果のハッシュ値同士は一致しないですよね? GMailの証明書を見ると、sha1で、 90adbe01984695b6649ad0f9ef4f1b5836eb380d という値になっていて、 私の端末(WindowsXP)でfcivコマンドを実行した結果も fciv -sha1 gmail.cer 90adbe01984695b6649ad0f9ef4f1b5836eb380d gmail.cer となり、同じ値なのですが。。。 証明書に記載されているハッシュ値はどのように計算されているのでしょうか?
- 締切済み
- ネットワーク
- 2bitのパリティビットはありえるのですか?(ハッシュ化DNA個人ID)
調べていてよく分からなかったので質問します。 今、DNAによる認証について調べているのですが、40bitのハッシュ化DNA個人IDを求めるところまでは分かりましたが、参考にしている文献には8bit毎にシフト・チェックビット(パリティビット?)を2bit付加するとありました。 自分はパリティビットとはデータに対して1bit付加するものだと思っていたので、よく分からなくなってしまいました。 文献には以下のように例が出ています 0111 1011 [10] 0000 0110 [01] 0110 1100 [01]・・・ この[ ]の中身がシフト・チェックビットだそうです。 そこで質問なのですが、 (1)そもそもシフト・チェックビットとはパリティビットなのでしょうか? (2)もしそうならこの場合、どのような規則で付加されているのでしょうか? いろいろ考えましたが、一向に法則性なども見えてこないのでよろしければお教え願います。
- 締切済み
- その他([技術者向] コンピューター)
お礼
なんか向こうの質問の補足にしたほうが良かったですかね? なんかいろいろすみません。 あと切り詰めるのはその通りで、私もそうしてます。 といっても殆ど放置ですが・・・ でそれで気をつけたほうがいいのは、確か独自ドメインのサービスで、 IDに当たるものがなくEメールアドレスとサイト認証パスワードだけ だったので、サイト認証パスワードとEメールアドレスの パスワード(これもフリーメール)が同じになってしまって 無駄になったことがあります。 なので自分が利用しそうな全Webサービスについて アカウント登録時に必須の入力項目を全部書き出して エクセルみたいので整理していかないと なんかドはまりしてまたすぐ何もかも厭に^^;なることが あります・・・ 大げさに言えば手動でネットサービス全部の 最大公約数的な認証API?を作ってるような もんですからね・・・ 自分はその辺で気力が尽きました・・・
補足
こちらでも毎回ありがとうございます。 認証用途なら256bitでも強度は充分で、しかも ハッシュなら被害拡大防止が容易ということですね。 で向こうの質問の続きかもしれないのですが データ暗号化の鍵としてのパスワードは (擬似)乱数で4096bitを用いると。 すると暗号化データの数だけ4096bitのパスワードが出来る ことになるので使っていくと結構な量になるのでは と思いますがこれはどこに保存しておいたらいいのでしょうか? 手元のPCだけだとHDDが飛んだりしたときに(まぁないでしょうが) どうにもならないですよね。かといってバックアップというのも それだけ管理の手間がかかるし。 できればネット上のオンラインストレージに置いておきたいのですが それはやっぱりいくらSSLとかIPv6とかやっても通信経路途中で 保護されてない区間があるとかそもそもIPv6にストレージサイトが 対応してないとかで本末転倒というか何してるんだか 分からないというか無駄というか無意味なんでしょうか。 やはりRAIDだかUSBメモリだかで手元のPCと同拠点に 物理媒体としてバックアップ必須なのでしょうか。 金かかるし紛失したりするしであまりこれ以上物理的な モノを増やしたくないのですが・・・