データベース行レベルの暗号化スキーム

Question

データベース内の機密性の高いデータを保護したいのですが。これは、データが暗号化され、敵の手に渡った場合、100年間安全である必要があることを意味します。また、RAMの平文で一度に脆弱なデータの量を制限したいと思います。これにより、プレーンテキストデータがディスクにページングされる可能性が低くなります。また、データベースは非常に大きい場合があるため、データベースにアクセスするためだけにデータベース全体を一度に復号化するよりも効率的である必要があります。したがって、データベースの行レベルで機密データを暗号化することを考えています。これは、レコードを参照する一意のインデックスが暗号化されていないため、各レコードを引き続き検索/取得できますが、機密データ自体は暗号化されています。

私の解決策は、データベースの行ごとにデータを持つことです：

index | IV | sensitive encrypted data | MAC

256ビットのデータベースキーは、/ dev/randomを使用して生成される機密データを暗号化するために使用されます。
各行のIVは、/ dev/urandomから256ビットになります（/ dev/randomより高速）。
暗号化アルゴリズムはTwofishです。
各レコードのMACは、キーを使用したインデックス、IV、機密データのHMAC-SHA3です。

システムはシングルユーザーです。ユーザーは強力な英数字のパスフレーズ（最小19文字）を作成します。

パスワードベースのキー導出関数がパスフレーズで実行され、導出された暗号化キーが作成されます。これは、Twofishでデータベースキーを個別に暗号化するために使用されます。これは、ユーザーがデータベース全体を再暗号化せずにパスワードを変更できるようにするためです。代わりに、新しいパスワードを作成してデータベースキーを再暗号化するだけです。これがスキームの最も弱い部分であることは理解していますが、攻撃者がパスワードの推測をブルートフォース攻撃することを非常に困難にしたいと思います。暗号化されたデータを保持するデバイスと同時にあらゆる種類のセカンダリトークンが危険にさらされる可能性があるため、セキュリティはパスフレーズの強度に依存する必要があると思います（デバイスとトークンは任意の理由で没収される可能性があると考えています）空港のセキュリティを通過するため、無駄になります）。

パスフレーズからキーを導出するために、PBKDF2は、256ビットの出力と/ dev/urandomから取得した256ビットのソルトを備えたHMAC-SHA3を使用して、10,000回の反復で使用されます。
私がやろうとしているのは、データを安全にするために必要なパスワード文字数と、低速のプロセッサとメモリが限られているモバイルデバイスのユーザーにとって適度に速くするために必要なパスワード文字数のバランスをとることです。ユーザーがPBKDFが完了するまで5秒以上待つことはないと思います。
MACはHMAC-SHA3-256（派生暗号化キー、salt |暗号化データベースキー）を使用して作成され、ディスク上のsaltおよび暗号化データベースキーの横に保存されます。ログイン時にこれを確認して、正しいパスワードを入力したことを確認できます。

プログラムが読み込まれると、ユーザーはパスフレーズを入力します。 KDFが実行され、データベース暗号化キーを復号化するためのキーが生成されます。プログラムが実行されている間、実際の暗号化キーはRAM=に保持される唯一のものであり、必要に応じて個々のデータベースレコードを検証および復号化するために使用されます。

行レベルIVの最適な長さは何ですか？256ビットで問題ありませんか？
パスワードの最小強度は19文字、PBKDF2の10,000回の反復は256ビットのデータベースキーを保護するのに十分な強度ですか？そうでない場合、どのパラメーターが機能しますか？
PBKDF2はまだここで使用するのに良いアルゴリズムですか？そうでない場合、どのScryptパラメータですか？
システムを安全にするためのその他の変更または推奨事項

FauChristian · Answer

行レベルIVの最適な長さは？ 256ビットでいいですか？

答えは、プレーンテキストの一部が既知であるか、攻撃者が簡単に推測できるかによって異なります。質問では、データは「非常に機密」であり、保護期間は「100年」であると説明されているため、暗号化に便利な最強の暗号と最大の秘密を使用します。

19文字の最小パスワード強度とPBKDF2の10,000回の反復は、256ビットデータベースキーを保護するのに十分強力ですか？そうでない場合、どのパラメータが機能しますか？

文字数に対する答えは、検証中にパスワードに課せられた規則を知らなければ決定できません。

PBKDF2はまだここで使用するのに良いアルゴリズムですか？そうでない場合、どのScryptパラメータですか？

回答が存在しますこれは、bcryptまたはPBKDF2に関する優れた背景情報を提供します。

システムを安全にするためのさらなる変更または推奨事項はありますか？

はい。たくさんの。ここにいくつかあります。

復号化後にクエリ結果で再構築できる冗長性をすべて削除します。
暗号化の前にブロックを使い果たすために使用されるソルトが本当に予測不可能であることを確認してください。（サーバーで取得できる最高のエントロピーソースを使用してください。）
クリティカルペイロードを統計的に独立させて、クリティカルテキストのプレーンテキストバージョンのメモリフットプリントを削減できる場合は、クリティカルペイロードをそれほどクリティカルでないペイロードから分離します。