ECMVQがNSA Suite Bから削除されたのはなぜですか？
法令により、従来とは異なり、NSAは隠れた方法で動作します。そのため、NSAが何かをした、またはしなかった正確な理由を厳密に知ることはできません。ただし、推測は可能です。
最初に注意することは、 スイートB は相互運用性を意味するということです。これは、公式に実装されることを目的としたアルゴリズムと機能の意図的な小さなリストですeverywhere 。たとえば、楕円曲線の場合、 FIPS 186-3 で説明されている15の中の特定の曲線twoのみがリストされます。したがって、NSAには、さまざまなシステムやライブラリにすでに実装されているアルゴリズムのみが含まれているか、近い将来実装される可能性が高いと考えられます。誰もMQVを使用していませんし、予見可能な将来にMQVを使用するつもりもありません...
さて、why誰も実際にMQVを使用していないのは別の問題であり、答えは通常の3つに要約されます：特許、無用、および弱点です。 "役に立たない"部分は説明に値します。MQVは、キー交換を両方の関係者の相互認証と組み合わせようとする認証済みのキー交換です。これはすばらしいですが、既存の通信フレームワーク、特に [〜＃〜] ssl [〜＃〜] にはうまく対応しません。 SSLでは、クライアントとサーバーは別個の役割です。クライアントは、サーバーの証明書を通じて正しいサーバー公開鍵を知っているという保証を得ますが、認証クライアントのを適用すると、鍵交換から分離されます（クライアントは、秘密鍵、およびその署名のアルゴリズムは、鍵交換に使用されるものと関連している必要はありません。
この主題に関する別の見方は、推定SSLクライアントがMQV公開鍵を持つ証明書を持っている場合（SSLでのMQVの使用が形式化および実装されていると想定）、クライアントはその証明書を使用して、MQVを使用するSSLサーバーでのみ認証できるということです。 およびたまたま、同じ楕円曲線を使用するMQV鍵ペアがあります。これはかなり制限的であり、クライアントが他の多くのコンテキストで使用できる一般的な署名証明書を持っている通常の状況とは対照的です。
興味深いことに、SSL/TLSでの楕円曲線暗号の使用は、長いドラフトシーケンスの後、2006年に公開された RFC 4492 で定義されています。 1998年の最初のドラフト には、MQVベースの暗号スイートが含まれています。しかし、2001年の second draft はそうではありません。最初のドラフトでは、MQVはDiffie-Hellmanと同じように使用されたため、実際のセキュリティ上の利点はありませんでした。その意味で、MQVはDHを実行するためのより複雑な方法であり、そのため完全に削除されました。 DHを介したMQVの利点とされている利点（実際の利点が Krawczykが拒否する であると仮定しても）は、SSL/TLSキー交換の構造によって無効にされます。なぜわざわざ？ DHは少し高速で、特許に関しては曇りが少なくなっています。
要約：2005年に明らかにされた弱点を考慮しなくても（数か月after NSAの公開） _スイートB）、DHを超えるMQVのセキュリティ上の利点は、特にスイートBが相互運用性に関するものであることに気付いた場合、つまり、定義によりnot独自仕様であることに気付いた場合、実際にはほとんど発生しない特定のコンテキストでのみ有効です。閉じたシナリオ。これに対応して、誰もMQVを実行しません（または、実行しても相互運用性を目指していません）。 「スイートB」の概念が適用される状況では、MQVはより単純な（そしてより高速な）Diffie-Hellmanよりも利点がない傾向があります。これだけでも、「スイートB」にMQVを含めないNSAを正当化します。