2016-07-19 12 views
-1

私たちは、サーバーからの要求/応答を暗号化/復号化するアプリケーションを開発しました。我々は 暗号化/復号化アプリケーションの性能テストを行っていましたが、多くのスレッド が同時にそれをやっている間に、暗号化/復号化プロセスに時間がかかることがわかりました。問題を特定するために、私たちは暗号化/復号化プロセスの一部であるすべてのメソッドを記録しています。 ロガーからは、Key Fetchingプロセスがプロセス全体の時間の70〜80%を費やしていることがわかりました。Javaキーストアでパフォーマンスの問題が発生していますか?

  1. 私たちは、暗号化/復号化のためのAESアルゴリズムを使用している
  2. AESキーは一意のIDを持つキーストアに格納されます。
  3. 暗号化/復号化処理の前に、キーストア&から一意のIDに対して格納されたAESキーを取得し、暗号化/復号化を実行します。
  4. キーストアのサイズが大きくなるとパフォーマンスが悪化しています。

さらに分析すると、キーストアは内部的にHashTableを使用していることがわかりました。これはパフォーマンス上の問題ですか?

キーストアのサイズが2002である--- TPSは85 キーストアのサイズは14007です - TPSは助けてください38

です。

+0

アンドロイドキーストアプロバイダに言及しないんではありません! Javaキーストアの参照 –

+0

パフォーマンスが問題になったときの店舗の規模は?この情報を回答ではなく質問に追加してください。 – zaph

+0

これは@Kalpen Patelの質問に関連していますか?その場合は、質問の1つを調整して削除してください。 – zaph

答えて

0

注:この使用法は、使用されているキーストア形式(JKS、BKS、JCEKS、...)の詳細を指定していないため、前提に基づいています。

鍵が必要なたびに、ファイル(JKS形式)からJavaキーストアをロードするとします。

キーストアはパスワードで保護されています。キーストアはパスワードで保護されています(空のパスワード)。パスワード文字列は、Javaキーストアを保護する暗号化キーを生成するために使用されます。

あなたの主な問題は、パスワードからのキー導出プロセスが、SHA1の1000回以上の反復をパスワードで実行する反brute-forceアルゴリズムを組み込んでいることです。これは、ブルートフォース攻撃を遅らせるために存在する意図された結果である多くの時間を消費する。

編集:JKSフォーマットは、ロード時にこの操作を実行するだけでなく、キーをロードするときも同様です。

結論:毎回Javaキーストアまたはキーをロードしないでください。 1分に1回以上ロードするようには設計されていません。

+0

私たちはJKSを使用しています。私たちはいつもキーストアを読み込んでいません。私たちはスタートアップ時にそれをやっています。 –

+0

しかし、鍵の復号化をトリガーするたびに鍵をロードしているため、すでに判明しているように多くの時間を消費します。 – Robert

+0

アプリケーション起動時に、キーをコンカレントハッシュマップにロードしてから、そのマップを永遠に使用します。キーはキーストアではなくハッシュマップから取得されます。 –

0

私はこの問題に直面していました...そして私はこれをベローズポストで回答しました。

実行速度に関する問題は、オペレーティングシステムのプラットフォームによって異なります。

Jvmはキーストアをメモリにロードします。そして内部ストレージとしてのハッシュテーブルコレクションを持っています。

ハッシュテーブルが同期されています。

キーストアからget操作を実行するたびに、物理キーストアからではなくメモリ内キーストアから取得されるよりも、get操作を実行するたびにLinuxベースのOSで( "top" - %wa section)コマンドを使用して確認できます。

キーストアはハッシュテーブルを使用しており、パフォーマンスの低下の根本原因です。

私はプロジェクトを初期化している間にキーストアのすべてのキーをConcurrentHashMapにロードすることでこの問題を解決しました。キーストアの代わりにMAPからすべての読み取り操作が実行されます。そして、すべての書き込み操作がキーストアとMAPの両方で実行されることを確認してください。これが役立つ

Java Keystore.getKey() slow while Key store size Increase

・ホープ..

関連する問題