パスワードを変更できるファイル暗号化
私のアプリは、デバイス上の暗号化されたユーザーファイルで動作する必要があります。誰かがデバイスを手にしたとき、それはデータを秘密に保つべきです。このため、私は次のスキーマについて考えています（これは間違っている可能性があるため、私が尋ねているのはそのためです）。
- アプリはランダムなキー
k（事前定義された固定長）を生成します。これは、ファイル暗号化のマスターキーとして使用されます。 - これは_
K = k || o_を定義し、oはゼロのストリング（事前定義された固定長）です。 - ランダムなソルトを生成して保存します。
h("")を計算します。つまり、キー導出関数を空の文字列に適用します（これは初期パスワードです。ユーザーがデータを保存する前にパスワードを変更するように求められるので問題ありません）。K ^ h("")をキーファイルに保存します（長さが一致していると仮定します）。
パスワードを検証するために、キーファイルの内容はh(password) ^ h("")でxorされます。結果は_k || o_でなければなりません。つまり、（少なくとも）oの長さと同じ数のゼロで終わる必要があります。
パスワードを変更するために、古いパスワードが検証され、チェックに合格すると、キーファイルの内容がh(oldPassword) ^ h(newPassword)でxorされ、結果によってキーファイルが上書きされます。
Xoringで十分かと思います。スキーマ全体が混乱している可能性は十分にありますが、適切なものを見つけることができませんでした。
私はあなたの設定は実際には大丈夫だと思います、提供されます：
- h()関数は、ブルートフォース攻撃を遅くするための低速の反復ハッシュです
- マスターキーによる暗号化は正しく行われます。 AES-GCM
- 鍵のサイズは適切で、おそらく128ビットkおよび256ビットo
しかし、私はあなたがここのエッジに正解であることに注意します。これは正しく理解するのが難しいものであり、弱点を簡単に持ち込む可能性があります。また、これは暗号の愛好家による迅速な分析であり、専門家ではありません。
マスターキーは Key Wrap -NISTの推奨事項に従って保護する必要があります 800-38F （2012年に最終化）が最善のアプローチです。
マスターキーはそれほど長くないため（128/256ビット）、最終的な暗号化されたマスターキーの暗号文によって公開される情報を最小限に抑えることが重要です。
- ランダム塩/ IV。 IVを公開しないでください。ランダムなソルトを使用しないという一見逆に思われる決定の概要については、これを参照してください crypto stackexchangeからの回答 。暗号文に含める必要のないハードコードされたIVを使用する方がはるかに良いです。
- 認証。いくつかの認証された暗号化スキーム（AES-GCMなど）が存在しますが、ここでも認証署名が公開されないように注意する必要があります。
NISTキーラップスキームは、XOR関数を巧みに使用してこれらの要素を直接暗号文に組み込みます。そのため、提供する必要があるのは強力な暗号化キーだけです。