The explicit key confirmation process remains optional. In 2005, Krawczyk proposed a hash variant of MQV, called HMQV. The HMQV protocol was designed to address Kaliski's attack (without mandating explicit key confirmation), with the additional goals of achieving provable security and better efficiency. HMQV made three changes to MQV:  HMQV claims to be superior to MQV in performance because it dispenses with the operations in 2) and 3) above, which are mandatory in MQV. The HMQV paper provides "formal security proofs" to support that dispensing with these operations is safe. In 2005, Menezes first presented a small subgroup confinement attack against HMQV. This attack exploits the exact missing of public key validations in 2) and 3). It shows that when engaged with an active attacker, the HMQV protocol leaks information about the user's long-term private key, and depending on the underlying cryptographic group setting, the entire private key may be recovered by the attacker. Menezes proposed to address this attack by at least mandating public key validations in 2) and 3). In 2006, in response to Menezes's attack, Krawczyk revised HMQV in the submission to IEEE P1363 (included in the IEEE P1363 D1-pre draft). However, instead of validating the long-term and ephemeral public keys in 2) and 3) respectively as two separate operations, Krawczyk proposed to validate them together in one combined operation during the key exchange process. This would save cost. With the combined public key validation in place, Menezes's attack would be prevented. The revised HMQV could still claim to be more efficient than MQV. In 2010, Hao presented two attacks on the revised HMQV (as specified in the IEEE P1363 D1-pre draft). The first attack exploits the fact that HMQV allows any data string other than 0 and 1 to be registered as a long-term public key. Hence, a small subgroup element is allowed to be registered as a "public key". With the knowledge of this "public key", a user is able to pass all verification steps in HMQV and is fully "authenticated" in the end. This contradicts the common understanding that "authentication" in an authenticated key exchange protocol is defined based on proving the knowledge of a private key. In this case, the user is "authenticated" but without having a private key (in fact, the private key does not exist).