アカウント名:
パスワード:
と思って読んだら、なるほど.DS_Storeのパターンが限られているので「既知平文が手に入る」という条件を簡単に満たせてしまうのか
小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。さすがにzipcryptの危険性を知ってるからランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?
> 小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。
既知平文攻撃には連続した8バイトを含む13バイト以上の平文が必要なので、2バイトのファイルが含まれていてもそれだけでは既知平文攻撃はできない。ただし非常に短いファイルはCRCからの逆算により解読されて攻撃の手がかりになることは確か。
> ランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?
勝手にそんなことしたら非対応のソフトで解凍したときランダムなゴミがついちゃうでしょ。脆弱なのがわかっていても互換性のために変更できないから問題なんだよ。逆に処理の変更が許されるなら中途半端なことをしないでAESを採用すればいい。
前半はなるほどです。後半は、zipの暗号化仕様を決めるときの話を想像してたので、勝手にそんな仕様にしても問題はないでしょう、という話です。後付けで勝手にやり方を変えるという突拍子も無いアイデアは想像してませんでした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
と思って読んだら、なるほど.DS_Storeのパターンが限られているので「既知平文が手に入る」という条件を簡単に満たせてしまうのか
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:0)
小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。さすがにzipcryptの危険性を知ってるからランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
> 小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。
既知平文攻撃には連続した8バイトを含む13バイト以上の平文が必要なので、2バイトのファイルが含まれていてもそれだけでは既知平文攻撃はできない。ただし非常に短いファイルはCRCからの逆算により解読されて攻撃の手がかりになることは確か。
> ランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?
勝手にそんなことしたら非対応のソフトで解凍したときランダムなゴミがついちゃうでしょ。脆弱なのがわかっていても互換性のために変更できないから問題なんだよ。逆に処理の変更が許されるなら中途半端なことをしないでAESを採用すればいい。
Re: (スコア:0)
前半はなるほどです。
後半は、zipの暗号化仕様を決めるときの話を想像してたので、勝手にそんな仕様にしても問題はないでしょう、という話です。後付けで勝手にやり方を変えるという突拍子も無いアイデアは想像してませんでした。