EverQuestできない日記

EverQuestの研究の一環として、活動記録から研究成果や攻略法、ネタばれ情報までいろいろ書いてました。

BRBF.DLL の評価

2008年02月05日 | 暗号
[ BRBF.DLL Ver. 0.15 (BREG Software) ]


仕様:非公開
 暗号アルゴリズムは Blowfish (ブロック・サイズ 64bit、鍵サイズ 32~448bit) です。利用モードは CFB / OFB / CBCモードで、IV は初期値をそのまま使うことも任意の値を指定することもできます。暗号鍵はパスワードの文字コードをそのまま使ってます。


評価、鍵強度:最大448bit、実装上の安全性:△、処理速度:○


 非商用なら無料で使えてメモリーとファイルの両方を暗号化できるのが特徴です。惜しむらくは、使い方の説明が少ないせいで、誤って脆弱になる可能性があります。正しく使いこなせるだけの暗号に関する知識があれば良いのですが、説明書が簡潔すぎて、暗号のことをよく知らない人には不親切な面もあります。機能的には使いやすくてなかなかいいので、ちょっと残念です。




 基礎的な部分だけのプリミティブな関数となってます。VC で開発してるだけあって、DLL に慣れてれば VB で使うのも簡単です。アルゴリズムこそ古めの Blowfish でブロック・サイズが小さいものの、特に弱点のある暗号ではなく、今でも充分実用に耐えるものと思われます。ただまあ、サンプル・コードなど VB 用の使い方が書いてないので、Win32 API や VC を使ったことが無い VBプログラマーにとっては少し敷居が高いかもしれません。


 処理速度はバイト配列の処理なら Rijn.dll の 2倍とそれなりの速度ですが、非常に高速な JoyCrypt.dll に比べると 1/3 の速度しかありません。AES も速いですが Blowfish も暗号アルゴリズムとしてかなり速い部類なので、これだけ実行速度に差がでるのは、あまり最適化をしてないのではないかと思われます。もっとも、実際にファイルの読み書きまで含むと、差は無い (ディスク・アクセスがボトルネックになる) ので実用面では困りません。個人で非商用なら無料で使えるので、後述する IV の扱いにさえ注意すればファイルやメモリーの暗号化ができたりモードも選べて便利でしょう。


 CBCモードで内部の処理がどうなってるか探りました。
鍵は  「61626300 00000000 00000000 00000000」
平文は 「00000000 00000000」
暗号文は「DC96520E 8FC0D218」
IVは  「FEDCBA98 76543210」になってることが判明しました。
自前で IV を指定しない場合、IV は最初はこの値になります。その後、CBCモードの最後の暗号文ブロックが随時次の IV になるようで、どうも内部で静的変数として IV (一つ前の暗号文) を保持してるもようです。同じ鍵で続けて CBC 暗号化や復号の一方だけを連続して行う時に便利な仕様ですが、暗号化と復号が混ざると IV を指定しないと正しく復号できなくなるので、「IV を指定しなくても動作する仕組み」はあまりよくないように思います。説明書にはきちんと書かれてはいませんが、IV を再初期化する関数があることからして、毎回 IV を指定するか初期化して使えということなのでしょう。


 ここらへんの説明が欠けているので、IV を指定しなくても動作するというのは暗号の使い方をあまり知らない人には安全性を損なう危険性があります。CBCモードやCFBモードでは平文の内容によって次の暗号文が撹乱されるので、IV が初期値や固定でもそう問題になりませんが、OFBモードではそうもいきません。


 OFBモードで内部の処理がどうなってるか探りました。
鍵は  「61626300 00000000 00000000 00000000」
平文は 「00000000 00000000, 00000000 00000000, 00000000 00000000」
暗号文は「DC96520E 8FC0D218, 728DDA62 FC6FDC84, A8287A90 94141211」
IVは  「FEDCBA98 76543210」のままです。
どうもCBCモードと異なり、OFBモードでは IV は初期値のまま変化しないようです。つまり、特に自前で毎回異なる IV を指定しない限り、同じ鍵からは常に同じ乱数列が生成されます。


 ファイルの暗号化における標準モードが OFBモードになっていて、これを IV 指定せずに初期値のまま使い続ける可能性があります。モードごとの特性や想定される危険性がきちんと説明されてないため、ストリーム暗号の基本である、「同じ鍵と IV で 複数の暗号化をしない。」を守らない人が多そうで怖いです。


 例えば、同じ鍵と初期値のままの IVで OFBモードで別の暗号化をしたとしましょう。
平文は 「30313233 34353637, 38394142 43444546, 30313233 34353637」
暗号文は「ECA7603D BBF5E42F, 4AB29B20 BF2B99C2, 981948A3 A0212426」
OFBモードでは平文と乱数列との XOR なので、乱数列が同じなら暗号文同士の XOR は平文同士の XOR になります。そこで、Windows OS 付属の関数電卓で上の暗号文と下の暗号文を XOR すると
上 「DC96520E 8FC0D218, 728DDA62 FC6FDC84, A8287A90 94141211」
下 「ECA7603D BBF5E42F, 4AB49B20 BF2B99C2, 981948A3 A0212426」
XOR 「30313233 34353637, 38394142 43444546, 30313233 34353637」
暗号強度がどうとか言う前に、XOR だけで平文を解読できてしまいました・・・


 これはまあ片方の数値が 0 の場合、XOR するともう一方の数値のままになるという特性によるもので、実際には全て 0 のファイルを暗号化することはないので、解読するのはもっと手間になります。しかし、平文同士の XOR が判明してる以上、一箇所でも片方の平文がわかれば、もう片方もわかるということで、既知平文攻撃に対しては無力です。ファイルにはフォーマットによってヘッダーなど値が決まってる部分があるので、そういうところから切り崩される可能性もあります。


 とにかく、ファイルの暗号化に関して標準が OFBモードになっていて、なおかつ IV を変更せずに固定された初期値のまま使えてしまうというのは、ユーザーを危険な方向にミスリードしてしまう問題点だと言えます。暗号化されたファイルに IV が含まれないのも不便で、復号する時に同じ IV を設定する必要性からついつい固定にしてしまいそうです。OFBモードでは IV を自前で設定しないとエラーがでるようにするとか、毎回変えるように説明書に警告を書いておくとか、暗号初心者に対する安全性の配慮が欠けているように思います。せっかく IV を自前で設定できるので、使うときは必ず設定しましょう。IV は乱数が望ましいですが、暗号文ごとに変化する値なら乱数性はそう気にしなくていいです。ファイルを暗号化する際には、暗号化したファイルの名前に IV を含めるようにすれば、復号するときにファイル名から IV を取得して設定することができます。


最新の画像もっと見る