後続の鍵導出でパスワード/鍵を検証する方法
ユーザーがアプリに初めてログインするとき、PBKDF2を使用してパスワードからAESキーを取得します。 AESキーはRAMのみに保持され、セッション中に他のキーとデータを暗号化およびラップするために使用されます。
現在のセッションが終了すると、キーは破棄されますが、暗号化されたデータと派生設定（ソルト/反復回数など）は次回のために保持されます。
その後のログインでは、パスワードと設定に基づいてキーを再取得しますが、キー（パスワード）が有効であることを（ある程度の信頼度で）確認してから使用します。
キーの導出はすでに（意図的に）長時間実行されており、別の長時間実行ハッシュアルゴリズムを使用してそのプロセスを長くしたくないため、パスワードに対してハッシュも計算する必要はありません。
私はこれに対するいくつかの解決策を見てきましたが、従うべき標準があるかどうか疑問に思っています。私がこれまでに見たもの：
- 暗号化エンジニアリングでは、Schneier et alは、導出関数のn番目の反復からハッシュデータを取得し、それをソルト、パスワードなどでハッシュして検証コードを形成することを提案しています。これを保存して、キーを導出するときに候補に対して同じコードを計算できます。それらが一致しない場合、あなたは拒否します。 欠点：サードパーティの暗号ライブラリを使用している場合、これを行うためにPBKDF2の内部状態にアクセスすることはおそらく不可能です。
SHA256(key+salt+password)のようなものを計算し、それを保存します。候補者を計算し、一致しない場合は拒否します。キーを使用して、既知のパターンまたはサフィックスで何かを暗号化し、それを保存します。例えば.
E(key, <32 bytes random data> + <32 bytes of 0>`.これを保存し、候補キーを使用して復号化し、サフィックスが一致するかどうかを確認します。選択した0の数によって、誤検知の可能性が決まります。
後者はシンプルで効果的なようですが、私はこの問題について専門家/当局からの明確なアドバイスを探しています。
通常、対称鍵を使用して暗号化する場合は、変更を検出するための整合性チェック（a [〜＃〜] mac [〜＃〜] ）も含める必要があります。データを監視できる攻撃者がデータを変更できない攻撃モデルはほとんどないため、通常、何らかの整合性チェックが必要です。 。
整合性チェックは、スタンドアロンのMACアルゴリズム、通常はHMACにすることができます。または、暗号化モードに統合することもできます（ [〜＃〜] gcm [〜＃〜] のように）。暗号化システムとMACを安全に組み立てるのは、通常想定されるよりもはるかに難しいため、後者を強くお勧めします（たとえば、 this を参照）。
暗号化システムに整合性チェックが含まれていると仮定すると、パスワードの修正を検証するための自然で安全な方法は、暗号化された小さなファイルを従来の内容で保持することです。ファイルの復号化にはMACの検証が必要であるため、パスワード（間接的に）。