暗号学的ハッシュ関数でbit長が適切って作れますか

質問

SHA256が（224かもですが）最小bit長で、
入力に1bitでも、また2bit以上入力値全体まで、異なれば、
出力のうちほぼ半数のbitが反転する、かつその
反転するbit位置は複数の入力値に対して法則性はなく、
ほぼランダムである。

という暗号学的ハッシュ関数であるのは、正しいですか？

また、データの暗号化に使われるパスワードは4096bitを推奨との
事ですが、
SHA4096などその時に合った暗号学的ハッシュ関数を
作るのは難しいのですか？
素人考えでは、今256bitで衝突が見つかってないなら
4096bitならbit長大きいのだから作れそうな気もしますが
やはりそういう問題ではないのでしょうか？

もし作れるとしたら、データの暗号化に使うパスワードを
SHAなんとか・・・の出力そのまま使っては、危険でしょうか？

というかデータに限らず認証のパスワードでも
SHAなんとかの出力そのままを使うのは何かまずいのでしょうか？

もしできたらパスワードを覚えなくてよいのでいいかと思ったのですが。

パスワードは「IDのパスワード」をSHAなんとかに通した値ということで。
IDは「種パスワード＋なんとかのサイト」をSHAなんとかに通した値ということで。

種パスワードはしょうがないからネットをパスワードの決め方とかで検索して
出てきた方法を見て理解して自分なりにアレンジして、最後にちゃんと頭に記憶して。

とりあえずここまで、どうでしょうか。

回答No.3

mtaka2

もう一つの質問の方にも書きましたが、この手法でパスワードを生成する場合、
あるサイトでのパスワードを解読するのに、種パスワードが判明する必要はありません。
例えSHA-256の入力が256bit以上あったとしても、SHA-256の出力である256bit分だけ試行すれば表パスワードが解読できます。

ですが、そこで判明するのは、そのサイトにおけるパスワードだけです。
他のサイトでのパスワードは、ソルト(「＋なんとかのサイト」の部分)が違いますから、
種パスワードがバレない限り大丈夫なわけです。

つまり、本手法のメリットは、
・サイトごとに別々のパスワードを使うので、あるサイトのパスワードが流出しても、他のサイトへの認証に影響しない
・共通の種パスワードから各サイトのパスワードを生成するので、個々のパスワードを覚える必要がない
・各サイトのパスワードから種パスワードを推測するのは事実上不可能
という点にあります。

ところで、SHA-256の出力をパスワードに使える文字列に変換した場合、Base64でも43文字になります。
ですが一般的なサイト認証では、パスワードにそれだけの長さを使えるところはあまり多くないと思います。
私の場合、それに応じてハッシュ値を切り詰めて短くしたものパスワードにしています。
個別パスワードの総当たりに対する強度は、そのパスワードの長さに応じたかなり弱いものでしかありません。

ですが、暗号の場合、手元に「暗号文と平文の組」を入手してから、それを元に解読するので、CPUパワーを存分に使えますが、
サイト認証の場合、「手元で解読」なんてことはできませんから「ネットを通して総当たり」みたいなことしかできません。
「1秒間に100万回の試行」なんてとうてい不可能ですので、8文字(=Base64で48bit)でも実用上問題ないでしょう。
仮に1秒間に100回の試行として、1000台並列で90年かかります。

一方で、Web上で使うパスワードの場合、「総当たりで解読される危険性」よりも
「個人情報の流出によってパスワードが漏れる危険性」の方が、可能性は高いと考えています。

その時、そのサイトでのパスワードは諦めるとして、
「漏れたあるサイトのパスワードから、他のサイトのパスワードが解読できるか」=「種パスワードが解読できるか」という点については、
まさにハッシュ関数本来の「衝突可能性」の問題になり、
ハッシュ関数の出力長が256bitしかなくても、
入力の方が十分な長さがあれば問題ないということになります。

お礼

なんか向こうの質問の補足にしたほうが良かったですかね？
なんかいろいろすみません。
あと切り詰めるのはその通りで、私もそうしてます。
といっても殆ど放置ですが・・・
でそれで気をつけたほうがいいのは、確か独自ドメインのサービスで、
IDに当たるものがなくEメールアドレスとサイト認証パスワードだけ
だったので、サイト認証パスワードとEメールアドレスの
パスワード（これもフリーメール）が同じになってしまって
無駄になったことがあります。

なので自分が利用しそうな全Webサービスについて
アカウント登録時に必須の入力項目を全部書き出して
エクセルみたいので整理していかないと
なんかドはまりしてまたすぐ何もかも厭に＾＾；なることが
あります・・・
大げさに言えば手動でネットサービス全部の
最大公約数的な認証API？を作ってるような
もんですからね・・・
自分はその辺で気力が尽きました・・・

補足

こちらでも毎回ありがとうございます。
認証用途なら256bitでも強度は充分で、しかも
ハッシュなら被害拡大防止が容易ということですね。

で向こうの質問の続きかもしれないのですが
データ暗号化の鍵としてのパスワードは
（擬似）乱数で4096bitを用いると。
すると暗号化データの数だけ4096bitのパスワードが出来る
ことになるので使っていくと結構な量になるのでは
と思いますがこれはどこに保存しておいたらいいのでしょうか？
手元のPCだけだとHDDが飛んだりしたときに（まぁないでしょうが）
どうにもならないですよね。かといってバックアップというのも
それだけ管理の手間がかかるし。
できればネット上のオンラインストレージに置いておきたいのですが
それはやっぱりいくらSSLとかIPｖ6とかやっても通信経路途中で
保護されてない区間があるとかそもそもIPv6にストレージサイトが
対応してないとかで本末転倒というか何してるんだか
分からないというか無駄というか無意味なんでしょうか。
やはりRAIDだかUSBメモリだかで手元のPCと同拠点に
物理媒体としてバックアップ必須なのでしょうか。
金かかるし紛失したりするしであまりこれ以上物理的な
モノを増やしたくないのですが・・・

回答No.2

mtaka2

暗号の運用においてはどちらも重要な位置を占めますが、
「暗号化アルゴリズム」と「ハッシュアルゴリズム」はまったく別物です。
SHA-256というハッシュ関数を直接暗号とからめてはいけません。

で、パスワードの生成にSHA-256を使うというのは、考え方自体は悪くないです。
(私自身、似たような方法を使ってます)

ですが、別の質問の方でも答えましたが、入力長が短い場合、総当たりされやすいという問題があります。

現状のSHA-256でも、それ自体はハッシュ関数として十分な強度を持っています。
ですが、たとえば入力が短ければ、入力の方を簡単に総当たりできてしまうわけです。

・種パスワードには十分な長さが必要。最低でも256bit
・SHA-256などのハッシュ関数は「辞書攻撃されやすいが覚えやすい文字列」から「辞書攻撃しにくいランダム風な文字列」に変換するものとみなせる

というわけで、一般的な「覚えやすいが辞書攻撃されにくいパスワードの決め方」に従う必要はありません。

辞書攻撃されやすい単語の組合せでも、十分な長さがあれば、全体としては辞書攻撃しにくくなりますから、辞書攻撃されやすい言葉を使っても全然問題ありません。
また、文字コードさえちゃんと決めておけば、種パスワードが日本語でも大丈夫です。
たとえば、たった17文字の俳句でも、漢字仮名交じりなら鍵長として約400bitの効果があります。
とにかく「覚えやすくて、十分に長いパスフレーズ」を種パスワードに使えばOKです。

お礼

なんか数が大きすぎて分からなくなってきました。
たぶん私なんか勘違いしてますよね？
性能向上のペースを考慮に入れても
10年以内に解読される確率は0.00001%
とかの暗号強度にしたかったら
鍵長4096bitとかそういう話ですよね？

それと認証のパスワードで1ヶ月以内に解読される
確率は現在のところ33%で良いならSHA256の出力で
充分だと、そういう違いですね？

でも希望を言うと面倒だから10年後にまだ同じハッシュを
使っていても
1ヶ月以内に解読される確率３３％とか
それくらいずっと同じ方法で使いたいのですが・・・
なるべく長持ちする方法ということで・・・

補足

おおっどうもこちらでもまたしても回答ありがとうございます。
どうも物分りが悪くてすみません。
ええと、暗号化アルゴリズムはPGPなり既存のを使うとして、
その実装というか、主に利用したデータ暗号化ソフトを実際に
利用するときに、たぶんパスワードが必要になりますよね？
そういえば昔オンラインストレージを試してみたときに
パソコン雑誌か専門誌かのサイトの記事のとおりに
TrueCryptだかを試して、そのときに確かIDにあたるものは
無くて、パスワードをかなり長い文字決めろみたいなことで、
こんなの普通決められないよなということで例のSHA256出力そのまま
方式で決めましたが、その計算方法については
ネットの全公開のとこにそのまま書いて、ただ
種パスワードにあたる部分だけを秘密にしておいたというか
変数ｘみたく書いておいただけなんですが、
そういった使い方では、やはり総当りされるのでまずいんですよね？
xに当たるのは256bit以上あるのですが。
80日で解けるのは64bitでしたか、そうすると256bitだと
320日ですか？これも確率の問題でええと
ちょっとズルします最強兵器
http://www.ttmath.org/online_calculator
ええと1文字が96種類あるとして8文字で96^8=7213895789838336
これが仰るような「1台あたり毎秒100万回の試行」で「1000台並列」
のスペックで、ってどのくらいの性能か全然わかりませんが
なんかAmazonクラウドとか使うかんじですかね？
で80日で総当り終了と。
すると39文字というか256bitだと10進数だとええと
115792089237316195423570985008687907853269984665640564039457584007913129639936ですか。さっきので割ると
16051256160426335421112334656861824770445830727107012841687391
ですか整数部だけで。
これ掛けることの８０が日数ですね。で365で割ると
351808354201125159914790896588752323735799029635222199269860
年てことでいいですかね。整数部だけでやってますが。
先の質問で回答頂いた4096bit長でないと弱いというのは、
データの暗号化の鍵長だと思いますが
認証のパスワードのbit長は実時間で総当り不可ですが
何らかの暗号化アルゴリズムの鍵長としては
総当りされてしまうということでしょうか？

回答No.1

root_16

言ってることが良く分かんないけど、
入力に対して出力がランダムで、
そのランダムなものが復号鍵だとすると、
暗号を復号するのにその復号鍵が必要だから
そのランダムなものを憶えないといけないですよね。
それ無理じゃないですか＞＜

パスワード入力しても出力がランダムなせいで
違う復号鍵が出来てしまうし、復号できねぇ。

お礼

回答ありがとうございました。

補足

複数のってのが分かりづらかったですかね。

ハッシュなので当然入力と出力が1対1ですか
入力aと入力bに対して出力がa'とa'+1
となってしまうような法則性はなく、ランダムだと
いうことです。