web-dev-qa-db-ja.com

IV +ソルトは同じですか？

暗号化アプリの実行中に、パスワード作成ビットを取得しました。

PBEKeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 10000, keyLength);

以降の実際の暗号化部分：

cipher.init(Cipher.ENCRYPT_MODE, secret, ivSpec);

初期化ベクトルにはランダムバイトが必要ですが、ソルトにはランダムバイトが必要です。ソルトとIVに同じ（暗号的に安全な）ランダムバイトを使用できますか、それとも暗号化を弱めることができますか？ -できれば、保管が少し簡単になります。

複数のメッセージでIVまたはソルトを再利用することについて話しているわけではありません。個別のメッセージごとに新しいバイトの配列が生成されますが、個々のメッセージごとに2つのソルトに同じ新しく生成されたバイトを使用できます+ IV？

例えば：

メッセージ1：ランダムバイト= h6ds..。ソルト= h6ds/IV = h6ds

メッセージ2：ランダムバイト= djs9..。ソルト= djs9/IV = djs9

メッセージ3：ランダムバイト= 9sdf..。ソルト= 9sdf/IV = 9sdf

... 等々

encryptionsaltinitialisation-vector
7
Crizly

IVは暗号化されたメッセージごとに一意である必要があります。そのため、このパスワードから生成したキーを使用して複数のシークレットを暗号化する場合は、ソルトをIVとして再利用できません。 IVを再利用すると、プレーンテキストに関する情報が漏えいし、最悪の場合、暗号化スキームが完全に破壊される可能性があります（使用しているモードによって異なります）。したがって、再利用すると、暗号化が実際に弱くなります。

ただし、notを再利用していて、1回しか使用されない場合は、同じランダム値が他の場所でソルトとして機能するという事実は、暗号化です。

追加用に編集：この特定のケースに当てはまるとは思わないが、言及する必要がある警告が1つあります。 KDFを使用してキーを生成しているため、ソルトはキーの強度の一部を構成します。 IVが攻撃者にさらされている場合（質問の言い回しを考えると、ここではそうではないと思います）、候補のキーと、弱いパスワードは辞書攻撃の影響を受けやすくなります。しかし、salt/IVが単に保存されているだけで、1つの妥協点が両方の妥協点であると合理的に考えることができる場合、強度に影響を与えないという最初の前提は依然として維持されます。

10
Xander

PBKDF2から取得したキーを使用する暗号化実行のPBKDF2のソルトをIVとして使用すると、ランダムOracleのように動作するPBKDF2に依存するため、2つの使用法が互いに「分離」され、不適切な相互作用が発生しなくなります。これはあまり研究された特性ではありませんが、PBKDF2がHMACへのネストされた呼び出しの多くであり、HMACがランダムなOracleの通常の候補であることを考えると、それはもっともらしいことです。

ただし、別の設計の方が分析が簡単です。KDFで、キーとIVに十分なバイトを生成するだけです。つまり、saltとパスワードから32バイトを生成します。暗号化キー用に16バイト、IV用に他の16バイトです。このようにして、ストレージの請求額を同じレベルに保ち（塩が1つだけで、IVのための余分なスペースはありません）、IVでファンキーなビジネスを行っていないことがある程度明らかになります。追加のボーナスとして、KDFをソルトの値とサイズに関する厳しい要件を持つ別のKDFに切り替えても、暗号化に適切な長さのIVを取得できます。

通常の警告が適用されます：

  • PBKDF2は、非常に優れたパスワードベースのキー導出関数ではありません。特に、実行時間は出力サイズ（しきい値を含む）に比例して増加します。つまり、PBKDF2から20バイトを超える値を取得すると、反復回数を半分にする必要があり、セキュリティに悪影響を及ぼします。また、PBKDF2はGPUで簡単に最適化できます。 Bcryptの方が適しています ; 「任意の出力長」の部分では、パスワードハッシュ関数を [〜＃〜] hkdf [〜＃〜] などの適切な（高速）KDFと組み合わせます。

  • 暗号化を行う場合、おそらく [〜＃〜] mac [〜＃〜] も必要です。これは難しいビジネスです。

2
Thomas Pornin