根据法规和传统，国家安全局以隐藏的方式运作。因此，NSA 做某事或不做某事的确切原因无法严格了解。但是，可以进行一些猜测。

首先要注意的是套件 B旨在实现互操作性：它是特意列出的一小部分算法和功能，其官方目的是在任何地方都可以实现。例如，对于椭圆曲线，他们只列出了FIPS 186-3 中描述的 15 条曲线中的两条特定曲线。所以我们可以假设 NSA 只包含已经在各种系统和库中实现的算法，或者在不久的将来很有可能实现。在可预见的未来，没有人使用 MQV，也没有人真正打算使用 MQV……

现在为什么没有人在实践中使用 MQV 是另一个问题，答案归结为通常的三个：专利、无用和弱点。“无用”部分值得解释：MQV 是一种经过身份验证的密钥交换，因为它试图将密钥交换与双方的相互身份验证结合起来。这很简洁，但不能很好地映射到现有的通信框架，特别是SSL。在 SSL 中，客户端和服务器是不同的角色；客户端通过服务器的证书确保它知道正确的服务器公钥，但客户端的身份验证，当完全应用时，它与密钥交换分开（客户端使用其私钥计算签名，并且该签名的算法不需要与用于密钥交换的算法相关）。

关于该主题的另一种观点是，如果假定的 SSL 客户端具有带有 MQV 公钥的证书（假设将 MQV 与 SSL 一起使用已正式并实施），那么客户端只能使用该证书向使用 MQV 的 SSL 服务器进行身份验证并且碰巧有一个使用相同椭圆曲线的 MQV 密钥对。这是相当严格的，并且与客户端具有可在许多其他上下文中使用的通用签名证书的通常情况形成对比。

有趣的是，在经过一长串草案之后，2006 年发布的RFC 4492中定义了 SSL/TLS 中椭圆曲线加密的使用。1998 年的初稿包括基于 MQV 的密码套件。但 2001 年的第二稿没有。在初稿中，MQV 就像 Diffie-Hellman 一样被使用，因此没有任何实际的安全优势。在这种情况下，MQV 只是一种更复杂的 DH 方式，因此被完全删除。SSL/TLS 密钥交换的结构使MQV 相对于 DH 的所谓好处（即使假设好处是真实的，这是Krawczyk 否认的）无效。那何必呢？DH 速度稍快，专利方面的阴云较少。

总结：即使不考虑 2005 年（NSA 套件 B 发布几个月后）揭示的弱点，MQV 相对于 DH 的安全优势仅在实践中很少遇到的特定环境中才有用，特别是如果我们注意到套件 B 是关于互操作性的，即根据定义与专有封闭场景无关。相应地，没有人做 MQV（或者当他们这样做时，他们不以互操作性为目标）。在“套件 B”概念适用的上下文中，MQV 往往比更简单（更快）的 Diffie-Hellman 没有任何好处。仅此一项就证明 NSA 不将 MQV 包括在其“套件 B”中是合理的。