Rijndael Salt、IV、パスフレーズを変更するためのベストプラクティス（アプリケーションセキュリティポリシー）とは
（注：SO-SSEに投稿することをお勧めします）
Rijndael暗号化に関して、これらの値（特にC＃.NET Webアプリケーション）の1つ以上の定期的な変更に関するベストプラクティス（および結果）は何ですか（ある場合）：
- 塩
- 初期化ベクトル（IV）
- パスフレーズ
アプリケーションの存続期間中にこれらの値のいずれかを変更することは一般的な方法ですか（実際には必要ですか）。 （たとえば、1つ以上が侵害された場合、または一般的なポリシーの一部としてのみ。）
その場合、元の（以前の）値を使用して暗号化されたデータベース内の既存のデータにはどのような影響がありますか？これらの値を変更することにより、既存のデータの復号化が「機能」しない（または誤った情報が返される）と考えられます。
（この質問の範囲には、そのような値が格納される方法が含まれる可能性があると思います-たとえば、サードパーティまたはその他の安全なストレージメカニズムを使用して-最初に、前述の値が現在RijndaelCryptographyという名前のクラスにプレーンテキストで格納されているとしましょう。そこから続けます。）
私の質問を説明するには、次のリンクを参照してください。 方法：対称（Rijndael）キーを使用してデータを暗号化および復号化する（C＃/ VB.NET）
その特定の例は何らかの方法で優れていますか（パス/ソルト/ IVをコードレベルで修正）？
更新1
- 質問から「AES」を削除しました。
更新2
- マイクロソフトがRijndaelの代わりにAESを使用することを勧めていることを読みました
「RijndaelクラスはAesアルゴリズムの前身です。Rijndaelの代わりにAesアルゴリズムを使用する必要があります。詳細については、.NET Securityブログのエントリ「RijndaelとAESの違い」を参照してください。 " （ リンク -そのページの半分を参照）
AESはキーとIVのみを受け取ります。 IVはランダムで、暗号化ごとに異なる必要があります。暗号文の前に追加するだけです。また、認証を追加することを強くお勧めします。
パスフレーズに関しては、単純なランダムキーを優先して、可能な限り回避します。鍵は単純で安全であり、鍵導出のコストを回避します。パスワードは、ユーザーが入力する必要がある場合にのみ使用してください。
本当にパスワード、十分な反復回数が必要な場合は、ランダムなソルトを生成し、PBKDF2（またはそれ以上）を使用します。このハッシュとソルティングは、弱いパスワードを補うためだけにあります。
キー導出で新しいソルトをいつ選択するかはより複雑です。理想的には、暗号化ごとに新しいランダムなものを使用しますが、コストがかかりすぎる可能性があります。それらを再利用できる場合もあれば、キーをキャッシュできる場合もありますが、それはアプリケーションによって異なります。
ソースコードにキーをハードコードしません。 web.configファイルは、より適切な場所のようです。アプリケーションで必要なため、キーを実際に非表示にすることはできません。
自分で暗号を実装するべきではありません。あなたの質問を考えると、あなたが間違っている可能性のあるものが多すぎます。代わりに、 高レベルのライブラリを使用 GPG（保存データを暗号化するため）またはTLS（移動中のデータ用）のように。
（独自に実装している場合は パスワードから暗号化キーを生成しないでください ;代わりに、真のランダムキーを使用する必要があります。必要に応じて、メッセージごとにランダムIVを選択する必要がありますモードによって。そして、あなたは 認証された暗号化/メッセージ認証を使用する必要があります 。しかし、実際には、学習することが多すぎるため、独自のものを実装するべきではありません。
既存の回答は素晴らしいですが、質問の1つの重要な側面である新しいIV、モード、キーへの移行は無視してください。
これを行う最も簡単な方法は、データベースに新しい列を追加することです。 1つは暗号化キーID（使用される暗号化キーを識別する一意の値）、1つは暗号化アルゴリズム、もう1つはIVです。
現在の設定では、現在の暗号化パスフレーズへの間接参照となるUUIDを生成します。これは、既存のすべての暗号文のキーID列に入力されます。完全なアルゴリズム名、ビットサイズ、およびモード（たとえば、「AES-128-ECB」を使用している場合）は、アルゴリズムの列に表示されます。そして、現在の静的IVがIV列に入ります。
新しい暗号化の場合は、CSPRNG（暗号で保護された疑似乱数ジェネレータ）から新しいキーを作成し、このキーを識別する新しいUUIDを作成します。適切なモードを選択します（CBCとCTRは適切な選択です。CBCは、すべての意図と目的のために、CSPRNGからの乱数を必要としますが、CTRは、単純なカウンターである可能性がある一意のナンスのみを必要とします）。新しい暗号化ごとに、選択したモードのIV要件に従って一意のIVを生成します。キーとIVを使用してデータを暗号化し、キーID、アルゴリズム、IV、および暗号文をデータベースに保存します。
復号化には、データベースに記録されているキー（IDで参照）、アルゴリズム、IV、および暗号文を使用します。キーIDが現在使用しているキーと一致する場合は、上記のプロセスを使用して、データをreencryptにする必要もあります。
一般的に、ソルト（通常はパスワード）で保護しているものを再暗号化するたびに、新しいソルトを作成します。
新しいIVを使用する必要がありますeveryメッセージを暗号化する時間。重複するIVはneverを使用する必要があります。つまり、暗号化されたメッセージごとに異なるIV値を使用する必要があります。
パスフレーズは、ユーザーにとって実用的な頻度で定期的に変更されます。これは、月に1回から年に1回の範囲です。私が働いたほとんどの場所では、90日ごとにログインパスフレーズを変更する必要があります。パスフレーズをあまりにも頻繁に変更すると、ずさんなユーザーの習慣につながります（つまり、ポストイットノートを使用してそれらを追跡します）、頻繁に変更しないと、セキュリティ違反の可能性が高くなります。