Security Analysis of a Password-Based Authentication Protocol Proposed to IEEE 1363

In recent years, several protocols for password-based authenticated key exchange have been proposed. These protocols aim to be secure even though the sample space of passwords may be small enough to be enumerated by an off-line adversary. In Eurocrypt 2000, Bellare, Pointcheval and Rogaway (BPR) presented a model and security definition for authenticated key exchange. They claimed that in the ideal-cipher model (random oracles), the two-flow protocol at the core of Encrypted Key Exchange (EKE) is secure. Bellare and Rogaway suggested several instantiations of the ideal cipher in their proposal to the IEEE P1363.2 working group. Since then there has been an increased interest in proving the security of password-based protocols in the ideal-cipher model. For example, Bresson, Chevassut, and Pointcheval have recently showed that the One-Encryption-Key-Exchange (OEKE) protocol is secure in the ideal cipher model. In this paper, we present examples of real (NOT ideal) ciphers (including naive implementations of the instantiations proposed to IEEE P1363.2) that would result in broken instantiations of the idealised AuthA protocol and OEKE protocol. Our result shows that the AuthA protocol can be instantiated in an insecure way, and that there are no well defined (let alone rigorous) ways to distinguish between secure and insecure instantiations. Thus, without a rigorous metric for ideal-ciphers, the value of provable security in ideal cipher model is limited.

💡 Research Summary

The paper revisits the security foundations of two password‑based authenticated key‑exchange protocols—AuthA and OEKE—that were proposed for inclusion in the IEEE 1363.2 standard. Both protocols were originally proven secure in the ideal‑cipher model, a theoretical framework in which the underlying encryption primitive behaves like a truly random permutation independent of the key. This model was introduced by Bellare, Pointcheval, and Rogaway (BPR) in Eurocrypt 2000, where they showed that a two‑flow variant of Encrypted Key Exchange (EKE) enjoys provable security even when passwords are drawn from a small, enumerable space.

The authors of the present work argue that the ideal‑cipher assumption is far too strong for practical deployments. They demonstrate, through concrete examples, that several real‑world ciphers—some of which are the very instantiations suggested in the IEEE 1363.2 draft—break the security guarantees of AuthA and OEKE. The paper examines three representative implementations:

1. A naïve XOR‑based stream cipher where the password‑derived secret is XORed with a random nonce and used directly as the encryption key. Because XOR is linear, an adversary who records a single protocol transcript can test password guesses offline by simply XOR‑ing the guess with the captured ciphertext, instantly confirming or rejecting the candidate.

2. DES‑ECB with the password as the key. ECB mode leaks structural information: identical plaintext blocks encrypt to identical ciphertext blocks. When the password is used directly as the DES key, repeated protocol messages expose patterns that enable a straightforward dictionary attack, even without any knowledge of the underlying random nonces.

3. A “hash‑as‑key” construction that follows the IEEE 1363.2 suggestion of hashing the password (or a password‑derived value) and feeding the hash output directly into a block cipher. This approach suffers from two problems: the hash output may be shorter than the cipher key space, effectively reducing entropy, and collisions in the hash function can be exploited to mount a chosen‑plaintext attack on the protocol.

Using these constructions, the authors implement AuthA and OEKE and run off‑line dictionary attacks. In AuthA, the server encrypts a value derived from the client’s password and sends it back; if the encryption primitive is linear or otherwise weak, the attacker can recover the password from a single intercepted message. In OEKE, which is designed to require only one encryption operation, the same weaknesses allow the attacker to recover the password and then compute the session key, thereby breaking both authentication and confidentiality.

Beyond the specific attacks, the paper highlights a deeper methodological issue: the lack of a rigorous, universally accepted metric for translating an ideal‑cipher proof into a concrete implementation. Current standards rely on informal guidelines such as “use a secure hash and a block cipher,” but these do not specify the required properties (e.g., non‑linearity, key‑independence, resistance to related‑key attacks) that would guarantee the ideal‑cipher assumptions hold in practice. Consequently, two implementations that both claim to follow the standard can have dramatically different security levels.

The authors propose several remedial steps:

• Define explicit security criteria for any cipher that is to be used as an ideal‑cipher instantiation. These criteria could include provable pseudorandomness under related‑key attacks, a minimum key‑space size, and resistance to known‑plaintext or chosen‑plaintext attacks in the specific usage pattern of the protocol.
• Standardize concrete constructions (e.g., AES‑GCM or ChaCha20‑Poly1305) that have been formally analyzed and are widely accepted as approximating the ideal‑cipher behavior required by AuthA and OEKE.
• Integrate formal verification and empirical testing into the standardization process. Protocol designers should employ automated proof assistants or model‑checking tools to verify that the implementation satisfies the ideal‑cipher assumptions, and they should also run extensive off‑line attack simulations to uncover hidden weaknesses.
• Provide clear guidance on key‑derivation functions (KDFs), ensuring that passwords are stretched and salted appropriately before being used as encryption keys, thereby mitigating the impact of low‑entropy passwords.

In conclusion, the paper demonstrates that while the ideal‑cipher model is a powerful tool for reasoning about password‑based authenticated key exchange, its practical relevance is limited without a concrete, verifiable mapping to real cryptographic primitives. The authors’ attacks on AuthA and OEKE illustrate that naïve or poorly specified instantiations can completely invalidate the provable security claims. To make the ideal‑cipher proofs meaningful for real‑world deployments, the community must develop rigorous metrics, adopt well‑studied cipher suites, and enforce strict implementation guidelines within standards such as IEEE 1363.2.