データベースに暗号化して保存したい小さな秘密がたくさんあります。データベース クライアントにはキーがあり、データベース サーバーは暗号化と復号化を処理しません。私のシークレットはすべて 16 バイト以下です。これは、AES を使用する場合に 1 ブロックだけを意味します。私は定数 IV (およびキー) を使用して暗号化を決定論的にしています。決定論的暗号化を行う理由は、暗号文を使用してデータベースに簡単にクエリを実行し、同じ秘密が 2 回格納されないようにするためです (列を UNIQUE にすることにより)。 ）。私が見る限り、キーが秘密である限り、これを行うことに問題はないはずです。しかし、私は確信したい: 私は正しいか間違っているか? 私が間違っている場合、どのような攻撃を行うことができますか?
ところで: 考えられる平文の数が比較的少ないため、ここではハッシュはまったく役に立ちません。ハッシュを使用すると、元の平文を取得するのは簡単です。
長さnビットのメッセージの理想的な暗号は、2 n ! そのような順列。「キー」は、選択された順列の説明です。
安全なブロック暗号は、理想的な暗号と見分けがつかないと想定されており、nはブロック サイズです。AES の場合、n=128 (つまり 16 バイト)。AES は安全なブロック暗号であると考えられています。
すべてのシークレットの長さが正確に 16 バイト (または 16 バイト未満で、明確に 16 バイトに拡張するためのパディング規則がある) の場合、理想的な暗号が必要であり、AES は「それ自体」で問題ありません。パディングを適用し、任意の長いストリームを処理する一般的な AES 実装では、ECB モードまたはすべてゼロの IV を使用する CBC モードを要求することで、単一ブロック暗号化を取得できます。
IV に関するすべての問題と、そもそも CBC などの連鎖モードが必要だった理由は、マルチブロック メッセージに由来します。AES は 16 バイトのメッセージを (それ以上でもそれ以下でもない) 暗号化します。連鎖モードは、より長いメッセージの理想的な暗号をエミュレートすることです。アプリケーションで、すべてのメッセージの長さが正確に 16 バイトの場合 (または、より短いが、パディングを追加する場合)、「生の」AES だけが必要です。固定 IV は生の AES に十分近いエミュレーションです。
ただし、次の点に注意してください。
暗号化された要素をデータベースに保存していて、アプリケーションの存続期間全体で一意性が必要な場合、秘密鍵は長期間有効です。秘密鍵を長期間秘密にしておくことは、難しい問題になる可能性があります。たとえば、長期間有効な秘密鍵には、何らかのストレージが必要です (これは再起動に耐えます)。故障したハードディスクをどのように管理していますか? 酸で満たされた大釜でそれらを破壊しますか？
暗号化は、完全性ではなく機密性を保証します。ほとんどのセキュリティ モデルでは、攻撃者がアクティブになる可能性があります (つまり、攻撃者がデータベースを読み取ることができれば、おそらくデータベースに書き込むこともできます)。アクティブな攻撃は、さまざまな問題を引き起こします。たとえば、攻撃者がデータベース内の秘密の一部を交換するとどうなるでしょうか? またはランダムにいくつかを変更しますか？いつものように、暗号化は簡単な部分です (本当に「簡単」というわけではありませんが、他の作業よりもはるかに簡単です)。
アセンブリが公開されている場合、または公開される可能性がある場合は、Reflector を使用してそれを使用するソース コードを公開することで、キーと IV を検出できます。データが本当に機密である場合、これが主な問題になります。MSIL を難読化することは可能ですが、それでは追跡が難しくなります。それでもコンピューターで消費できる必要があるため、真に暗号化することはできません。
静的 IV を使用すると、実装が周波数攻撃に対して脆弱になります。AES CBC 暗号化の場合、IV の重要性は何ですか?を参照してください。