web-dev-qa-db-ja.com

AESとCBCを使用する場合、IVをプレーンテキストのハッシュにできますか？

[もともとは、programmers.stackexchange.comにタイトルが付いています：AES + CBCで暗号化して、暗号化されたデータを検索できますか]

基本的には、暗号ブロック連鎖モード、暗号フィードバックモード、出力フィードバックモードのいずれかを備えたAdvanced Encryption Standardを使用します（まだ決めていません）。各モードには初期化ベクトルが必要です。暗号化された文字列を次のように「検索可能」にしたいということです。

データベーステーブルのリストと、各テーブルの「表示名」があるとします。概念的には、リストは次のようになります（私は{xxx}を使用してxxxの暗号化された形式を意味し、[IVx]は初期化ベクトルを意味します）：

ENC_DISPLAY_NAME         | ENC_TABLE_NAME
------------------------ | -----------------
[IV1]{John's table}      | [IV2]{TABLE_3574}
[IV3]{Eric's list}       | [IV4]{TABLE_3100}
                         |
[IV5]{Darren's projects} | [IV6]{TABLE_2823}
[IV7]{Paul's contacts}   | [IV8]{TABLE_5843}

次に、ENC_DISPLAY_NAMEでの検索を許可するとします。 （必要なのは等価検索だけです。）検索したい表示名で使用されている初期化ベクトルを知る方法が必要です。

表示名の128ビットハッシュ（多分CRC）を計算し、それをIVとして使用して暗号化された文字列を計算する必要があると思います。つまり、「ダレンのプロジェクト」を保存したい場合は、次のようにします。

AESKey key = ...;
String str = "Darren's projects";
CRCType crc = ComputeCRC(str);

BinaryString enc = crc.ToBinaryString ( ).Concat
    (EncryptWithAESandCBC(str, key, (IVType)crc));

INSERT INTO MY_TABLE(ENC_DISPLAY_NAME,ENC_TABLE_NAME) VALUES(enc, ...);

代わりに文字列を検索する場合は、最後を除いて同じ手順を実行してから、SELECT * FROM MY_TABLE WHERE ENC_DISPLAY_NAME=enc。

これは以前に試されたことがありますか？ （セキュリティ）リスクはありますか？

[関連質問： プレーンテキストとその暗号文を指定してAES暗号化キーを計算しますか？ ]

appseccryptographyencryptiondatabases
15
Null Pointers etc.

平文で計算されたハッシュは、「均一なランダム性」に関する限り、IVに適切な特性を持っています。これは、暗号的に安全なハッシュ関数、not CRC用です。むしろ、SHA-256のようなものです。 CRCは、暗号化に対して十分に安全ではありません。

ただしの場合、IVは解読する人が知っている必要があるため、暗号化されたメッセージとともに保存する必要があります。 IVが平文からハッシュ関数で計算される場合、これにより平文に対して辞書攻撃を実行できます（ハッシュに一致する平文が見つかるまで可能な平文を試行します）。辞書攻撃を打ち負かすことは、パスワードに対してすでに十分に困難であり、パスワードは安全でランダムに見えるようになっています。したがって、表示名のようにまったくランダムではないものについては、プレーンテキストから計算されたハッシュではなく、適切に安全な暗号化乱数ジェネレータから生成されたIVを実際に使用する必要があります。 IVは生成方法に関係なく保存する必要があるため、ストレージコストは変わりません。

19
Thomas Pornin

短い答え：IVはランダムで、平文で送信する必要があります。

ハッシュのプレーンテキストに関する情報を漏らさないように注意する必要があります。 必須ではないハッシュのレインボーテーブルを使用してプレーンテキストを取得することは可能です。したがって、データベースではなく構成ファイルに保存されているソルト値は、ordreにあります。

ということで、私はこれをお勧めします：

  • 今と同じように保存されたランダムIVを使用する
  • 平文データのソルトハッシュを別の列に格納する
  • ランダムIVと暗号文を取得するためにソルトハッシュを検索する

だからあなたの例では、あなたはこれを持っているでしょう：

NC_DISPLAY_NAME                                            | ENC_TABLE_NAME
-----------------------------------------------------------+------------------
hash(salt+"Darren's projects"), [IV5]{Darren's projects}   | [IV6]{TABLE_2823}

もちろん、ソルトハッシュにはリスクがないわけではありません。それはあなたが最初に避けようとしていたものよりも低いですが、それでも存在します。そのリスクが高い場合は、ECBモードでプレーンテキストハッシュを（別のAESキーで）暗号化し、それを検索できます。したがって、テーブルは次のようになります。

NC_DISPLAY_NAME                                               | ENC_TABLE_NAME
--------------------------------------------------------------+------------------
{k1 hash("Darren's projects")}, [IV5]{k2 Darren's projects}   | [IV6]{TABLE_2823}

ハッシュを実行すると、IVを使用する場合と同等のエントロピー（入力のホワイトニング）が得られます（ただし、それを確認するための計算能力はありません）。暗号化すると、レインボーテーブルや辞書を保護できます。

ランダムなIV暗号化された暗号文の総当たりよりも検索インデックスの総当たりが長くなると、速度のセキュリティのトレードオフが発生することがわかります。

5
ixe013

コンテンツのハッシュをそこに置く場合は、暗号化によってデータの別のコピーが提供されることを認識してください。それを使用しているのがルックアップだけの場合、必要なのはハッシュ（とにかく衝突がなければ）だけです。そのため、名前に基づいて特定の行を探している攻撃者は、データの暗号化された部分を無視して、探しているハッシュを探すだけで、キーを知らなくてもそれを見つけることができます。

ここで、使用しているダイジェストがCRCやハッシュだけでなくHMACである場合は、問題ないかもしれません。ただし、追加の情報を漏らさないように注意する必要があることに注意してください。

0
Yuliy