SSL / TLSの対称暗号化セッションキー
この質問は、SSL/TLSプロトコルで使用されるセッション送受信キーに関係します。私の理解では、この鍵は対称暗号化（DES、AES、BlowFishなど）を使用していると思います。公開鍵と秘密鍵のペアが鍵交換セキュリティに関して対称鍵よりも優れている場合、セッションに非対称暗号化を使用しないのはなぜでしょうか。キーも？
これは既存の質問の拡張です： PKIのセキュリティ、証明書、認証局、秘密の転送
3つの理由（現在）：
- 非対称暗号化は、対称暗号化よりも遅く、はるかに低速です。桁違いに遅い。
- 同じキー長の場合、非対称はビット単位の対称よりもはるかに弱くなります。したがって、同等の保護を提供するには、より大きな鍵が必要です。これは、1で述べた速度低下の原因にもなります。
- （@ThomasPorninのコメントによると:)非対称暗号化を使用すると、出力サイズが増加します。たとえば、RSAを使用する場合、暗号化されたデータはクリアテキストよりも少なくとも10％大きくなります。一方、対称暗号化では、ギガバイトのデータを暗号化する場合でも、固定サイズのオーバーヘッドがあります。
非対称暗号化アルゴリズムは、対称アルゴリズムよりもはるかに効率的ではありません。したがって、基本的に非対称キーによる暗号化のすべての使用には、実際のメッセージが暗号化される対称セッションキーの暗号化が含まれます。
キーの長さに関するAviDの役立つメモに加えて、量子コンピューティング攻撃が実行可能になると、すべての主流の公開キーアルゴリズム（したがってSSL/TLS）が無効になります。しかし、量子コンピューター攻撃があったとしても、まっすぐなAES-256は強いままです。 Key size-Effect of Quantum Computing Attacks-Wikipedia を参照してください。問題は、それらの鍵を交換して信頼を確立する方法に戻ります。
これは、ハイブリッド暗号システムと呼ばれる標準的なアプローチです。対称暗号法と非対称暗号法には、それぞれ長所と短所があります。特に：
- 非対称暗号化により、1人の参加者だけが復号化できるメッセージを誰でも暗号化でき、1人の参加者だけが署名できるメッセージを誰でも確認できます。
- 対称暗号化は、非対称暗号化よりもはるかに高速です。本当に、たくさん。
対称暗号方式と非対称暗号方式のどちらを選択するかについては、セキュリティは本当に問題ではありません。非対称暗号化は、対称暗号化では解決できない問題を解決します。それ以外の場合は、対称暗号化が使用されます。これは非常に高速だからです。
（高速であることの結果として、対称暗号はより高いセキュリティマージンを持つ傾向があります：共通の鍵サイズ— 128ビットAES —は完全に斬新な数学的進歩を妨げるほど十分に大きく、現在地球上に存在するすべてのコンピューターは長期間動作します宇宙が存在しているので、暗号化を破る可能性はほとんどありません。非対称暗号化は、そのパフォーマンスが低いため、より小さなマージンで実行され、一般的に使用される鍵サイズを数年間問題なくするクラッキング方法で数学的改善が時折ありますが、必ずしもそうとは限りません数十年間ですが、これは、機能/パフォーマンスの代替案と比較して、二次的な懸念事項です。）
ハイブリッド暗号化システムは、必要な場合にのみ非対称暗号化を使用することにより、ジレンマを解決します。
- メッセージの署名を確認するために、メッセージは ハッシュ であり、非対称暗号化はハッシュでのみ使用され、可変長メッセージでは直接使用されません。
- 一部のデータを暗号化するために、対称的な セッションキー が生成されます。非対称暗号化は、参加者（クライアントとサーバー）の間でこの対称鍵を共有するために使用されます。 「実際の」データは暗号化され、この対称キーを使用して authenticated になります。
HTTPSはウェブで一般的に使用されているため、サーバーには公開鍵がありますが、クライアントにはありません。どのブラウザーもサーバーにアクセスでき、サーバーはクライアントが誰であるかを気にしません。 （ クライアント側の証明書は、意味のある場所で使用されます 。）HTTPSセッション確立の非常に高レベルで不完全なビューは次のとおりです。
- サーバーはその certificate をクライアントに送信します。証明書には、サーバーの公開鍵、および 認証局 によるその公開鍵の署名が含まれています。クライアントは認証局が既知の認証局であることを確認します（ブラウザーには認証局の公開鍵のリストが付属しています）。
- attacker がトラフィックを検査するだけで、またはトラフィックを変更するだけで（または少なくともアクティブな）キーを再構築できないように、クライアントとサーバーは対称キーを選択するように調整します攻撃者が検出され、クライアントまたはサーバーがセッションを中止します）。 A Diffie-Hellman鍵交換 プラスサーバーによる署名（クライアントに、交換が中間者攻撃ではなくサーバーで行われたことを確認させるため）が1つの可能性です対称鍵を生成します。また、サーバーの秘密キーのみに依存することも可能です（ただし、 転送秘密 は保証されません）。
- 以降のすべての通信では、その対称鍵が使用されます。
上記の多くの簡略化を行ったことに注意してください。詳細については、以下をお読みください。