web-dev-qa-db-ja.com

ユーザー指定のパスワードを使用してファイルを安全に暗号化する

私は現在、node.jsを使用してnode-webkit用に記述された（一種の）安全なデスクトップベースのRTFテキストエディタを構築しようとしています。ここで読んだいくつかの回答に基づいています。たとえば、- 「文字列」パスワードをAESで使用されるキーに安全に変換するにはどうすればよいですか？ および PKBDF2-SHA256を使用する場合の推奨反復回数？ とりわけ、私は思いついたしかし、私はこれらのアルゴリズムをどのように組み合わせたかについてはかなり確信が持てず、誰かがシステムをチェックしてくれることを望んでいました。

初めてのアプリケーションの初期化時：

  1. 1024の暗号的に安全な疑似乱数バイトを生成します（k）
  2. ソルトとしてさらに256個の^を生成します（s）
  3. ユーザーパスワードを要求する（p）
  4. Sをソルトとして使用してPBKDF-2を使用してpをストレッチし、64Kラウンド（n =ラウンド数）を512バイト（長さ= l）の長さにします（P）（私のシステムでは1秒強かかります）
  5. PをキーとしてAES-CBCを使用してkを暗号化します（K）
  6. お店 s||n||l||Kディスク上

新しいファイルを暗号化して保存する場合：

  1. ユーザーパスワードを要求する（p）
  2. 読んだ s||n||l||Kディスクから
  3. 上記のステップ3と同様に、ステップ2のp、P、およびsを使用して、nをlにストレッチします。
  4. Kを使用してPを復号化します
  5. kを使用して、AESCBCを使用してファイルデータを暗号化します。ディスクに保存

考えられる懸念事項（これは最新のラップトップ/デスクトップで使用できることになっていることに注意してください）には、次のものがあります。

  • マジックナンバー（64K、512、1024）
  • iVなし（必要かどうかわからない）
  • アルゴリズムのいくつかの組み合わせについて何か
  • 他の愚かな間違い
encryptionaesfile-encryptionpbkdf2
2
Vivek Ghaisas

私の観察は次のとおりです。

  • lの値を保存しても意味がありません。代わりにnを保存する必要があります。 PBKDF2は、lの値ごとに異なるシーケンスを生成するのではなく、シーケンスをより長く拡張することに注意してください。
  • AESは256ビット（32バイト）以下のキーを受け入れるため、kに1024バイト、Pに512バイトを生成するのは奇妙に思えます。
  • 暗号化のステップ5で、kはAES-CBCを使用して暗号化されると言いますが、IVがどのように選択されるかについては言及しません。 kには重複するブロックがないため、これはここではそれほど重要ではありませんが、暗号モードを適切に使用することをお勧めします。
  • 復号化のステップ5で、IVを指定せずにAES-CBCについて再度言及します。これは非常に重要です。IVを不適切に選択すると、システムが完全に破損する可能性があります。
  • ファイルまたは保存されたメタデータに信頼性を提供しません。 AES-CBCは順応性があり（つまり、暗号文はキーを知らなくても平文に影響を与える方法で変更できる）、構造が特に影響を受けやすいため、これは実際には重要です。

あなたの一般的な構造は実際には大丈夫ですが、安全な構造と弱い構造を区別する詳細が欠けています。

これが私がそれをする方法です：

  • pをユーザーのパスワードとします。
  • let kd（データキー）はランダムな128ビット値です。
  • s（salt）をランダム、ランダムな128ビット値とします。
  • cを反復回数とします。例： 1,000,000。
  • let km（マスターキー）およびka（認証キー）は、PBKDF2（p、s、c、32）の2つの16バイト（128ビット）の半分として計算されます。つまり、ユーザーパスワードとソルトのPBKDF2で、反復回数、および32バイトの出力長。
  • let k 'd（暗号化されたデータキー）はAES（kd、km）、ECBモードで128ビットAESを使用。
  • [〜＃〜] iv [〜＃〜]をファイルデータの暗号化時に使用する初期化ベクトルとします。
  • [〜＃〜] q [〜＃〜]（メタデータ）を連結値としますs | c | k 'd | IV。
  • しましょうaQ[〜＃〜] q [〜＃〜]の信頼性レコードであり、H（Q、ka）、ここで[〜＃〜] h [〜＃〜]はHMAC構造の暗号化ハッシュ関数です。 HMAC-SHA256。
  • ストア[〜＃〜] q [〜＃〜]およびaQファイルヘッダー内。

128ビットキーが使用されており、AESのブロックサイズは128ビットであるため、計算時に暗号化する必要があるブロックは1つだけですk 'dしたがって、ECBモードのAESは安全です。 CBCまたは別のモードを使用するという追加の複雑さは不要です。

メタデータの信頼性レコードを提供することで、攻撃者がファイルの復号化に必要なパラメーターを「微調整」するのを防ぐことができます。最も重要なことは、IVの信頼性を提供することです。これは、変更の主要なターゲットです。値を使用してxorを実行すると、復号化時にプレーンテキストの最初のブロックもその値を使用してxorを実行するためです。この特性は、展性として知られています。部分的に知られている（たとえば構造化された）平文の場合、これは壊滅的な影響を与える可能性があります。

ここから、ファイルの暗号化と復号化の残りのプロセスを推定できるはずです。私が行う追加の1つは、暗号化されたデータのHMACハッシュを計算し、それをヘッダーに格納して、暗号化されたデータの信頼性を確保することです。

5
Polynomial