アカウント名:
パスワード:
と思って読んだら、なるほど.DS_Storeのパターンが限られているので「既知平文が手に入る」という条件を簡単に満たせてしまうのか
「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。長さや文字種組み合わせに確信がないと心折れるくらいは掛かる。だから既知平文攻撃ができるってのは割と強い。
既知平文攻撃自体は知ってたけどzipcryptでここまで気楽かつ強力とは知らなかった。.DS_Storeに限らず既知平文は割合ありがちだからリアルに怖いね。個人用途では7zipの暗号化を使ってるからそう心配はないが。
「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。
821日が 64日になる、という計算らしいけど、それほどお手軽では無いとも言えるし。クラウド環境などを動員されたら、そんなに差は無いのかも。
7z あたりが OS で標準サポートされないのはどうしてなのかな。
今回の手法で全パターン(65536通り) を総当たりするのにかかる時間は、以下のようになります。 (先程のスクショを取得したのと同じ端末の場合)
.DS_Store 1パターンあたりにかかる時間 (85秒) * 65536 = 5570560秒 = 92842分 = 1547時間 = 64日
また、同端末のhashcatのベンチマーク結果 (m=17200) は85915.0 kH/sでした。この結果から、英数字+記号の8文字のパスワードをブルートフォースするためにはおよそ以下の時間がかかることがわかります。
948 / 85915000 = 70950234秒 = 1182503分 = 19708時間 = 821日
つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。
7zやrarはzipフォルダーのようなものを実装するのが困難(最後のファイル1つだけがほしくても先頭からすべて展開しなければならない)。圧縮率と引き換えなので一概に悪いとは言えないけど
それはソリッド形式とよばれるもので、オプションを外せばファイル単位での圧縮も対応していますよただ書かれている通り、圧縮率はかなり変わってきますが7zip や rar が劣るとすれば（辞書サイズなど仕方ないけど）メモリ使用量や処理速度、最適化された実装の存在くらいじゃないかな
自分で圧縮したファイルだけを扱えればいいわけじゃないからオプションで無効にできても意味がない
実装が困難という誤解に対し、そういったオプションが既にあるという指摘をしただけで入手した圧縮ファイルから 1 ファイルだけ取り出せないから意味がない、ってよくわからん反論だなぁ全展開するのが大変な圧縮ファイルから 1 ファイルだけ取り出したい、って割とレアケースなのでは
前提の、OSの標準として実装って条件が抜けてないかな？オプションによって内部の単一ファイルを扱えたり扱えなかったりするんじゃ、標準には使えないでしょ。
そんな前提は提示されていないのですが……OS の標準に不適な理由は #4130430 にもある通りライセンスが理由だと思うけど機能的な理由で不適となるなら、オプションが多すぎて初心者には扱いにくいかも、ぐらいかな（ファイル名も暗号化できるのは必要な機能だけど混乱しそう、とか）
なお可能/不可能の意味で「扱えない」という書き方をしているならこれも誤解で、処理時間がかかるだけで扱えはしますよある程度モダンな環境（CPU/メモリ/SSD）であれば、それほど違和感なく扱えるような実装には出来るんじゃないかな
>7z あたりが OS で標準サポートされないのはどうしてなのかな。
#4130376 が> 7z あたりが OS で標準サポートされないのはどうしてなのかな。に対する回答であるというならそうかもしれませんが明示もされていませんし、技術的な回答に対しては #4130400 で誤りを指摘していますそこに運用上の問題を #4130408 で追加していますが、それに対しても #4130433 でレアケースじゃないかと指摘しているのですが追加される後付け理由にも全部回答を提示していて、なお何に疑問を呈されるのか……
いうて7zipもrarも公式ツールはアーカイブをフォルダのように操作できますし…むしろファイルを取り出すときよりファイルを消したり足すときのほうが問題。あと単純に遅い。
一覧を表示するだけならインデックスを見るだけだから速いけど、ファイルを取り出そうとするとわかるよ。少なくとも7-Zipの公式クライアントは
ランダムアクセス可(先頭から全て展開する必要がない)、認証つき暗号採用、メタデータ(ヘッダー)も暗号化、マルチプラットホーム、となると思い当たるのは rar, ezio, dar ぐらい。
rar は linux 上で使っても良いモノなんだけどライセンスの問題がどうにもならない。個人的には ezio を改造して使っている。erasure code があって extend attribute にも対応しているから linux 上で /etc とかまるっと暗号化バックアップ作るのにちょうどいい感じ。
既知平文攻撃はパスワードの長さ（強度）を無視できます（結果としてパスワードが不明なまま展開される）そのためパスワードを長くすればするほど総当たりとの差は広がる一方で、それが> つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。という一文に現れています
> 7z あたりが OS で標準サポートされないのはどうしてなのかな。cab があるから、というのと 7z は GNU LPGL なのでライセンス上リバースエンジニアリングの許可が必要など Windows に標準で載せるには縛りが厳しいからではないかな
> 7z は GNU LPGL なので
7-ZipはLGPLだけどLZMA SDK [sevenzip.osdn.jp]はpublic domainだよ。7zをサポートするだけならこれで十分なのでライセンスが理由ではない。
#4130357に書いたけど実際にはさらに数万倍高速化できると思う
LZMAが赤い赤いロシアのアルゴリズムだから。
と、中国製の端末を使って書き込んでるんですね
7z あたりが OS で標準サポートされないのはどうしてなのかな
自前のフォルダー操作ができて暗号化にも圧縮にも対応したディスクイメージというものがありますので。
そういえばWindowsに搭載のtarコマンドはlibarchive実装なので、たぶん7zを読み書きできるはず。OSサポートとして思っているのと違うかもしれないけど。
ところがぎっちょん、Windows標準のtarはわざわざ7-Zipサポートをオフにしてビルドされているらしく、使えない。
既知平文攻撃の場合、パスワードの長さは関係ないからね。
zipcryptoの内部状態は96bitしかないので、ある程度以上パスワードが長くなったらパスワードよりも内部状態で総当りしたほうが速くなる。さらにさまざまな攻撃手法で96bit総当たりより大幅に高速化できることが知られており、既知平文攻撃もその1つ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
と思って読んだら、なるほど.DS_Storeのパターンが限られているので「既知平文が手に入る」という条件を簡単に満たせてしまうのか
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:0)
「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。
長さや文字種組み合わせに確信がないと心折れるくらいは掛かる。
だから既知平文攻撃ができるってのは割と強い。
既知平文攻撃自体は知ってたけどzipcryptでここまで気楽かつ強力とは知らなかった。
.DS_Storeに限らず既知平文は割合ありがちだからリアルに怖いね。
個人用途では7zipの暗号化を使ってるからそう心配はないが。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:2)
「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。
821日が 64日になる、という計算らしいけど、それほどお手軽では無いとも言えるし。クラウド環境などを動員されたら、そんなに差は無いのかも。
7z あたりが OS で標準サポートされないのはどうしてなのかな。
今回の手法で全パターン(65536通り) を総当たりするのにかかる時間は、以下のようになります。 (先程のスクショを取得したのと同じ端末の場合)
.DS_Store 1パターンあたりにかかる時間 (85秒) * 65536 = 5570560秒 = 92842分 = 1547時間 = 64日
また、同端末のhashcatのベンチマーク結果 (m=17200) は85915.0 kH/sでした。
この結果から、英数字+記号の8文字のパスワードをブルートフォースするためにはおよそ以下の時間がかかることがわかります。
948 / 85915000 = 70950234秒 = 1182503分 = 19708時間 = 821日
つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
7zやrarはzipフォルダーのようなものを実装するのが困難(最後のファイル1つだけがほしくても先頭からすべて展開しなければならない)。圧縮率と引き換えなので一概に悪いとは言えないけど
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:2, 参考になる)
それはソリッド形式とよばれるもので、オプションを外せばファイル単位での圧縮も対応していますよ
ただ書かれている通り、圧縮率はかなり変わってきますが
7zip や rar が劣るとすれば（辞書サイズなど仕方ないけど）メモリ使用量や処理速度、最適化された実装の存在くらいじゃないかな
Re: (スコア:0)
自分で圧縮したファイルだけを扱えればいいわけじゃないからオプションで無効にできても意味がない
Re: (スコア:0)
実装が困難という誤解に対し、そういったオプションが既にあるという指摘をしただけで
入手した圧縮ファイルから 1 ファイルだけ取り出せないから意味がない、ってよくわからん反論だなぁ
全展開するのが大変な圧縮ファイルから 1 ファイルだけ取り出したい、って割とレアケースなのでは
Re: (スコア:0)
前提の、OSの標準として実装って条件が抜けてないかな？
オプションによって内部の単一ファイルを扱えたり扱えなかったりするんじゃ、標準には使えないでしょ。
Re: (スコア:0)
そんな前提は提示されていないのですが……
OS の標準に不適な理由は #4130430 にもある通りライセンスが理由だと思うけど
機能的な理由で不適となるなら、オプションが多すぎて初心者には扱いにくいかも、ぐらいかな（ファイル名も暗号化できるのは必要な機能だけど混乱しそう、とか）
なお可能/不可能の意味で「扱えない」という書き方をしているならこれも誤解で、処理時間がかかるだけで扱えはしますよ
ある程度モダンな環境（CPU/メモリ/SSD）であれば、それほど違和感なく扱えるような実装には出来るんじゃないかな
Re: (スコア:0)
>7z あたりが OS で標準サポートされないのはどうしてなのかな。
Re: (スコア:0)
#4130376 が
> 7z あたりが OS で標準サポートされないのはどうしてなのかな。
に対する回答であるというならそうかもしれませんが明示もされていませんし、技術的な回答に対しては #4130400 で誤りを指摘しています
そこに運用上の問題を #4130408 で追加していますが、それに対しても #4130433 でレアケースじゃないかと指摘しているのですが
追加される後付け理由にも全部回答を提示していて、なお何に疑問を呈されるのか……
Re: (スコア:0)
いうて7zipもrarも公式ツールはアーカイブをフォルダのように操作できますし…
むしろファイルを取り出すときよりファイルを消したり足すときのほうが問題。
あと単純に遅い。
Re: (スコア:0)
一覧を表示するだけならインデックスを見るだけだから速いけど、ファイルを取り出そうとするとわかるよ。少なくとも7-Zipの公式クライアントは
Re: (スコア:0)
ランダムアクセス可(先頭から全て展開する必要がない)、認証つき暗号採用、メタデータ(ヘッダー)も暗号化、マルチプラットホーム、となると思い当たるのは rar, ezio, dar ぐらい。
rar は linux 上で使っても良いモノなんだけどライセンスの問題がどうにもならない。
個人的には ezio を改造して使っている。erasure code があって extend attribute にも対応しているから linux 上で /etc とかまるっと暗号化バックアップ作るのにちょうどいい感じ。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
既知平文攻撃はパスワードの長さ（強度）を無視できます（結果としてパスワードが不明なまま展開される）
そのためパスワードを長くすればするほど総当たりとの差は広がる一方で、それが
> つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。
という一文に現れています
> 7z あたりが OS で標準サポートされないのはどうしてなのかな。
cab があるから、というのと 7z は GNU LPGL なのでライセンス上リバースエンジニアリングの許可が必要など Windows に標準で載せるには縛りが厳しいからではないかな
Re: (スコア:0)
> 7z は GNU LPGL なので
7-ZipはLGPLだけどLZMA SDK [sevenzip.osdn.jp]はpublic domainだよ。7zをサポートするだけならこれで十分なのでライセンスが理由ではない。
Re: (スコア:0)
#4130357に書いたけど実際にはさらに数万倍高速化できると思う
Re: (スコア:0)
LZMAが赤い赤いロシアのアルゴリズムだから。
Re: (スコア:0)
と、中国製の端末を使って書き込んでるんですね
Re: (スコア:0)
7z あたりが OS で標準サポートされないのはどうしてなのかな
自前のフォルダー操作ができて暗号化にも圧縮にも対応したディスクイメージというものがありますので。
Re: (スコア:0)
そういえばWindowsに搭載のtarコマンドはlibarchive実装なので、たぶん7zを読み書きできるはず。OSサポートとして思っているのと違うかもしれないけど。
Re: (スコア:0)
ところがぎっちょん、Windows標準のtarはわざわざ7-Zipサポートをオフにしてビルドされているらしく、使えない。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
既知平文攻撃の場合、パスワードの長さは関係ないからね。
zipcryptoの内部状態は96bitしかないので、ある程度以上パスワードが長くなったらパスワードよりも内部状態で総当りしたほうが速くなる。さらにさまざまな攻撃手法で96bit総当たりより大幅に高速化できることが知られており、既知平文攻撃もその1つ。