14

私たちはプロジェクトでいくつかの厳しいセキュリティ要件を実行することを目指しており、パフォーマンスの高い多くの暗号化を実行する必要があります。

PKIは対称暗号化よりもはるかに低速で複雑であることは知っていると思いますが、自分の気持ちを裏付ける数字が見つかりません。

4

7 に答える 7

31

はい、純粋な非対称暗号化は、対称暗号 (DES や AES など) よりもはるかに低速です。これが、実際のアプリケーションがハイブリッド暗号を使用する理由です。高価な公開鍵操作は、対称アルゴリズムの暗号化鍵を暗号化 (および交換) するためだけに実行されます。実際のメッセージの暗号化に使用されます。

公開鍵暗号化が解決する問題は、共有秘密がないことです。対称暗号化では、すべての関係者が鍵を秘密に保つことを信頼する必要があります。この問題は、パフォーマンスよりもはるかに大きな懸念事項です (ハイブリッド アプローチで軽減できます)。

于 2008-09-23T00:54:15.097 に答える
31

OS X 10.5.5 を実行し、OpenSSL のストック ビルドを実行する Macbook では、「openssl speed」は AES-128-CBC を 46,000 1024 ビット ブロック/秒でクロックします。その同じボックスは、毎秒 169 署名で 1024 ビット RSA を記録します。AES-128-CBC は「教科書」のブロック暗号化アルゴリズムであり、RSA 1024 は「教科書」の公開鍵アルゴリズムです。それはりんごとオレンジですが、答えは次のとおりです。RSA ははるかに遅いです。

ただし、それが公開鍵暗号化を使用すべきでない理由ではありません。本当の理由は次のとおりです。

  1. 公開鍵の暗号化操作は、生データの暗号化を目的としていません。Diffie-Hellman や RSA などのアルゴリズムは、ブロック暗号アルゴリズムの鍵を交換する方法として考案されました。したがって、たとえば、安全な乱数ジェネレーターを使用して AES 用の 128 ビットのランダム キーを生成し、それらの 16 バイトを RSA で暗号化します。

  2. RSA のようなアルゴリズムは、 AES よりも「ユーザーフレンドリー」ではありません。ランダムキーを使用すると、AES にフィードする平文ブロックは、キーを持たない人にはランダムに出てきます。これは実際には RSA には当てはまりません。RSA は --- AES よりも --- 単なる数学の方程式です。そのため、キーを適切に保存および管理するだけでなく、RSA プレーンテキスト ブロックのフォーマット方法にも細心の注意を払う必要があります。そうしないと、脆弱性が発生します。

  3. 公開鍵は、鍵管理インフラストラクチャなしでは機能しません。公開鍵を検証するスキームがない場合、攻撃者は実際の鍵ペアを独自の鍵ペアに置き換えて、「中間者」攻撃を仕掛けることができます。これが、SSL が証明書の厳密な役割を通過することを強制する理由です。AES のようなブロック暗号化アルゴリズムもこの問題に悩まされていますが、PKI がなければ、AES は RSA と同じくらい安全です。

  4. 公開鍵の暗号化操作は、AES よりも実装上の脆弱性の影響を受けやすくなっています。たとえば、RSA トランザクションの両側は、RSA 式に供給される数値であるパラメーターに同意する必要があります。攻撃者が暗黙のうちに暗号化を無効にするために代入できる邪悪な値があります。同じことが Diffie Hellman にも当てはまり、さらに楕円曲線にも当てはまります。もう 1 つの例は、2 年前に複数のハイエンド SSL 実装で発生した RSA 署名偽造の脆弱性です。

  5. 公開鍵を使用することは、「通常とは異なる」ことをしている証拠です。普通でないことは、まさに暗号化で絶対に望んでいないことです。アルゴリズムだけでなく、暗号設計は、安全と見なされるまで何年にもわたって監査およびテストされます。

アプリケーションで暗号化を使用したいクライアントには、次の 2 つの推奨事項があります。

  • 「保存データ」については、 PGP を使用します。本当！PGP は 10 年以上にわたって叩かれてきましたが、愚かな実装ミスから安全であると考えられています。それにはオープンソースと商用版があります。

  • 「転送中のデータ」には、TLS/SSL を使用します。TLS ほどよく理解され、よくテストされているセキュリティ プロトコルは世界中にありません。あらゆる金融機関が、最も機密性の高いデータを移動するための安全な方法としてこれを受け入れています。

ここにまともな記事があります[matasano.com] 私とプロの暗号学者である Nate Lawson が数年前に書いたものです。これらの点について詳しく説明します。

于 2008-09-23T22:13:06.863 に答える
11

OpenSSLspeedサブコマンドを使用して、アルゴリズムのベンチマークを行い、自分の目で確かめてください。

[dave@hal9000 ~]$ openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     139343.68k   152748.27k   155215.70k   155745.61k   157196.29k


[dave@hal9000 ~]$ openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 9267 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 299665 2048 bit public RSA's in 9.99s
...
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s    927.6  29996.5
于 2008-09-23T00:48:38.090 に答える
4

実際の PKI ベースの暗号化システムでは、非対称暗号化を使用して対称キーを暗号化し、そのキーを使用して対称暗号化を使用してデータを暗号化します (そうは言っても、誰かが反例を指摘するでしょう)。

そのため、非対称暗号アルゴリズムによって対称暗号アルゴリズムに課せられる追加のオーバーヘッドは固定されています。これは、データ サイズには依存せず、キー サイズにのみ依存します。

前回これをテストしたとき、3 つほどの X.509 証明書のチェーン [編集して追加: 署名したデータ] を検証するのに、100MHz 程度で実行されている ARM で数秒かかりました (多くの繰り返しの平均で、明らかに）。どれだけ小さいか思い出せません - 無視できるほどではありませんが、1 秒未満です。

正確な詳細を思い出せなくて申し訳ありませんが、要約すると、非常に制限されたシステムを使用しているか、多くの暗号化を行っている場合 (1 秒間にできるだけ多くの SSL 接続を受け入れたい場合など) を除き、NIST 承認の非対称暗号化方式は高速です。

于 2008-09-23T00:54:08.700 に答える
2

どうやらそれは1000倍悪いです。（http://windowsitpro.com/article/articleid/93787/symmetric-vs-asymmetric-ciphers.html）。しかし、実際に大量のデータを処理しているのでない限り、それは問題にはなりません。できることは、非対称暗号化を使用して対称暗号化キーを交換することです。

于 2008-09-23T00:50:18.273 に答える
0

おそらく、プロジェクトに関する詳細を追加して、より質の高い回答を得ることができます。何を確保しようとしていますか？誰から？セキュリティの要件を説明できれば、はるかに良い答えが得られます。暗号化メカニズムがあなたが思っているものを保護していない場合、パフォーマンスはあまり意味がありません。

たとえば、X509証明書は、クライアント/サーバーエンドポイントを保護するための業界標準の方法です。PGPの装甲は、ライセンスファイルを保護するために使用できます。簡単にするために、両方のエンドポイントを制御する場合、Blowfish（および他の暗号のホスト）を使用した暗号ブロックチェーンは、PerlまたはJavaで簡単に使用できます。

ありがとう。

于 2008-09-23T02:15:31.920 に答える