Misplaced Pages

Password Authenticated Key Exchange by Juggling

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

The Password Authenticated Key Exchange by Juggling (or J-PAKE) is a password-authenticated key agreement protocol, proposed by Feng Hao and Peter Ryan. This protocol allows two parties to establish private and authenticated communication solely based on their shared (low-entropy) password without requiring a Public Key Infrastructure. It provides mutual authentication to the key exchange, a feature that is lacking in the Diffie–Hellman key exchange protocol.

Description

Two parties, Alice and Bob, agree on a group G {\displaystyle G} with generator g {\displaystyle g} of prime order q {\displaystyle q} in which the discrete log problem is hard. Typically a Schnorr group is used. In general, J-PAKE can use any prime order group that is suitable for public key cryptography, including Elliptic curve cryptography. Let s {\displaystyle s} be their shared (low-entropy) secret, which can be a password or a hash of a password ( s ≠ 0 {\displaystyle s\neq 0} ). The protocol executes in two rounds.

Round 1
Alice selects x 1 ∈ R [ 0 , q − 1 ] {\displaystyle x_{1}\in _{R}} , x 2 ∈ R [ 1 , q − 1 ] {\displaystyle x_{2}\in _{R}} and sends out g x 1 {\displaystyle g^{x_{1}}} , g x 2 {\displaystyle g^{x_{2}}} together with the Zero-knowledge proofs (using for example Schnorr non-interactive zero-knowledge proof as specified in RFC 8235) for the proof of the exponents x 1 {\displaystyle x_{1}} and x 2 {\displaystyle x_{2}} . Similarly, Bob selects x 3 ∈ R [ 0 , q − 1 ] {\displaystyle x_{3}\in _{R}} , x 4 ∈ R [ 1 , q − 1 ] {\displaystyle x_{4}\in _{R}} and sends out g x 3 {\displaystyle g^{x_{3}}} , g x 4 {\displaystyle g^{x_{4}}} together with the Zero-knowledge proofs for the proof of the exponents x 3 {\displaystyle x_{3}} and x 4 {\displaystyle x_{4}} . The above communication can be completed in one round as neither party depends on the other. When it finishes, Alice and Bob verify the received Zero-knowledge proofs and also check g x 2 , g x 4 ≠ 1 {\displaystyle g^{x_{2}},g^{x_{4}}\neq 1} .
Round 2
Alice sends out A = g ( x 1 + x 3 + x 4 ) x 2 s {\displaystyle A=g^{(x_{1}+x_{3}+x_{4})x_{2}s}} and a Zero-knowledge proof for the proof of the exponent x 2 s {\displaystyle x_{2}s} . (Note Alice actually derives a new public key using g x 1 + x 3 + x 4 {\displaystyle g^{x_{1}+x_{3}+x_{4}}} as the generator). Similarly, Bob sends out B = g ( x 1 + x 2 + x 3 ) x 4 s {\displaystyle B=g^{(x_{1}+x_{2}+x_{3})x_{4}s}} and a Zero-knowledge proof for the proof of the exponent x 4 s {\displaystyle x_{4}s} .

After Round 2, Alice computes K = ( B / g x 2 x 4 s ) x 2 = g ( x 1 + x 3 ) x 2 x 4 s {\displaystyle K=(B/g^{x_{2}x_{4}s})^{x_{2}}=g^{(x_{1}+x_{3})x_{2}x_{4}s}} . Similarly, Bob computes K = ( A / g x 2 x 4 s ) x 4 = g ( x 1 + x 3 ) x 2 x 4 s {\displaystyle K=(A/g^{x_{2}x_{4}s})^{x_{4}}=g^{(x_{1}+x_{3})x_{2}x_{4}s}} . With the same keying material K {\displaystyle K} , Alice and Bob can derive a session key using a Cryptographic hash function: κ = H ( K ) {\displaystyle \kappa =H(K)} .

The two-round J-PAKE protocol is completely symmetric. This helps significantly simplify the security analysis. For example, the proof that one party does not leak any password information in the data exchange must hold true for the other party based on the symmetry. This reduces the number of the needed security proofs by half.

In practice, it is more likely to implement J-PAKE in three flows since one party shall normally take the initiative. This can be done trivially without loss of security. Suppose Alice initiates the communication by sending to Bob: g x 1 , g x 2 {\displaystyle g^{x_{1}},g^{x_{2}}} and Zero-knowledge proofs. Then Bob replies with: g x 3 , g x 4 , B = g ( x 1 + x 2 + x 3 ) x 4 s {\displaystyle g^{x_{3}},g^{x_{4}},B=g^{(x_{1}+x_{2}+x_{3})x_{4}s}} and Zero-knowledge proofs. Finally, Alice sends to Bob: A = g ( x 1 + x 3 + x 4 ) x 2 s {\displaystyle A=g^{(x_{1}+x_{3}+x_{4})x_{2}s}} and a Zero-knowledge proof. Both parties can now derive the same session key.

Depending on the application requirement, Alice and Bob may perform an optional key confirmation step. There are several ways to do it. A simple method described in SPEKE works as follows: Alice sends to Bob H ( H ( κ ) ) {\displaystyle H(H(\kappa ))} , and then Bob replies with H ( κ ) {\displaystyle H(\kappa )} . Alternatively, Alice and Bob can realize explicit key confirmation by using the newly constructed session key to encrypt a known value (or a random challenge). EKE, Kerberos and Needham-Schroeder all attempt to provide explicit key confirmation by exactly this method.

Security properties

Given that the underlying Schnorr non-interactive zero-knowledge proof is secure, the J-PAKE protocol is proved to satisfy the following properties:

  1. Off-line dictionary attack resistance - It does not leak any password verification information to a passive/active attacker.
  2. Forward secrecy - It produces session keys that remain secure even when the password is later disclosed.
  3. Known-key security - It prevents a disclosed session key from affecting the security of other sessions.
  4. On-line dictionary attack resistance - It limits an active attacker to test only one password per protocol execution.

In 2015, Abdalla, Benhamouda and MacKenzie conducted an independent formal analysis of J-PAKE to prove its security in a random oracle model assuming algebraic adversaries.

The protocol design

The J-PAKE protocol is designed by combining random public keys in such a structured way to achieve a vanishing effect if both parties supplied exactly the same passwords. This is somehow similar to the Anonymous veto network protocol design. The essence of the idea, however, can be traced back to David Chaum's original Dining Cryptographers network protocol, where binary bits are combined in a structured way to achieve a vanishing effect.

The implementation

J-PAKE has been implemented in OpenSSL and OpenSSH as an experimental authentication protocol. It was removed from the OpenSSH source code at the end of January 2014. It has also been implemented in Smoke Crypto Chat Messenger, in NSS and was used by Firefox Sync version 1.1 but discontinued in 1.5 which uses a different key exchange and storage method. Mozilla's J-PAKE server was shut down along with the Sync 1.1 storage servers on 30 September 2015. Pale Moon continues to use J-PAKE as part of its Sync service. Since February 2013, J-PAKE has been added to the lightweight API in Bouncycastle (1.48 and onwards). J-PAKE is also used in the Thread (network protocol)

Standardization

J-PAKE was included in ISO/IEC 11770-4 (2017) as an international standard. It is also published in RFC 8236.

References

  1. F. Hao, P. Ryan. Password Authenticated Key Exchange by Juggling. Proceedings of the 16th International Workshop on Security Protocols, 2008.
  2. Jablon, David (October 1996). "Strong Password-Only Authenticated Key Exchange". ACM SIGCOMM Computer Communication Review. 26 (5): 5–26. CiteSeerX 10.1.1.57.4798. doi:10.1145/242896.242897. S2CID 2870433.
  3. F. Hao, P. Ryan. J-PAKE: Authenticated Key Exchange Without PKI. Springer Transactions on Computational Science XI, Special Issue on Security in Computing, Part II, Vol. 6480, pp. 192-206, 2010.
  4. M. Abdalla, F. Benhamouda, P. MacKenzie Security of the J-PAKE Password-Authenticated Key Exchange Protocol.
  5. Chaum, David (1988). "The dining cryptographers problem: Unconditional sender and recipient untraceability". Journal of Cryptology. 1: 65–75. doi:10.1007/BF00206326. S2CID 2664614.
  6. "CVS log for src/usr.bin/ssh/Attic/jpake.c". cvsweb.openbsd.org. Retrieved 17 November 2023.
  7. Moonlander, Casio (2020). Smoke - An Android Echo Chat Software Application:: Personal Chat Messenger / Open Source Technical Website Reference Documentation. Norderstedt: BOD. p. 44. ISBN 9783752691993.
  8. "Firefox Sync's New Security Model". 30 April 2014.
  9. "Shutting down the legacy Sync service". 31 July 2015.
  10. "Pale Moon updated to 25.7.3! - Pale Moon forum".
  11. "Archived copy" (PDF). Archived from the original (PDF) on 2015-09-11. Retrieved 2015-09-15.{{cite web}}: CS1 maint: archived copy as title (link)
  12. "ISO/IEC 11770-4:2017(en)". iso.org. Retrieved 17 November 2023.

External links

Category: