Comparison
J-PAKE scheme looks too computationally expensive, but actually it's not.
Item | Description | No of Exp |
---|---|---|
1 | Compute gx1, gx2 and ZKPs for { x1, x2 } | 4 |
2 | Verify ZKPs for { x3, x4 } | 4 |
3 | Compute A and ZKP for { x2 • s } | 2 |
4 | Verify ZKP for { x4 • s } | 2 |
5 | Compute K | 2 |
Total | 14 |
Recall that EKE and SPEKE use only 2 exponentiations compared with 14 exponentiations in J-PAKE, we might think J-PAKE is computationally expensive. However, both EKE and SPEKE must use long exponents. One typical exponentiation in EKE or SPEKE is equivalent in cost 6-7 exponentiation in J-PAKE. Hence, overall computational costs for EKE, SPEKE, and J-PAKE are actually about the same.
Why can J-PAKE use short exponents?
You must be curious about why J-PAKE can use short exponents. The basic pattern of the PAKE family are exactly same. They all choose a secret number as a private key and generate a public key with the group generator .
From the aspect of probability, the reason of why J-PAKE can achieve same security as EKE and SPEKE is that it decomposes the probability of cracking one private key into several probabilities of cracking several private keys.
Suppose the EKE or SPEKE use a 4-bits group modulo , then its used private key must also be 4-bits. Therefore, there are possible choices for the private key. To crack one PAKE session channel, the attacker needs to hit not only Alice's private key, but also Bob's one. Thus, the probability of hitting the private keys of both sides is . However, J-PAKE can reach the same probability by using only 2-bits group modulo . J-PAKE uses 2 exponents per session on each side. Consequently, it will produce 2 private keys on each side in one protocol execution. That is, Alice and Bob will have choices for one 2-bits private key. To establish one J-PAKE session, both Alice and Bob will have possible combinations for two random private keys. Thus, there are possible combinations for Alice and Bob's private keys. Then the probability to compromise a J-PAKE session is . And that's why J-PAKE can achieve the same security as EKE and SPEKE.
Formally, assume that are the probabilities to crack one private key of respectively EKE/SPEKE and J-PAKE. Then to find a such that can guarantee that J-PAKE has same security level as EKE and SPEKE. That is, if we use bits private key for EKE or SPEKE, To achieve same security level, we must use bits private key for J-PAKE such that
Thus, J-PAKE can only use half bits of EKE or SPEKE to keep the channel secret.