ハッシュを暗号化キーとして使用する場合、PBKDにソルトは必要ですか？
AES256でデータを暗号化するためにパスワードからキーを生成しています。生成されたハッシュは保存されないので、ソルトを使用する必要がありますか？ソルトを使用して公開した場合、暗号化されたデータの安全性は低下しますか？
生成されたハッシュは保存されず、暗号化キーとしてのみ使用され、暗号化されたデータの中央リポジトリがないため、レインボー攻撃から保護する必要はないと思います。
新しい情報に基づいて回答を更新しました：
パスワード/パスフレーズのエントロピーが低い
パスワードに関しては、人間はあまり創造的ではありません。このため、これらのパスワードは、暗号化キーを生成するためのシードとしては不適切な選択肢になります（エントロピーが高いはずです）。 研究 からの引用：
Burnettは昨年、600万のユーザー名とパスワードの組み合わせを分析し、ユーザーの91％が1,000の最も一般的なパスワードの1つを使用していたことを発見しました。99.8％が最も一般的な10,000のパスワードを使用しています。そして、「パスワード」はそれらすべてのリーダーであり、ユーザーアカウントの4.7％で使用されていました。
辞書（Rainbowではなく）攻撃はあなたが心配すべきものです
上記の統計を考えると、可能性のある暗号化キーの合計の非常に小さなサブセット（数千または数百万！）を扱っている可能性があります。 256ビットのAESキーのアドレス空間は2 ^ 256です。そのような場合、辞書攻撃を心配する必要があります。
次のPBKD関数について考えてみます。
上記のPBKDFは、（パスワード||塩）の組み合わせに対してハッシュ関数のc反復Hを実行します
また、100万個のパスワードのパスワードディクショナリと、アプリケーションに100人のユーザー
塩なし
ユーザーごとのソルトがない場合、上記のPBKDF関数は次のようになります。
攻撃者が行う必要があるのは、辞書内の各パスワードに対応する1MAESキーの辞書を計算することだけです。
The number of times a user needs to run the KDF function = 1M.
塩あり
各ユーザーがソルトを持っているので、AESキーの一般的な1Mリストは機能しません。攻撃者は、特定のユーザーの特定の可能なAESキーのセットを作成するために、ユーザーごとに1M KDF操作を行う必要があります。
The number of times a user needs to run the KDF function = 100M.
BcryptやscryptなどのPBKDFは、これらのような辞書攻撃を防ぐためだけに意図的に遅い関数になっています。
最後に
結果のキーがよりエントロピーを持ち、攻撃者が辞書ベースのブルートフォース攻撃を行うには、ユーザーごとに辞書を計算する必要があることを確認するために、PBKDF関数でソルトを使用することをお勧めします。 PBKDF関数は低速になるように設計されているため、ユーザーごとの辞書リストの作成は、単一のリストよりも桁違いに遅くなります。
古い答え
ソルトは、2人の異なるユーザーが同じパスワードと同じデータを持っているシナリオで役立ちます。確定的暗号化が使用される場合、結果の暗号テキストは同じになり（PBKDFを使用して導出された暗号化キーが同じになるため）、暗号解読のベクトルが開かれます。パスワードがソルトされている場合、結果の暗号文は前述の場合とは異なります。
塩は秘密ではありません。塩を暗号化/非表示にする必要はありません。ただし、ユーザーごとに一意である必要があります。
また、ユーザー/パスフレーズの概念がない場合は、PBKDFを使用してキーを生成する必要はありません。ルーカスが述べたように、安全な乱数ジェネレーターを使用して、ランダムキーを直接作成できます。
PBKDF2は、パスフレーズからキーを取得するために使用されます。パスフレーズを実際に使用せずにキーを生成するだけの場合は、安全なランダムジェネレーターを使用してバイトのセットを生成することもできます。
ソルトはデータの安全性を低下させません。ソルトは秘密とは見なされません。