対称的に暗号化されたデータをURLで渡す場合、または暗号化されたデータをCookieに保存する場合、同じURLで対称暗号化IV（Salt）を渡すことは、合理的および/または必須であり、および/または可能ですか？Saltを使用するというアイデアは、Webなどのステートレス環境でも有効ですか？
（名前やアカウントなどのリストを指定すると、データベースでsaltがどのように機能するかは理解できますが、ステートレス環境でデータを渡すため、saltを保存することはできません。
データの暗号化と復号化に使用されるサーバー側のパスワードを想定すると、Saltはどのように使用できますか？別のIVをクエリ文字列で渡すことができると思いますが、ソルトを公開していますか？
または、「パスワード」のハッシュからキーとIVを生成することもできます。IVとキーがハッシュの重複しない領域から来ていると仮定すると、これは大丈夫ですか？（ソルト/キーは特定のパスワードで常に同じになることを理解しています。）
編集：通常はAESを使用します。
暗号化ルーチンごとにランダムなIVを生成することをお勧めします。これらは、暗号文とともに安全に渡すことができます。
編集：
ソルトは通常、対称暗号化ではなくハッシュに使用されるため、保存している情報の種類と、AES暗号化でソルトを使用している理由を尋ねる必要があります。塩が公に入手可能である場合、それはそれを持っているという目的を無効にします。
攻撃者がソルト、IV、および暗号文を持っている場合、弱いキーに対してブルートフォース攻撃を簡単に実行できるため、実際に行う必要があるのは、キーの強度を確保することです。
秘密鍵から初期化ベクトルを生成しないでください。初期化ベクトルは、特定のメッセージに対して予測できないものにする必要があります。キー (またはキーの生成に使用されるパスワード) から生成した場合、IV は常に同じになり、その目的が無効になります。
ただし、IV は秘密である必要はありません。保護されていない暗号文で送信することは非常に一般的です。URL に IV を組み込むことは、特定のサーバー側の状態で特定のリンクの IV を追跡しようとするよりもはるかに簡単です。
ソルトと IV には異なる用途がありますが、同様の方法で作用します。
暗号化された「ソルト」は、パスワードベースの鍵導出アルゴリズムで使用されます。認証のためにハッシュされたパスワードを保存することは、この関数の特殊なケースです。ソルトは、同じパスワードで異なるハッシュを生成し、ハッカーが一般的なパスワードのハッシュ値を事前に計算し、「逆引き」インデックスを構築して、特定のパスワードをすばやく発見できるようにする「辞書攻撃」を阻止します。ハッシュ。IVのように、使用される塩は秘密ではありません.
初期化ベクトルは、CBC のようなフィードバック モードで、DES や AES のようなブロック暗号で使用されます。各ブロックは、暗号化されると次のブロックと結合されます。たとえば、CBC では、暗号化の前に、前のブロック暗号文が現在のブロックの平文と XOR 演算されます。IV はランダムに生成され、プロセスをブートストラップするためのダミーの初期ブロックとして機能します。
メッセージごとに異なる IV が選択される (または、少なくとも選択されるべきである) ため、同じメッセージが同じキーで暗号化された場合、結果の暗号文は異なります。その意味で、IV は塩に非常に似ています。暗号ランダム ジェネレーターは、通常、salt または IV の最も簡単で最も安全なソースであるため、それらにも類似点があります。
暗号化は非常に簡単に台無しになります。自分が行っていることに確信が持てない場合は、保護している情報の価値を考慮し、必要なトレーニングや相談を受けるために適切な予算を立てる必要があります。