Java暗号化：AES/CBC/PKCS5Paddingシナリオで使用する種子

Question

私は、AES/CBC/PKCS5Paddingメソッドを使用してデバイス上のユーザーのデータを暗号化するアプリケーションを構築しており、セキュリティは非常に重要です。誰かがデータベースを取得した場合のブルートフォース攻撃を防ぎたい。

テーブルの各行には、関連するタイトルがあります。私は種として何を使うべきか分かりません。私は、次のいずれか行うことができます。

1. ハードコード私自身のシードソースのを、私はこれは誰かが私のアプリを逆コンパイル場合

2. のように、ユーザが入力したタイトルを使用して読み取ることができると信じて他の方法は、上記のすべてのシナリオで、がない限りシード

3. は、私はC、私自身の種子の連結と同様に入力されたタイトル

を使用します種を見つけ出す誰かを視覚化する。これは暗号化されたデータを無理やりにすることができるという点で、これは役に立ちますか？もちろん、上記のすべてのシナリオでは、ユーザーのパスワードをキーの一部として含めることもできます。

潜在的なハッカーにとって、どうすればそれを難し​​くすることができますか？

編集（再編集）以下の回答と私の研究や思考のプロセスに基づいて

。私は次のことができると思う。

1. ユーザーがパスワードを入力しますが、機密データを格納する前に、データベース
2. に保管していないが、彼らはそれを識別するためのラベルを入力する必要があります。私はこれをデータベースにテキストとして保存し、塩として使用します
3. 私は、PBKDF2でユーザーのパスワードとラベルを使用してキーを生成しますが、それを保存しません。
4. ＃ 3は
5. を解読するために機密データを暗号化するために、私は再びユーザのパスワードと行ラベルをオフに基づいて鍵を生成し、機密データ

この音権利をいを復号化するためにそれを使用するのだろうか？ハッカーは、2つの列（クリアテキストのラベル）と暗号化されたデータでデータベースを保持すると何かを推論できますか？

編集2

私は具体的にはAndroidのアプリケーションを構築するために計画していて、次のリンクは、私が必要なものに強打しました。

https://nelenkov.blogspot.in/2012/04/using-password-based-encryption-on.html?m=1

https://android-developers.googleblog.com/2013/02/using-cryptography-to-store-credentials.html?m=1

Answer 1

正しいアプローチは、暗号化と復号化のためのサーバー側のソリューションを持つことです。それがオプションでない場合、データの各行に対してsaltを維持し、クライアント側のアルゴリズムで暗号化/復号化の鍵としてsaltを使用することをお勧めします。

Answer 2

ここでの問題は、誰かがアプリケーションを逆コンパイルするたびに、キーを生成する方法が自明であることです。したがって、そのキー生成への入力データのすべてが分かっている場合、キーの生成は簡単です。

このため、AES暗号化で使用されるパスフレーズを入力する可能性があります。パスフレーズを強引にすることが困難になるように、PBKDF2などのシステムを使用していることを確認してください。

データベースがユーザーのデバイスに格納されておらず、外部に格納されている場合は、デバイスにsecure random keyを生成して格納し、実際に中央データベースに格納される前にデータを暗号化する必要があります。私のコメントと、編集内容を1として

Answer 3

、可能な解決策は、この（私は実際にJavaプログラマないんだけど、下記の擬似コードは、明確にする必要があり）に沸く：

aesKey <- PBKDF2-SHA512(userPassword)[:32] 
hmacKey <- PBKDF2-SHA512(userPassword)[32:] // PBKDF2-SHA512 has a natural 64 byte output 

iv <- CSPRNG(16) // 16 byte IV for AES from a CSPRNG 
ciphertext <- AES256CBC(plainText, aesKey, iv) // Use PKCS5Padding 

result <- iv + ciphertext // Prepend the IV. 
result <- HMAC-SHA256(result, hmacKey) + result 
// Prepend the HMAC of the IV and ciphertext using the hmacKey. Always encrypt THEN mac. 

のカップル重要なノート：

• あなたは常にHMACにIVを含める必要があります。 HMACは暗号文だけではありません。

• SHA512とSHA256の選択が重要です。 SHA512は64バイトの自然出力を持つため、PBKDF2を使用して2つの32バイト鍵を導出するのに最適です。このアルゴリズムを調整すると、次のバイトロットを生成するための最終的なPBKDF2イテレーション以外のものを使用することになりますが、これは有益ではありません。

• PBKDF2に使用する塩は、実際にはそれほど重要ではありません。あなたはこれをランダムに生成して暗号文と一緒に格納することができますが、この例ではPBKDF2の静的な塩が問題ありません。