1

私は、多数のファイルで非対称暗号化を使用するシステムに取り組んできました。私は現在、4096 ビット キーで RSA を使用して、各ファイルに対してランダムに生成された 256 ビット AES キーを暗号化していますが、必要な操作の 1 つはすべてのファイルをスキャンすることであるため、パフォーマンスがやや不足しています (システムが稼働している場合の推定数)。使用数は約 10,000 です)、特定の秘密鍵を使用して復号化できるものを識別します。この操作がすぐに完了するとは思っていませんが、現時点では時間がかかりすぎています (1 秒あたり最大 2 ファイルの処理)。キーの長さを減らすことを検討しましたが、2048 ビットに減らしても、必要なレベルのパフォーマンスが得られません。512 ビットでほぼカットできますが、そのようなキーを簡単にクラックできるようになったため、それは問題外です。

より高速でありながら同様の暗号強度を持つシステムの方向性を教えてくれる人はいますか? 既存のアプリケーションにきちんとプラグインするには、Java JCA プロバイダー (例: bouncycastle など) を介して実装する必要があります。弾む城が El Gamal をサポートしていることは知っていますが、このアルゴリズムがどれほど強力であるか、または RSA よりも高速である可能性があるかどうかについての詳細はわかりません。また、比較的短いキー (384 ビットなど) しか必要としない楕円曲線システムについても耳にしますが、これらのいずれかの実装がどこにあるのかわかりません。

4

3 に答える 3

4

尋ねられた質問については、「ECDH」としても知られる楕円曲線上でDiffie-Hellmanを試してください。現在の技術では破れないサイズを扱うと、セキュリティの見積もりは少し難しくなります。これは、将来の技術の進化にどのように賭けるかに依存するためです。それでも、P-256曲線上のECDHは、「128ビット」のセキュリティを提供します。これは、2048ビットRSAから得られるレベルと同様のレベルです。このレベルは、現在のすべての使用法に対して広く十分です。より適切に言えば、P-256が十分でない場合、問題には非常に特別なニーズがあり、暗号化の強度が最も心配する必要はありません。

私のPC(2.4 Ghz Intel Core2、64ビットモード、Linuxを実行)では、OpenSSLは、単一のコアを使用して、1秒あたり約900のECDHインスタンスを処理すると主張しています。

編集:長さに応じた主要なセキュリティの見積もりについては、いくつかのアルゴリズムについては、このサイトを参照してください。

于 2010-02-02T19:27:36.463 に答える
2

各キーの暗号学的に強力なハッシュを計算し、それを各ファイル名とともに平文で保存してみませんか? 次に、すべてのファイルと照合する必要があるキーがあれば、そのキーをハッシュしてテーブルで検索するだけです。

于 2010-02-02T19:11:18.740 に答える
0

私はより少ないRSA操作を必要とするアプローチに行きます。SSL / TLSは、AESなどのキーの暗号化にRSAなどを使用しますが、パケットごとに、またはあなたの場合にセキュリティを実行するのに十分な大きさのキーサイズで計算コストのかかる操作であるという理由だけで、データにAESを使用しないでください。 、ファイルごとに。

別の公開鍵システムは次のとおりです:http://en.wikipedia.org/wiki/ElGamal_encryption。セキュリティ面では、まだ壊れていないと思いますが、個人的には今のところRSAに信頼を置いています。現在利用可能な楕円曲線暗号化アルゴリズムがあるかどうかはわかりません。つまり、それらが研究されていることはわかっていますが、実稼働で使用する準備ができていない可能性があることを理解しており、特許の問題があると聞きました。

于 2010-02-02T19:16:57.860 に答える