プレーンテキストとその暗号文を指定してAES暗号化キーを計算しますか？
暗号化された文字列を含むデータベーステーブルをOracleで作成する必要があります（つまり、列はRAWです）。文字列はアプリケーションによって暗号化され（AES、128ビットキーを使用）、Oracleに格納され、後でOracleから取得されて復号化されます（つまり、Oracle自体が暗号化されていない文字列を見ることがありません）。
2つの文字列の1つになるこの1つの列を見つけました。誰かが気づき、おそらくAESキーを理解するためにこれらの2つの値が何であるかを理解するのではないかと心配しています。
たとえば、列が暗号文＃1または＃2のいずれかであることが誰かにわかった場合：
暗号文＃1：
BF,4F,8B,FE, 60,D8,33,56, 1B,F2,35,72, 49,20,DE,C6.暗号文＃2：
BC,E8,54,BD, F4,B3,36,3B, DD,70,76,45, 29,28,50,07.
対応する平文を知っている：
平文＃1（「デトロイト」）：
44,00,65,00, 74,00,72,00, 6F,00,69,00, 74,00,00,00.平文＃2（ "シカゴ"）：
43,00,68,00, 69,00,63,00, 61,00,67,00, 6F,00,00,00.
暗号化キーが「バッファロー」であると彼は推測できますか？
42,00,75,00, 66,00,66,00, 61,00,6C,00, 6F,00,00,00.
私は、Plaintext＃1をCiphertext＃1に変換できる128ビットのキーが1つだけあるべきだと考えています。これは、代わりに192ビットまたは256ビットのキーを使用する必要があるか、または他の解決策を見つける必要があることを意味しますか？
（余談ですが、ここには、同じ平文だが鍵が異なる2つの暗号文があります。）
暗号文＃1 A（ "デトロイト"）：
E4,28,29,E3, 6E,C2,64,FA, A1,F4,F4,96, FC,18,4A,C5.暗号文＃2 A（「シカゴ」）：
EA,87,30,F0, AC,44,5D,ED, FD,EB,A8,79, 83,59,53,B7.
受け入れられた回答は危険なほど誤解を招くと思われるため、コミュニティWikiとして回答を追加しています。ここに私の推論があります：
問題は、AESキーを導出できるかどうかということです。その点では、受け入れられた答えは正しいです。それは 既知のプレーンテキスト攻撃 と呼ばれ、AESはその種の攻撃に耐性があります。そのため、攻撃者はこれを利用してキーを取得し、データベース全体を処理することはできません。
しかし、ここには別の潜在的に危険な攻撃があります：a Ciphertext Indistinguishablity Attack 。ウィキペディアから：
暗号文の区別がつかないは、多くの暗号化スキームのプロパティです。直感的には、暗号システムが区別できない特性を持っている場合、攻撃者は暗号化したメッセージに基づいて暗号文のペアを区別できなくなります。
OPは、この列が2つの可能な値の1つを保持していることを示しました。暗号化は確定的であるため（つまり、ランダムIVを使用しない）、攻撃者はどの行が互いに同じ値を持っているかを確認できます。攻撃者がしなければならないのは、1つの行のその列のプレーンテキストを見つけ出すことだけで、列全体の暗号化を解読しています。データを非公開にしたい場合の悪いニュース-私が想定しているのは、そもそもデータを暗号化した理由です。
緩和策：これを防ぐには、暗号化を非決定的（または少なくとも攻撃者に非決定的）にして、同じ暗号化を繰り返す平文は異なる暗号文を生成します。たとえば、ランダムな 初期化ベクトル（IV） を使用して Cipher Block Chaining（CBC）モード でAESを使用することにより、これを行うことができます。 secure random number generator を使用して、各行に新しいIVを生成し、IVをテーブルに格納します。この方法では、キーがなければ、攻撃者はどの行が一致するプレーンテキストを持っているかを知ることができません。
nビットの鍵を使用したブロック暗号の場合、プレーンテキストブロックと対応する暗号文を指定すると、鍵は2n-1平均すると、そのブロック暗号は「壊れている」と言われ、暗号技術者はそれを使用しないようにします。 AESは（まだ）壊れていません。だから心配ありません。
ただし、まだいくつかのことが言われている場合があります。
- 平文とそれに対応する暗号文があると、攻撃者は潜在的な鍵の値を検証できます。
- 2n-1値は、実際にはキースペースの半分のサイズです。攻撃者は、1つのキーが一致するまで、可能なすべてのキーを試すことができるという考えです。平均して、彼は正しいキーを押す前に半分のキーを試す必要があります。これは、キースペースにサイズ2があることを前提としていますん。キースペースを削減する可能性はまだあります。たとえば、キーが米国の町の名前であると判断した場合、可能なキーの数は非常に少なくなります（米国には10万以上の町はありません）。 。したがって、キー生成プロセスで実際に128ビットキーが生成される可能性がある場合にのみ、128ビットセキュリティが保証されます。
- 各値をAESコアに直接詰め込んで暗号化しているようです。 AESは確定的であるため、これは、同じ値を持つ2つのセルが同じ暗号化ブロックを生成することを意味し、攻撃者はそれに気付く可能性があります。言い換えると、どのセルが互いに等しいかについての情報をリークします。状況によっては、これが問題になる場合とそうでない場合があります。あなたはそれに気づくべきです。
- 16バイトを超える値をどのように処理するかは言いません。これは単純な問題ではありません。一般的に、これにはCBCなどの 連鎖モード と、初期化ベクトルが必要です（モードによって異なります。 CBC、16バイトのランダムな値-each暗号化された値の新しいIV）（これにより、前のポイントからの情報漏えいも修正できます）。
答え：いいえ、このシナリオではAESキーを復元できません。 AESは既知の平文攻撃に対して安全です。つまり、攻撃者が平文とそれに対応する暗号文（不明なAESキーでの暗号化）を知っていても、攻撃者はAESキーを復元できません。特に、攻撃者はAESキーをランダムに選択したとすると、単純に可能なキーを次々に試すよりも速くAESキーを回復することはできません。
追伸暗号化に使用しているものは、IVを使用していないようです。これはセキュリティ上のリスクです。使用している操作モードはわかりませんが、ランダムなIVには、よく知られている暗号化モード（CBCモード暗号化、CTRモード暗号化など）を使用する必要があります。同じメッセージを複数回暗号化すると、常に同じ暗号文が得られるというセキュリティリークは避けた方がよいでしょう。このリークは、適切なIVで標準の操作モードを使用することで回避できます。 （おそらく、メッセージ認証コード（MAC）を使用して暗号文を認証し、変更を防止する必要があります。）
暗号化をソルトします。
そうすれば、暗号化にパターンがなくなります。 （他にもメリットがあります！）
https://stackoverflow.com/questions/5051007/what-is-the-purpose-of-salt
AESは、Rainbowテーブルを作成するほど簡単ではありません。最初に理解する必要があるのは、テーブルに初期化ベクトルが必要であることです。これを半定期的に変更している限り、（実際には現実的ではない）レインボーテーブルを作成するには、非常に長い時間がかかります。桁違いに長い。一般的なRainbowテーブルは基本的に2次元であるため、IVとキーの両方を理解するには、結果セットのキューブが本質的に必要になります。
Thomas Porninの投稿を読んだ場合、彼は、結果の力ずくの強制という点で、これが何を意味するかについてかなり詳細に説明しています。
現実的な心配は、データベースにアクセスできる誰かが別のフィールドから文字列を挿入できることです（おそらく、要素ごとに列でランダムなパディング値を使用していないためです。またはシード。）
値をシードすると、この問題は発生せず、暗号文自体に対する唯一の（現実的な）攻撃ははるかに困難になります。