7

Xoomタブレットで簡単なAndroidアプリを作成しました。これは、SQLCipherデータベースに文字列のメモを保存するだけです。

ユーザーは、SQLCipherlibによってデータベースに使用されるパスフレーズを入力するように求められます。これは今のところうまく機能し、非常にスムーズです。

今、私は認証の目的で小さなPBKDF2アルゴリズムも実装しました(実際、将来的に他のファイルを暗号化したいのですが、データベースに保存することはできません)。しかし今のところ、私は自分のpbkdf2アルゴリズムが正しいかどうかをチェックするようになりました。私はjavax.cryptoとjava.securityライブラリのみを使用しました。

次のようなコードスニペット:

int derivedKeyLength = 128;
int iterations = 500;
KeySpec spec = new PBEKeySpec(passphrase.toCharArray(), salt, iterations, derivedKeyLength);
SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
byte[] derivedKey = f.generateSecret(spec).getEncoded();    

ソルトは、SecureRandomで生成された16バイトの乱数です。

そこで、キーとソルトをハードコーディングし、認証のために派生キーを比較しました(テストケースのみ!)

私の問題は、Xoomでは、反復が500のみに設定されているにもかかわらず、派生関数が完了するまで約5秒続くことです。

AFAIK SQLCipherは、デフォルトで4000の反復回数を使用しており、キーが間違っているか正しい場合、即座に応答します。(反復を4000に設定した場合、少なくとも15秒かかります)

問題は、それを非効率的に実装したのか、それともSQLCipherのパフォーマンスが非常に優れているため(ネイティブNDK関数など)なのかということです。

よろしくお願いしますps:申し訳ありませんが、私の英語はまだそれほど素晴らしいものではありません!

編集:

申し訳ありませんが、私は十分に明確ではありませんでした:-)

PBKDF2は遅い(具体的には、ブルートフォース攻撃を遅くするための反復量)と想定されていることを私は知っています。それがまさに私が求めている理由です!反復回数を5000と言うように設定したかった(これは受け入れられず、15秒以上)

私が言ったように、SQLCipherは特定のパスワードからキーを導出するためにPBKDF2(反復= 4k、私は500を使用しています)も使用しているので、私はただ疑問に思っています。結局のところ、AESを使用した暗号化について話しているのではなく、キーを取得する際の違いについてのみ話しているのです。

もちろん、SQLCipherが自作のキー派生関数よりもはるかに高速であることは正当なようですが、SCLCipherのPBKDF2は実際に瞬時に動作するため、これほど大きな違いになるとは思いませんでした。

ご挨拶!

4

2 に答える 2

10

OK、それ(以下を参照)は正確にはあなたの問題ではありません。PBKDF2は遅いですが、そのハードウェアのそれらのパラメーターで説明されているほど遅くはないはずです。Android PBE / KDFのパフォーマンスに関するいくつかの統計(およびヒント)があります:http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.htmlSecretKeyFactoryパフォーマンスの問題は不明ではありません:LVLとAESObfuscatorを使用したSecretKeyFactoryのひどいパフォーマンスを回避する方法はありますか?

SecretKeyFactory純粋なJava実装を使用している可能性があります。SQLCipherには、関連する2つの機能があります。

  • OpenSSL、コンパイルされたネイティブコードを使用します(私のデスクトップでは、 OpenSSLのPBKDF2は、JVMの起動時間を除いて2000回の反復でJVM6SecretKeyFactoryバージョンよりもほぼ100倍高速です。AESの速度を比較していません。他の人はAndroidでも遅いと感じているようです)
  • 4000回の反復PBKDF2は、データベースが開いているときにのみ実行され、その後、ページHMACシークレットに対して最大2回の反復が行われます(文書化されているように、デフォルト構成を想定しています)

あなたのコードは正しいようです。反復を増やしても、それほど大きな(線形?)パフォーマンスの低下はないはずです。XoomはJITで非古代のJVMを実行している必要がありますが、他のコードでパフォーマンスの問題を確認できますか?


PBKDF2は、(この質問への回答https://security.stackexchange.com/questions/7689/clarification-needed-for-nists-whitepaper-recommendation-for-password-based-keを参照)低速になるように設計されています。意図されたキーストレッチ操作。反復カウンターを使用すると、速度とセキュリティのトレードオフが可能になります。

AESは常に高速であることが意図されており、高速です(速度比較PDF、選択されたAES候補は、その論文では元の名前Rijndaelで参照されています)。

PBKDF2の計算時間を、SQLCipherデータベースでSQL操作を実行するのにかかる時間と直接比較していると思います。SQLCipherデータベースは、ほぼ確実に高速になるように設計されています。

要件が異なる2つの異なる操作を効果的に比較しているため、速度が異なります。

于 2013-03-07T10:42:53.187 に答える
2

わかりました、私は問題が何であるかを理解しました。

デバイスをPCから切断すると、すぐに機能します。その後再接続した場合も。

これで、反復量が5000以上であっても、導出関数は1秒未満で済みます。私のXoomはすべてのデバイスの中で最新ではないので、これは素晴らしいことです。

デバッグモードか何かのせいかもしれませんが、実はよくわかりません!

とにかく、mr.spuraticに感謝します。これが将来誰かに役立つことを願っています:-)

于 2013-03-08T08:09:20.130 に答える