2048ビットSSLおよび256ビット暗号化について
DigiCertのページでは、256ビットの暗号化を使用した2048ビットのSSLを宣伝しています。 http://www.digicert.com/256-bit-ssl-certificates.htm
ここの違いは何ですか？なぜ2つの暗号化ビットが参照されているのですか？
これが広告のスクリーンショットです。
GeotrustのプレミアムSSL広告では、次のように宣伝しています。
Security: domain control validation, strong 256-bit encryption, 2048-bit root
では、256ビットの暗号化と2048ビットのルートの違いは何ですか？
問題が明確になることを願っています。
2048ビットはRSA鍵ペアに関するものです。RSA鍵は大きな整数を含む数学オブジェクトであり、「2048ビット鍵」は大きな整数がよりも大きいような鍵です22047が2より小さい2048。
256ビットはSSLに関するものです。 SSLでは、サーバーキーはランダムな256ビットのキー（）を送信するためにのみ使用されます1つは数学的な構造を持たず、単なる束ですビット）;大まかに言えば、クライアントはランダムな256ビットキーを生成し、それをサーバーのRSA公開キー（サーバーの証明書にあり、「2048ビットキー」であるキー）で暗号化して、結果をサーバーに送信します。サーバーはそのRSA秘密鍵を使用して操作を元に戻し、クライアントが選択した256ビットの鍵を取得します。その後、クライアントとサーバーは256ビットを使用して対称暗号化と整合性チェックを行い、RSAはその接続ではこれ以上使用されません。
詳細については this answer を参照してください。この設定は、しばしば「ハイブリッド暗号化」と呼ばれます。これは、RSAがバルク暗号化には適切でないために行われますが、対称暗号化は、物事を開始するために必要な最初のパブリック/プライベートビジネスを実行できません。
（SSLはRSA以外のアルゴリズムとの鍵交換を行うことができるため、上のテキストの説明を少し簡略化しましたが、それがアイデアの要点です。）
もう少し詳しく説明すると、2048ビットのRSA鍵は非対称暗号と呼ばれるものです。 IDの検証（署名）と、意図した受信者のみが送信された情報にアクセスできるようにする（暗号化）ために使用されます。公開鍵と秘密鍵の2つの要素で構成されています。キーは実際には互いに関連していますが、2つの非常に大きな疑似素数（互いに関連する素数）によって関連付けられているため、公開鍵から秘密鍵を理解するのは非常に困難です。
とは言っても、アルゴリズムは単に理解するのが非常に難しい（しかし解決可能である）ものに基づいているため、数学的に解決できず複雑さに依存しない共有秘密に基づく対称アルゴリズムよりも安全性が低くなりますセキュリティのための数学の問題の詳細（後で詳しく説明します）。これが、鍵が対称の対応物（256ビットのみ）よりもはるかに大きい理由です。方程式を解くのを困難にするには、はるかに大きな鍵が必要です。また、非対称鍵で送信される情報が多いほど、それが破られる可能性が高くなります（また、暗号化/復号化はプロセッサに負荷がかかります）。
このため、SSLは、検証フェーズと鍵交換フェーズでRSAのみを使用します。代わりに、対称鍵（この場合はクライアントのブラウザーでサポートされている場合は256ビット）が生成され、RSA暗号化を介してサーバーに送信され、残りのデータは共有鍵と対称アルゴリズムを介して交換されます。
これは、サーバーが秘密鍵で暗号化するチャレンジへの応答をクライアントが最初にデコードすることで発生し、クライアントはサーバーの公開鍵（これはCAが既知のルート鍵（この場合はDigiCert ）はほとんどのブラウザに含まれています）。デコードされた応答がチャレンジと一致すると、クライアントはサーバーが要求に応答したことを認識します（ただし、仲介する仲介者がいる可能性があります）。次に、クライアントは256ビットの対称鍵を生成し、サーバーの公開鍵で暗号化してサーバーに送信します。キーはサーバーの公開キーで暗号化されているため、サーバー（秘密キーを知っている）だけがキーを復号化できます。つまり、前のステップの仲介者は、新しい共有キーを知ることができません。これで、クライアントは、共有キーを介して送信される情報が目的のサーバーからのみ送信されることを信頼できます。
既存の回答に詳細を追加するだけです...
私の質問は、クライアントがランダムな256ビットのキーを生成することをどのように知るのですか？ （なぜ128ではないのですか？）.
これは、ネゴシエートされる暗号スイートによって異なります。 TLS 1.1の一部として定義されているもののリストは、 RFC 4346付録A.5 にあります。たとえば、TLS_RSA_WITH_AES_128_CBC_SHAは128ビットのキーを使用しますが、TLS_DHE_RSA_WITH_AES_256_CBC_SHAは256ビットのキーを使用します。
ネゴシエートされる暗号スイートは、サーバーにインストールされている証明書ではなく、クライアントとサーバーの構成によって異なります。クライアントがClient Helloメッセージで接続を開始すると、サポートする暗号スイートのリストを送信します。次に、サーバーは必要なものを選択し、Server Helloメッセージでそのことを伝えます。
この暗号スイートは、これらの対称鍵が最終的に共有される方法を決定します。 SSL/TLSハンドシェイクの直接の目的は、クライアントとサーバー間で共有マスター前の秘密を確立することです。これは、より広く key-exchangeと呼ばれます（RFC 4346付録F.1.1を参照） 。
これは2つのカテゴリに分類されます（匿名キー交換を除く）。
- RSA鍵交換（例：
TLS_RSA_WITH_AES_128_CBC_SHA）：クライアントは、サーバーの公開鍵（証明書にある）を使用してプレマスターシークレットを暗号化します。 - DH（E）鍵交換（例：
TLS_DHE_RSA_WITH_AES_256_CBC_SHA）：Diffie-Hellman鍵交換が行われます。サーバーはDHパラメータに署名し、クライアントはサーバー証明書の公開鍵に対して署名を検証します。 （RSAベースの証明書があることは、RSA鍵交換を意味するものではありません。）
ハンドシェイクの最後に、これらの2つのステップのどちらが使用された場合でも、クライアントとサーバーは共通のプリマスターシークレットを所有しています。それらはマスターシークレットを導出します（ RFC 4346セクション8.1 を参照）。
master secretから、 RFC 4346セクション6.3で説明されているように、両方の当事者が暗号化キー（およびMACシークレット）を導出できます。 。
鍵タイプ（RSAまたはDSS）以外に、暗号鍵のサイズを証明書に依存させるものはありません。さらに、どちらのタイプにも、256ビットキーを使用する暗号スイートがあります。たとえば、TLS_DHE_DSS_WITH_AES_256_CBC_SHAやTLS_DHE_RSA_WITH_AES_256_CBC_SHAなどです。 （DSSは署名のみのアルゴリズムなので、プレマスターシークレットを暗号化するためにRSAのようなキー交換を取得することはできません。）
証明書内の鍵のサイズは、鍵交換の偽造を防止する（または記録されたトラフィックを解読できる）ためにのみ重要です。誰かが証明書内の公開鍵から秘密鍵を見つけることができた場合、それらは次のように機能できます。実サーバーを偽装するMITM、またはRSA鍵交換を使用するときに、暗号化されたプレマスターシークレット（および記録されたトラフィック）を解読できる（DHE暗号スイートは、プレマスターシークレットへのアクセスを防ぐように正確に設計されています） 、攻撃者が秘密鍵と記録されたトラフィックを入手した場合でも、 この質問 ）を参照してください。これが、十分に大きな非対称鍵が重要である理由です。
証明機関はマーケティングの観点から見た目が良いため、Webサイトに「256ビット」を付ける傾向があります。
それは間違いではありませんが、重要なのはサーバーのセットアップ方法やクライアントのサポート内容であることを理解していない人にとって誤解を招く可能性があります。