アカウント名:
パスワード:
NSAが確保できる演算能力を、2014年にスパコンのランキングGraph500で1位を獲得を取得した、日本の理化学研究所の「京」1式丸ごとと同じレベルと仮定して計算してみます。GPU での演算は試算が難しいので、今回は考えないものとします(もっとも、こういった分野にはGPUが使われるのでほんとはそっちで計算すべきかもしれませんが、データがすぐには入手できませんでした)。
「京」は、浮動小数点数演算を1秒あたり1京回おこなう処理能力(10ペタFLOPS)を持ちます。これに対して一般家庭で普通に購入できるレベルのコンピュータのCPUだと、Core i7 (Haswell) 8コア 3.0GHz で 384 GFLOPS です。つまり、性能差は 約 26,040 倍ということになります。
HDD の暗号化や Evernote のノートの暗号化を想定して、複合に必要な時間(パスフレーズを入力してから復号処理のために待たされる時間として許容できる時間)を3秒間とします。この時間が3秒間になるように、パソコンやスマホのスペックに合わせて、パスフレーズをソルト付きHMACハッシュ関数を通る回数を自動的に変更する仕組みにすれば良いと思います。勿論、時間がかかっても強度をあげたい人のために、手動で設定変更もできるようにしときます。
さて、さっき例に出したCore i7 (Haswell) 8コア 3.0GHz で 3秒間かかる処理の場合、「京」だと1秒間で8,680回行える訳です。「京」ならば、1分間で520,800回、1時間で31,248,000回、1日で749,952,000回、1年で273,732,480,000回、100年で27,373,248,000,000回、パスフレーズの試行ができることになります。
ランダムな英数字7桁のパスワードの場合 3,521,614,606,208 通りですから、これだと平均6年程度で解読されてしまいます。しかし、ランダムな英数字8桁のパスワードならば、218,340,105,584,896 通りになりますから、平均で400年ぐらいの解読時間がかかることになります。
ということで、正しいアルゴリズムで実装すれば、8桁のランダムな英数字のパスワードでも十分安全だし、低スペックな端末を考慮してHMACハッシュ関数を通す回数を減らす場合や、コンピュータの性能の向上を考慮しても10桁~12桁のランダムな英数字のパスワードで大丈夫なことが分かります。
もっとも、現実には、パスフレーズをそのままAESの秘密鍵として用いるようなゴミ屑のような実装が平気で行われているのが現状です。セキュリティの高さを売りにしているシステムであっても、MD5、SHA、SHA1といった高速ハッシュアルゴリズムを数千回通して満足しているような酷い実装がまかり通っています。そういった糞みたいな実装をするから、1秒間に1兆回試行できてしまうんです。正しくは、ソルト付きHMACハッシュ関数を用いるべきです。
Evernoteも、2014年2月までは、ユーザが指定したパスフレーズからなる鍵長 64bitのRC2暗号といった脆弱な暗号化アルゴリズムが使われていました。しかし、私がさんざんクレームを付けておいた甲斐もあって(?)、ユーザのパスフレーズをHMAC/SHA-256ハッシュ関数に50,000回通したものが AES キーとして利用されるように改善された [evernote.com]ようです。ということで、脆弱な暗号を採用しているシステムに対しては、みんなで苦情を送るのが良いかもしれません(暗号化アルゴリズムが非公開なのは論外です)。なお、既に暗号化したノートは、暗号化をやり直さないと脆弱なままなので注意が必要です。(ちなみに、Evernote社は、画像検索がまともにできないバグ [srad.jp]などを、確実に再現する方法を書いて報告しても直さず放置することからあまり好きではありません)
なお、HDDの暗号化で有名なTrueCryptは、ユーザーが入力したパスフレーズを、きちんとソルト付HMACである、HMAC-RIPEMD-160(2000回)、HMAC-SHA-512(1000回)、HMAC-Whirlpool(1000回) に、カッコ書きで書いた回数通してから、鍵として使う仕組みになっています。
ストレッチは正規システム側でも負荷が上がるので、「攻撃側必要演算リソース=正規側認証部必要演算リソース×定数」の定数項には寄与しません。それどころか、正規側は汎用の演算装置で実装すると思われますが、特定の繰り返し演算は演算特化のGPGPU処理や専用回路による効率化があり得るのでむしろ正規システム側の方が相対的に損をする取引です。
ストレッチは付け焼き刃としては有効でも所詮付け焼き刃だと認識すべきです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
まともなアルゴリズムなら 「1秒間に1兆回」 ではなく 「1秒間に1万回」 しか試行できない (スコア:3)
NSAが確保できる演算能力を、2014年にスパコンのランキングGraph500で1位を獲得を取得した、日本の理化学研究所の「京」1式丸ごとと同じレベルと仮定して計算してみます。GPU での演算は試算が難しいので、今回は考えないものとします(もっとも、こういった分野にはGPUが使われるのでほんとはそっちで計算すべきかもしれませんが、データがすぐには入手できませんでした)。
「京」は、浮動小数点数演算を1秒あたり1京回おこなう処理能力(10ペタFLOPS)を持ちます。これに対して一般家庭で普通に購入できるレベルのコンピュータのCPUだと、Core i7 (Haswell) 8コア 3.0GHz で 384 GFLOPS です。つまり、性能差は 約 26,040 倍ということになります。
HDD の暗号化や Evernote のノートの暗号化を想定して、複合に必要な時間(パスフレーズを入力してから復号処理のために待たされる時間として許容できる時間)を3秒間とします。この時間が3秒間になるように、パソコンやスマホのスペックに合わせて、パスフレーズをソルト付きHMACハッシュ関数を通る回数を自動的に変更する仕組みにすれば良いと思います。勿論、時間がかかっても強度をあげたい人のために、手動で設定変更もできるようにしときます。
さて、さっき例に出したCore i7 (Haswell) 8コア 3.0GHz で 3秒間かかる処理の場合、「京」だと1秒間で8,680回行える訳です。「京」ならば、1分間で520,800回、1時間で31,248,000回、1日で749,952,000回、1年で273,732,480,000回、100年で27,373,248,000,000回、パスフレーズの試行ができることになります。
ランダムな英数字7桁のパスワードの場合 3,521,614,606,208 通りですから、これだと平均6年程度で解読されてしまいます。しかし、ランダムな英数字8桁のパスワードならば、218,340,105,584,896 通りになりますから、平均で400年ぐらいの解読時間がかかることになります。
ということで、正しいアルゴリズムで実装すれば、8桁のランダムな英数字のパスワードでも十分安全だし、低スペックな端末を考慮してHMACハッシュ関数を通す回数を減らす場合や、コンピュータの性能の向上を考慮しても10桁~12桁のランダムな英数字のパスワードで大丈夫なことが分かります。
もっとも、現実には、パスフレーズをそのままAESの秘密鍵として用いるようなゴミ屑のような実装が平気で行われているのが現状です。セキュリティの高さを売りにしているシステムであっても、MD5、SHA、SHA1といった高速ハッシュアルゴリズムを数千回通して満足しているような酷い実装がまかり通っています。そういった糞みたいな実装をするから、1秒間に1兆回試行できてしまうんです。正しくは、ソルト付きHMACハッシュ関数を用いるべきです。
Evernoteも、2014年2月までは、ユーザが指定したパスフレーズからなる鍵長 64bitのRC2暗号といった脆弱な暗号化アルゴリズムが使われていました。しかし、私がさんざんクレームを付けておいた甲斐もあって(?)、ユーザのパスフレーズをHMAC/SHA-256ハッシュ関数に50,000回通したものが AES キーとして利用されるように改善された [evernote.com]ようです。ということで、脆弱な暗号を採用しているシステムに対しては、みんなで苦情を送るのが良いかもしれません(暗号化アルゴリズムが非公開なのは論外です)。なお、既に暗号化したノートは、暗号化をやり直さないと脆弱なままなので注意が必要です。(ちなみに、Evernote社は、画像検索がまともにできないバグ [srad.jp]などを、確実に再現する方法を書いて報告しても直さず放置することからあまり好きではありません)
なお、HDDの暗号化で有名なTrueCryptは、ユーザーが入力したパスフレーズを、きちんとソルト付HMACである、HMAC-RIPEMD-160(2000回)、HMAC-SHA-512(1000回)、HMAC-Whirlpool(1000回) に、カッコ書きで書いた回数通してから、鍵として使う仕組みになっています。
Re: (スコア:0)
ストレッチは正規システム側でも負荷が上がるので、「攻撃側必要演算リソース=正規側認証部必要演算リソース×定数」の定数項には寄与しません。
それどころか、正規側は汎用の演算装置で実装すると思われますが、特定の繰り返し演算は演算特化のGPGPU処理や専用回路による効率化があり得るのでむしろ正規システム側の方が相対的に損をする取引です。
ストレッチは付け焼き刃としては有効でも所詮付け焼き刃だと認識すべきです。