GPGPUでZIPパスワードを解析 63
タレコミ by Anonymous Coward
あるAnonymous Coward 曰く、
高速電算研究所のWEBサイトによれば、 ZIPファイルにかけたパスワードを忘れてしまった人のために GPGPUで高速に解析するサービスを開始したそうだ。 GPGPUとはグラフィック用途に特化して開発されたチップを使用して汎用的な計算を行わせる技術で、スーパーコンピュータ等で用いられている。
Youtubeに実際のパスワード解析を行う動画がアップロードされているが、 680億個のパスワード空間を探索するのに要した時間は108秒。 動画では大文字、小文字、記号を組み合わせた6桁のパスワードが あっさりと割り出されている。
ZIPパスワード解析といえばPIKAZIP等のフリーソフトが有名だが、 高速電算研究所によればIntel Corei7でPIKAZIPを動作させた場合と比較して 約100倍のパフォーマンスを実現したとのこと。
ZIP暗号には互換性を重視した「Traditional PKWARE Encryption」が多く使われており、 最大鍵長はわずか96bit（12桁）であり、より強度の高いAES暗号の普及はいまだ十分とは言えない。 現在機密情報をやり取りする目的で、一般に暗号化ZIPは広く使用されていると思われ、 近い将来、現実的な時間でパスワードが解読されてしまうことも起こりそうだ。
結局人間律速 (スコア:4, 興味深い)
鍵の最大長を長くしたところで、パスワードは実際は人間が覚えられる8文字ぐらいで運用されるので、
逆に復号に時間がかかるアルゴリズムを採用すればいいと思います。
1KBのテキスト復号するのに10分とか。
Re:結局人間律速 (スコア:2)
これはからは、覚えることは諦めて、長いパスワードにして必ずメモするという運用に変えたほうが良いような気がします。
Re: (スコア:0)
3DESならぬ128AES (128回AESを適用、鍵はPKCS#5v2でも使ってくれ) とか？
段数を増やすことが安全性につながるはずなのでいいと思うのだけど。
生体認証とか (スコア:2)
最終的には生体認証しかないな～とか思ったが、かけたら相手が開けないじゃんとかアホなことを考えてしまった･･･
Re:生体認証とか (スコア:2, おもしろおかしい)
Re:生体認証とか (スコア:3, おもしろおかしい)
短すぎます。強度が不足しています。
Re:生体認証とか (スコア:1, 参考になる)
良くあるように、送った後別便で指を送ってあげればいいのでは。
10回で終わりのように思えますが、新入社員や契約社員などの指を借りれば、そこそこの回数実行可能です。
Re:生体認証とか (スコア:3, おもしろおかしい)
Re:生体認証とか (スコア:3, 興味深い)
もちろん仕事の大半はその猫のご機嫌取りだ。 なにせ貴重な鍵だからな。
Re: (スコア:0)
Re: (スコア:0)
なんかいいなぁその響き
Re:生体認証とか (スコア:1)
生体公開鍵暗号方式 (スコア:1)
自分の生体情報を秘密鍵としてそれを元にして公開鍵を生成し、
送信者にはその公開鍵を渡せば…
とも思ったがそもそもZIPは共通鍵しか対応していない気が。
Re: (スコア:0)
Re: (スコア:0)
Re:生体認証とか (スコア:1, 参考になる)
ていうか、生体認証は鍵運搬や鍵生成の手軽さ、完全な複製の困難である事メリットなだけで、一般的なパスワードとは性質が全く違いますよ。
完全な複製の困難である事は十分なメリットですが、ゼラチン指のような擬体による突破を避ける為にシステムを人間などで監視する必要がありますし、鍵情報の再現性が微妙なのでシステム内に復元可能な形で鍵を格納する必要があり破壊的な解析にも耐えられません。
生体情報がリードオンリーかつリードプロテクト無しである以上セキュリティ的に微妙です。
システム内の比較用鍵を排除できても、擬体対策は難しいですからね･･･技術が進めば外科的に再現できる可能性が高いです。
信用できる要素が見当たらないが (スコア:2, 興味深い)
演算器の並列台数、料金だけでなく、所在地、電話番号すら書かれていない
謎の団体。
”高速電算研究所”でググると16件しかヒットしない。
公式を除くとニュースサイト、プレスリリースサイトより/.jpの投稿のほうが速い
謎の団体。
whois照会ではムームードメインを代理窓口とし情報を隠す
謎の団体。
団体？
「私たち」って書いてある事を素直に信じてよいのだろうか？
1.真っ当な研究所orベンチャー企業
2.個人の小遣い稼ぎ
3.ジョークサイト
4.着手金だけ振り込ませる詐欺、成功報酬つり上げる詐欺、ヘッダ抜き取りプログラムが実は…
Re: (スコア:0)
ググてヒットする所は結局スラドを参照してるから
実質的に公式とスラドしか無いよ
なんだろこれ夏休みのお小遣い稼ぎかなｗ
Re: (スコア:0)
ZIPで暗号化するマヌケはいないだろ (スコア:1, 参考になる)
Re:ZIPで暗号化するマヌケはいないだろ (スコア:2)
＞ZIPで暗号化するマヌケはいないだろ
ZIPの256ビットAES暗号なら充分に堅牢だと思いますよ。
2月に某所に投稿した暗号関連の記事を日記に再掲しました。
http://srad.jp/~chocopa/journal/535844 [srad.jp]
Re:ZIPで暗号化するマヌケはいないだろ (スコア:2, すばらしい洞察)
とはいえ、パスワードの鍵の長さが6-8じゃあんまり意味ないでよね。
GPUつかわなくても実時間で解析できそうだし...
# 100倍として10800秒?
個人的には公開鍵暗号で暗号化ならセッション鍵を使うことになるんで、
PGP(GnuPGでも)がいいんですが、せめてファイル暗号化ツールとしてでも導入してくんないんですかねぇ...
# 共通鍵暗号でも暗号化アルゴリズム切り替えられるしねぇ
M-FalconSky (暑いか寒い)
Re:ZIPで暗号化するマヌケはいないだろ (スコア:2, すばらしい洞察)
公開鍵暗号と共通鍵暗号の話は分けて考えましょうよ･･･
考え方も使い方も全然違うんですし。
楕円曲線だの素因数分解だのを使うのは公開鍵暗号の方で、これらは一方向性の計算によって相関の有る数値ペアを生成するのがキモになってます。さらに、公開鍵暗号は通常の運用ではデータ本体の暗号化には使われず、ハッシュ値や共通鍵暗号の暗号鍵を暗号化するだけです。
相関があるのが重要なのでこれを抜かしては話になりませんし、そもそも本文の暗号化に使ってません。
また、AESやDESは共通鍵暗号(共通鍵ブロック暗号)になりますが、これは「何かの表で置き換える方法」の延長線上にある暗号です(XORに使う1つの値が1つの換字表として機能するため)。
共通鍵暗号のメジャーどころはストリーム暗号かブロック暗号のどちらかです。
ストリーム暗号は暗号鍵を種にした擬似乱数で1文字ごとに換字表を再生成する暗号です。
ブロック暗号は、ブロック単位でメッセージの一部と暗号鍵を使って生成した擬似乱数を使って多重に換字(と転置操作(転置式暗号も古典暗号の一つ))する暗号です。
重要なのは換字表の交換手順であり、換字自体はむしろ古典的暗号よりもシンプルです。
それはともかく、ZipでAES使ったとしてもアーカイバが対応してくれないと悲しい事になりますから、素直に最初からAESが使えるとされている7zなり何らかの暗号化専用形式を使うべきだと思います。
もう一つ付け加えると、AESの堅牢性云々より、AESの暗号鍵生成に使うパスワードの方を気にすべきだと思います。
# AES自体の安全性も、突破こそされていないものの有る程度は研究によって弱くなってきてるようですし、胡坐をかくのもどうかと思う
# ACで投稿したいのでこっちでコメント
Re:ZIPで暗号化するマヌケはいないだろ (スコア:2)
参考に提示したまでで、それは2月に別のテーマで書いたものです。
Re: (スコア:0)
AES256は安全なんだけど、Windows XP標準のzipでサポートされてないからやっぱだめー。
Vista以降ならサポートされてるけど、まだXPのお客さん多いしー。
どーせ新しくツール入れなきゃいけないんなら、zipにする理由あんまりないしー。
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1)
企業から見積もりとか送られてくるとき、いつものように暗号化 ZIP 固められて、パスワードが別便メールで送られてくるのですが、この「パスワードが別便メールで送られてくる」っていうのはどこから広まった手法なんでしょうねえ。
Hiroki (REO) Kashiwazaki
Re:ZIPで暗号化するマヌケはいないだろ (スコア:3, 興味深い)
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1, すばらしい洞察)
1通目でファイルを間違って送っちゃっても、パスワード送らなければセーフみたいな
今回のタレコミ的にはアウトだけど
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1, すばらしい洞察)
きっと2通目も間違えて送るよ。
Re: (スコア:0)
あと、bzip2 とか 7zip とかはアンチウイルスが対応してない(場合が多い)ので、平文でも何とか。
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1)
あれも大変不毛なバッドノウハウだと思う。
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1, 参考になる)
受信者が転送する際に意図せず添付ファイルまで送ってしまっても機密が漏れないようにするためです。
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1)
パスワードはせめて別経路でとお電話差し上げたらウザがられたでござる。
というのはさておき、パスワードを別のメアドに送ってくる人もいて、それはそれでまだマシかもと思ったり。あくまでも比較問題だけど。
Re: (スコア:0)
Re: (スコア:0)
頭悪いんだと思う。
TCP/IPの教科書を読んだばかりの素人管理者が、
パケットはインターネットでは毎回違う経路を通ると勘違いして
社内ルールを決めてるんでしょうね。
確かに入門書を見るとそれっぽい説明はするけどさ。
Re: (スコア:0)
＞TCP/IPの教科書を読んだばかりの素人管理者が、
＞パケットはインターネットでは毎回違う経路を通ると勘違いして
＞社内ルールを決めてるんでしょうね。
言いたいことはわからいでもないが、ルーティングは今回無関係では？
社内の転送厨(≒管理職)が中身見ずにほいほい協力会社なんかに転送して、
あとから「それ転送したらやばいだろ」と上司から怒られ、
それを情シスのせいにしたたことが発端ぽい気がする。
Re: (スコア:0)
元コメは、管理者がパスワードを別便メールで送るという社内ルールを作っているのではなく、利用者が勝手にそうした運用を編み出しただけと読めましたけど。
管理者が推奨してるところってあるのかしら？
Re:ZIPで暗号化するマヌケはいないだろ (スコア:2)
・添付する場合は、暗号化ソフトで暗号化したファイルを添付。
・先方で暗号化されたファイルを開けない場合はパス付ZIP圧縮をする。
・ただしパスは別送。
と規定すると、管理者曰く
「面倒くさいから、添付有メールが減るんです。
データの出ていく量を減らせるんです。」
# ITって仕事を効率化してくれるんじゃなかったっけー（棒）
Re:ZIPで暗号化するマヌケはいないだろ (スコア:1, 参考になる)
dodonqaです。
会社の規約で、外部へのメールは、必ず暗号化しろと決まっています。
復号できないとクレームが多いので、Windows付属のzipパスワードが標準です。
HDD暗号化ソフトの付加機能でファイル暗号化も可能ですが、相手先に同一のソフトがないと復号できないor自己展開式になり、ハッシュキーも付けずにアイコンだけで実行ファイルの安全性を確認して自己展開させる(様なクセを付ける)位ならzipの方がマシと判断しています。
--
以上、駄文でした。 dodonqa Projects (no active)
アイディア自体は既出 (スコア:1, 参考になる)
Re: (スコア:0)
元のファイルを送ってもらわないといけないと思う。
金出してパスワードを解除するなんて、よほど大事なファイルだろうけど
PASS解析されたら中のファイルも漏洩するからな。
宣伝乙 (スコア:0)
これ個人事業なんでしょうかね？
空目 (スコア:0)
なんてこった! (スコア:0)
680億というとだいたい 2^36。
96bit鍵の半数が 2^95 なので、(平均すれば) ほんの 108*2^59秒 もあれば解析されてしまいます！
# つまり 2 兆年、と。
Re:なんてこった! (スコア:2)
その 680 億は、パスワードの数。
96 bit は実際に暗号化に使われている鍵の数。実際に暗号化処理に使われる鍵そのものは、パスワードから何らかの演算処理をして作り出されるもので、パスワードの文字列がそのまま、鍵として使われるわけではない。
余談：
単純なのは、パスワード文字列のハッシュ値を取得して、それを鍵として使う。ただ、zip のソースコードを眺めたら、zip オリジナルらしい処理で、パスワード文字列から鍵を生成していた。
閑話休題。
で、ブルートフォースで解読する場合、鍵そのもので解読しようとすると、文字通り、296 通りの鍵を試す必要があるけど、鍵の「素」になるパスワード文字列の方が、「どうせ人間のやることだ。6 文字程度で、記号文字は入ってないだろう」と割りきって解析すると、296より遥かに少ない数で解読できる。
680 億種類のパスワードは、もし、記号を除いた英数字に限れば、log6468000000000 = 5.997... なので、約６文字。ASCII 図形文字（いわゆる英数字記号。0x21-0x7e の範囲の文字）と半角スペースの 95 文字だと、log9568000000000 = 5.477 文字。なので、もとの話ざっくりとまとめると、6 文字の英数字なら数分で解けますよ、という話になる。
で、文字種を 95 文字をベースに考えれば、6 文字のパスワードは 956 = 735091890625 のパスワードなので、108 秒 × 735091890625 / 68000000000 = 1167 秒 = 19 分 27 秒。7 文字だったら、その 95 倍で約 30 時間。8 文字なら 4 ヶ月、9 文字なら 30 年、10 文字なら 3000 年ぐらいになる。
Traditional PKWARE Encryption と AES で、１つのパスワードにつき解読にかかる時間がどの程度違うかは分からないけど、7-zip を使って AES 256 bit の暗号化 ZIP ファイルを作っても、パスワードが 6 文字だったら、現実的な時間で解けるのは変わらないはず。
とりあえず、英数字、大文字小文字、記号を混ぜて 10 文字のパスワードなら、今のところは安全圏かな。もっとも、そんな 10 文字のパスワードを人間が覚えてられるかが問題だけど...。
ほんとに100倍？ (スコア:0)
PikaZipって1スレッドで動くプログラムなので8個起動させてフル稼働させれば
差は縮まるのではないかな。
あと、100倍ってことは約7bit相当でパスワード文字数にすると1文字未満なのね
Re: (スコア:0)
以下ってどこ？
ここですか？
Re: (スコア:0, 興味深い)
dodongaうざいです。
独り善がりの無意味な駄文を書き散らかさないでください。
--
以上、苦言でした。
Re: (スコア:0)
Re: (スコア:0)
以下の文章は真実である
以上の文章は駄文である
なにこのびみょうな矛盾感？