web-dev-qa-db-ja.com

最初の基準としてセキュリティ、次にパフォーマンスの順に続くこれらの暗号の順序は何ですか？

セキュリティを優先する場合は、次の暗号をどの順序で配置する必要があるかを判断するためのガイドが必要です。同順位の場合は、パフォーマンスを考慮して決定します。

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384

そして、このリストはどうですか？

DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256

別のリスト、私はそれらを混ぜたくありません;）

tlsopensslcipher-selection
6
canciobello

セキュリティ：512ビットのRSAキーを使用するなどの愚かなことをしない場合、これらの暗号スイートはすべて同等に安全です。 「それを壊すことはできません」ゾーンで。つまり、mehです。 1つが他よりも安全であるとは言えません。

ただし、例外として、「ECDHE」スイートは、実際の暗号化に一時的な鍵ペアを使用します。対応する秘密鍵はファイルに格納されないため、これは Perfect Forward Secrecy と呼ばれる気の利いたプロパティを付与します。基本的にそれは、事実の後でサーバーの秘密鍵のコピーを盗む攻撃者に対して通信を免疫にします。 PFSは技術監査に適しています。

パフォーマンスの問題は、正式に測定された後にのみ存在します。クヌースが言ったように：時期尚早な最適化は、すべての悪の根源です。したがって、そのような質問をしないでください。 それを試して、測定する必要があります。いずれにせよ、答えはコンテキストに大きく依存します：関与するマシン、帯域幅、使用パターン...

短い答え：は問題ではありません。

長い答え：

「GCM」暗号スイートは [〜＃〜] gcm [〜＃〜] ;を使用します。非GCM暗号スイートは、CBCモードのAESと追加のHMAC（ここでは、SHA-384を使用）を使用します。パフォーマンスの問題は、関連するシステムによって異なります。

  • 小規模な32ビットシステム（組み込みARM ...）では、GCMのMAC部分は高額になりますが、SHA-384（64ビット計算のため...）も高額になります。ネクタイだと思います。
  • PCでは、AESコストが支配的です。
  • ... AES-NI を備えた最近のPCを除いて、AESは非常に高速で、GCMも同様です。

したがって、GCM暗号スイートは通常、よりお買い得です。ただし、実際に違いに気付くには、多くの帯域幅または非常に小さなCPUが必要です。 AES-NIがなくても、通常のサーバーには、CPUに余裕があれば、フルギガビット帯域幅でSSLを実行するのに十分な能力があります。

非対称暗号化の場合：

  • ECDHEスイートは、完全なハンドシェイクごとに（楕円曲線）Diffie-Hellmanおよび署名をサーバーに暗黙指定しますが、ECDH暗号スイートは楕円曲線Diffie-Hellmanのみを必要とします、その半分はすでに完了しています。
  • ...しかし、通常のPCでは、1秒あたりおよびコードごとに数千を処理するため、これが問題になることはほとんどありません。
  • ...特に通常のSSLクライアントはSSLセッションを再利用するため、非対称暗号化は、特定のクライアントからその日の最初の接続に対してのみ発生します。
  • ECDSA署名はRSA署名よりも高速です。
  • ...もちろんキーのサイズによって異なります。
  • ...しかしverificationの場合、これは逆の方法です。
  • ...そして、繰り返しになりますが、これが実際に問題になるには、1秒間に非常に多くの新しいクライアントが必要です。通常のPCは、毎秒数百の2048ビットRSAシグネチャ、毎秒数千の256ビットECDSAシグネチャを実行します。
  • ECDSAシグネチャはRSAシグネチャよりも短いため、これによりネットワークが少し節約されます（ただし、フルハンドシェイクごとに数十バイトしかありません）。
  • DHEおよびECDHE暗号スイートは、完全なハンドシェイクごとに数十の追加バイトを意味します。
  • DHEはECDHEに似ていますが、楕円曲線はありません。同じセキュリティレベル（256ビットのカーブポイントではなく2048ビットのモジュラス）を達成するには、より大きな数学を使用する必要があるため、RSAとECDSAのようになります。少し大きくても、少し遅くても、実際には問題になりません。 。

したがって、実際には、securityやperformanceに基づいても、有用な区別はできません。実際、AES-256（AES-128の代わりに）とSHA-384（SHA-256の代わりに）を主張することで、すでにファッションステートメントを作成しています。あなたはそれをそのままにして、それを論理的な結論に導くこともできます：できるだけ多くのGCMと楕円曲線を使用してください！これにより、印象的な監査人からブラウニーポイントが付与されます。

14
Thomas Pornin

アプリケーションに応じてスイートを選択する必要があります。電子メールなどの永続データの場合は、電子メールを復号化するためにサーバーにキーを保存する必要があるため、エフィメラルキーを使用できません。

また、ブラウザー証明書の互換性のために、RSSA over ECDSAを使用することをお勧めします。

（純粋な情報について：短命の鍵は認証されません。MITM攻撃を回避したい場合は、どこかで信頼性を取得する必要があります。たとえば、静的な公開鍵（証明書で信頼されているなど）を使用できる場合は、mitmを阻止します。

これらのスイートの1つを破るには、盗聴者はDH（ECDHの楕円曲線）の離散アルゴリズム問題とRSAの整数分解問題を解かなければなりません。そうすることが知られている最良のアルゴリズムは、両方の問題に対して一般化することができ、したがって、それらは同じ漸近的な複雑さを共有します。）

0
Stefano Beltrame