password authenticated key exchange full report
project report tiger Active In SP Posts: 1,062 Joined: Feb 2010 
06022010, 02:54 PM
Password authenticated Key Exchange.doc (Size: 91.5 KB / Downloads: 95) Password Authenticated Key Exchange ABSTRACT: PasswordAuthenticated Key Exchange (PAKE) studies how to establish secure communication between two remote parties solely based on their shared password, without requiring a Public Key Infrastructure (PKI). Despite extensive research in the past decade, this problem remains unsolved. Patent has been one of the biggest brakes in deploying PAKE solutions in practice. Besides, even for the patented schemes like EKE and SPEKE, their security is only heuristic; researchers have reported some subtle but worrying security issues. In this paper, we propose to tackle this problem using an approach different from all past solutions. Our protocol, Password Authenticated Key Exchange by Juggling (JPAKE), achieves mutual authentication in two steps: first, two parties send ephemeral public keys to each other; second, they encrypt the shared password by juggling the public keys in a verifiable way. The first use of such a juggling technique was seen in solving the Dining Cryptographers problem in 2006. Here, we apply it to solve the PAKE problem, and show that the protocol is zeroknowledge as it reveals nothing except onebit information: whether the supplied passwords at two sides are the same. With clear advantages in security, our scheme has comparable efficiency to the EKE and SPEKE protocols. Submitted By: Prashant Virutkar Manisha Rajguru Computer Engineering. ComputerEngineering 1 INTRODUCTION The username/password paradigm is the most commonly used authentication mechanism in security applications. Alternative authentication factors, including tokens and biometrics, require purchasing additional hardware, which is often considered too expensive for an application. However, passwords are lowentropy secrets, and subject to dictionary attacks. Hence, they must be protected during transmission. The widely deployed method is to send passwords through SSL/TLS. But, this requires a Public Key Infrastructure (PKI) in place; maintaining a PKI is expensive. In addition, using SSL/TLS is subject to maninthemiddle attacks. If a user authenticates himself to a phishing website by disclosing his password, the password will be stolen even though the session is fully encrypted. Since passwords are inherently weak, one logic solution seems to replace them with strong secrets, say, cryptographically secure private keys. This approach was adopted by the UK National Grid Service (NGS) to authenticate This work was done while the authors worked on an EPSRCfunded project and implimentation (EP/D051754/1). users. In the UK, anyone who applies to access the national grid computing resource must first generate a private/public key pair of his own, and then have the public key certified by NGS. The authentication procedure for the grid computing environments in the USA is similar. However, developments in the past ten years reveal that users â€œ most of them are noncomputer specialists â€œ encounter serious difficulties in managing their private keys and certificates. This has greatly hindered the wider acceptance of the grid computing technology. Hence, weak passwords are just a fact of life that we must face. Researchers have been actively exploring ways to perform passwordbased authentication without using PKIs or certificates â€œ a research subject called the Password Authenticated Key Exchange (PAKE). The first milestone came in 1992 when Bellovin and Merrit introduced the EKE protocol. Despite some reported weaknesses ,the EKE protocol first demonstrated that the PAKE problem was at least solvable. Since then, a number of protocols have been proposed. Many of them are simply variants of EKE, instantiating the symmetric cipher in various ways. The few techniques that claim to resist known attacks have almost all been patented â€œ most notably, EKE was patented by Lucent Technologies, and SPEKE by Phoenix Technologies. As a result, the scientific community and the wider security industry cannot readily benefit from the implementations of these techniques . The security with the EKE and SPEKE protocols is only heuristic. Given the way the two techniques were designed, formal security proofs seem unlikely without introducing new assumptions or relaxing requirements; we will explain the details in Section 4. In the following section, we will introduce a different approach to solve the PAKE problem, and show that our solution is free from the security issues reported with the EKE and SPEKE protocols. 2 PROTOCOL 2.1 MODEL We assume the key exchange is carried out over an unsecured network. In such a network, there is no secrecy in communication, so transmitting a message is essentially no different from broadcasting it to all. Worse, the broadcast is unauthenticated. An attacker can intercept a message, change it at will, and then relay the modified message to the intended recipient. It is perhaps surprising that we are still able to establish a private and authenticated channel in such a hostile environment solely based on a shared password â€œ in other words, bootstrapping a highentropy cryptographic key from a lowentropy secret. First of all, we formulate the security requirements that a PAKE protocol should fulfill. 1. Offline dictionary attack resistance â€œ It does not leak any password verification information to a passive attacker. 2. Forward secrecy â€œ It produces session keys that remain secure even when the password is later disclosed. 3. Knownkey security â€œ It prevents a disclosed session key from affecting the security of other sessions. 4. Online dictionary attack resistance â€œ It limits an active attacker to test only one password per protocol execution. In our threat model, we do not consider the Denial of Service (DoS) attack, which is rare but powerful. Since almost all PAKE protocols are built upon public key cryptography, they are naturally vulnerable to DoS attacks, in which an attackerâ„¢s sole purpose is to keep a server performing expensive public key operations. When this becomes a threat in some applications, there are wellestablished solutions â€œ for example, we can add a clientpuzzle protocol before engaging in any key exchange . There are generally two types of PAKE protocols: balanced and augmented ones. A balance scheme assumes two communicating parties hold symmetric secret information, which could be a password, or a hashed password. It is generic for any twoparty communication, including clientclient and clientserver. On the other hand, an augmented scheme is more customized to the clientserver case. It adds the server compromise resistance requirement â€œ an attacker should not be able to impersonate users to a server after he has stolen the password verification files stored on that server, but has not performed dictionary attacks to recover the passwords . This is usually realized by storing extra password verification data â€œ such as a (weak) public key derived from the password â€œ together with a hash of the password on the server. By design an augmented scheme is more complex and requires more computing power, but the added benefits are questionable. First, one may ask whether the threat of impersonating users to a compromised server is significantly realistic in practice. More importantly, none of the augmented schemes can provide any comforting assurance once the server is indeed compromised â€œ all passwords need to be revoked and updated anyway. Though it may be the case that some passwords are stronger than others and are more resistant to offline dictionary attacks , the strongness of a password is difficult to quantify, given that people often vary the same password slightly for different applications and use date of birth or petâ„¢s name as the password. If the presumption of a strong password turns out incorrect, the socalled server compromise resistance might just provide a false sense of security. To defend against the server compromise threat, a more proper solution is to apply a threshold scheme to distribute the password verification data among a set of servers, as suggested in. In this paper, we only consider the balanced case (there is a general method to convert any balanced scheme to an augmented one if needed). In the following section, we will propose a balanced PAKE protocol that satisfies the outlined requirements. 2.2 TWOSTEP EXCHANGE Let G denote a subgroup of Z*p with prime order q in which the Decision DiffieHellman problem (DDH) is intractable. Let g be a generator in G. The two communicating parties, Alice and Bob, both agree on (G, g). Let s be their shared password3, and s 6= 0 for any nonempty password. Since s has low entropy, we assume the value of s falls within [1, q  1]. Alice selects two secret values x1 and x2 at random: x1 R Zq and x2 R Z* q . Similarly, Bob selects x3 R Zq and x4 R Z*q. Note that since q is prime, Zq only differs Z*q in that the later excludes Ëœ0â„¢. Hence, x2, x4 6= 0; the reason will be evident in security analysis.3 Depending on the application, s could also be a hash of the shared password, so that it preserves some privacy against an honestbutcurious server administrator. Step 1: Alice sends out gx1 , gx2 and knowledge proofs for x1 and x2. Similarly, Bob sends out gx3 , gx4 and knowledge proofs for x3 and x4. The above communication can be completed in one step as neither party depends on the other. When this step finishes, Alice and Bob verify the received knowledge proofs, and also check gx2 , gx4 6= 1. Step 2: Alice sends out A = g(x1+x3+x4)Â¢x2Â¢s and a knowledge proof for x2 Â¢ s. Similarly, Bob sends out B = g(x1+x2+x3)Â¢x4Â¢s and a knowledge proof for x4*s. When this step finishes, Alice computes K = (B/gx2Â¢x4Â¢s)x2 = g(x1+x3)Â¢x2Â¢x4Â¢s, and Bob computes K = (A/gx2Â¢x4Â¢s)x4 = g(x1+x3)Â¢x2Â¢x4Â¢s. With the same keying material K, a session key can be derived a = H(K), where H is a hash function. Before using the session key, Alice and Bob may perform an additional key confirmation process as follows: Alice sends H(H(a)) to Bob, and Bob then replies H(a). This process is the same as in. It gives explicit assurance that the two ends derived the same session key4. In the protocol, senders need to produce valid knowledge proofs. The necessity of the knowledge proofs is motivated by Andersonâ„¢s sixth principle in designing secure protocols: Do not assume that a message you receive has a particular form unless you can check this. Fortunately, ZeroKnowledge Proof (ZKP) is a wellestablished primitive in cryptography; it can allow one to prove his knowledge of a discrete logarithm without revealing it . As one example, we could use Schnorrâ„¢s signature , which is noninteractive, and reveals nothing except the one bit information: whether the signer knows the discrete logarithm. Let H be a secure hash function5. To prove the knowledge of the exponent for gx, one sends {gv, r = v  xih} where v R Zq and h = H(g, gv, gx, SignerID). This signature can be verified by the receiver through checking whether gv and grgxh are equal. Adding the SignerID into the hash function is to prevent replaying the signature. Since Alice and Bobâ„¢s SignerIDs are unique, Alice cannot replay Bobâ„¢s signature back to Bob and vice versa. In the second step of the protocol, Alice sends A = gx2Â¢s a to Bob, where ga = gx1+x3+x4 . Here, ga serves as a generator. As the group G has prime order, any nonidentity element is a generator . So Alice could simply check ga 6= 1 to ensure it is a generator. In fact, as we will explain in Section 3, (x1 + x3 + x4) is random over Zq even in the face of active attacks. Hence, the probability for ga = 1 is extremely small â€œ on the order of 2160 for 160bit q. Symmetrically, the same argument applies to the Bobâ„¢s case. 2.3 IMPLEMENTATION Since our protocol involves several zeroknowledge proofs, one might concern about its cost. We now count the number of exponentiations in the protocol and evaluate its computational efficiency. Note that for Schnorrâ„¢s ITEM DESCRIPTION NO OF EXP TIME(MS) 1 Compute {gx1 , gx2} and KPs for {x1, x2} 4 23 2 Verify KPs for {x3, x4} 4 24 3 Compute A and KP for {x2 Â¢ s} 2 9 4 Verify KP for {x4 Â¢ s} 2 10 5 Compute k 2 9 Total 14 75 Table 1. Computational cost for Alice in JPAKE signature, it requires one exponentiation in generation and two in verification. Hence, in our protocol, each partywould need to perform 14 exponentiations in total â€œ including 8 in the first step, 4 in the second step, and 2 in computing the session key. To better assess the cost in real terms, we implement the protocol in Java on a 2.33GHz laptop running Mac OS X. The modulus p is chosen 1024bit and the subgroup order q 160bit. The cost for Alice is summarized inTable 1; for Bob, it is the same. The results demonstrate that the protocol â€œ executed only once in a session â€œ runs sufficiently fast. The total computation time is merely 0.075 sec. As compared to the time that the user keys in his password, this latency is negligible at the client. However, the cost at the server may accumulate to be significant if requests are dealt with simultaneously. Therefore, the threat of Denial of Service (DoS) attacks still needs to be properly addressed in practical deployments (e.g., by using ). 3 SECURITY ANALYSIS In this section, we analyze the protocolâ„¢s resistance against both passive and active attacks. First, we consider a passive attacker who eavesdrops on the communication between Alice and Bob. Aliceâ„¢s ciphertext A contains the term (x1 + x3 + x4) on the exponent. The following two lemmas show the security properties of (x1 + x3 + x4) and A. Lemma 1 Under the Discrete Logarithm (DL) assumption, Bob cannot compute (x1 + x3 + x4). Proof. To obtain a contradiction, we reveal x2 to Bob. The knowledge proofs in the protocol show that Bob knows x3 and x4. Hence, Bob knows {gx1 , x2, x3, x4} (based on which he can compute A, B). Assume Bob is able to compute (x1+x3+x4). Then, he is able to compute x1. This, however, contradicts the DL assumption , which states that one cannot compute x1 from g, gx1 . Therefore, even with x2 revealed, Bob is still unable to compute (x1 + x3 + x4). Lemma 2 Under the Decision DiffieHellman (DDH) assumption, Bob cannot distinguish Aliceâ„¢s ciphertext A = g(x1+x3+x4)Â¢x2Â¢s from a random element in the group. Proof. From Lemma 1, (x1 +x3 + x4) is a random value over Zq, unknown to Bob. Also, x2 Â¢ s is a random value over Zq, unknown to Bob. Based on the Decision DiffieHellman assumption , Bob cannot distinguish A from a random element in the group. Based on the protocol symmetry, the above two Lemmas can be easily adapted from Aliceâ„¢s perspective â€œ Alice cannot compute (x1 + x2 + x3), nor distinguish B from a random element in the group. The following theorem proves that our protocol fulfills the offline dictionary attack resistance requirement (see Section 2.1). Theorem 3 (Offline dictionary attack resistance) Under the DDH assumption, the ciphertexts A = g(x1+x3+x4)Â¢x2Â¢s and B = g(x1+x2+x3)Â¢x4Â¢s do not leak any information for password verification. Proof. Lemma 2 implies that Bob cannot computationally correlate A to the ciphertext he can compute: B. From Lemma 2, even Bob cannot distinguish A from a random value in G. Surely, a passive attacker cannot distinguish A from a random value in G, nor can he computationally correlate A to B. Based on the protocol symmetry, the passive attacker cannot distinguish B from a random value in G either. Therefore, to a passive attacker, A and B are two random and independent values; they do not leak any useful information for password verification. While the above theorem shows that the password is secure against a passive attacker, we now show the session key is secure too. In the following theorem, we consider a stronger attacker, who knows the discloseds. Theorem 4 (Forward secrecy) Under the Square Computational DiffieHellman (SCDH) assumption6, the past session keys derived from the protocol remain secure even when the secret s is later disclosed. Proof. After knowing s, the passive attacker wants to compute a = H(K) given inputs: {gx1 , gx2 , gx3, gx4 , g(x1+x3+x4)Â¢x2 , g(x1+x2+x3)Â¢x4}. Assume the attacker is able to compute K = g(x1+x3)Â¢x2Â¢x4 from those inputs. For simplicity, let x5 = x1 + x3 mod q. The attacker behaves like an oracle â€œ given the ordered inputs {gx2 , gx4, gx5, g(x5+x4)Â¢x2 , g(x5+x2)Â¢x4}, it returns gx5Â¢x2Â¢x4 . This oracle can be used to solve the SCDH problem as follows. For gx where x R Zq, we query the oracle by supplying {gx+a, gx+b, gx, gbÂ¢(x+a), gaÂ¢(x+b)}, where a, b are arbitrary values chosen from Zq, and obtain f(gx) = g(x+a)Â¢(x+b)Â¢x = gx3 (a+b)Â¢x2+abÂ¢x. In this way, we can also obtain f(gx+1) = g(x+1)3 (a+b)Â¢(x+1)2+abÂ¢(x+1) = gx3+(3ab)Â¢x2+(32a2b+ab)Â¢x+1ab+ab. Now we are able to compute gx2 = f(gx+1) Â¢ f(gx)1 Â¢ g(3+2a+2b)Â¢x1+a+bab1/3 . This, however, contradicts the SCDH assumption , which states that one cannot compute gx2 from g, gx. We now consider the case when a session key is compromised (see the knownkey security requirement in Section 2.1). Compared with other ephemeral secrets xi (i = 1 . . . 4) â€œ which can be immediately erased after the key bootstrap phase â€œ a session key lasts longer throughout the session, which might increase the likelihood of its exposure. An exposed session key should not cause any global effect on the system . In our protocol, a known session key does not affect the security of either the password or other session keys. From an explicit key confirmation process, an attacker learns H(H(a)) = H(H(H(K))) and H(a) = H(H(K)). It is obvious that learning a = H(K) does not give the attacker any additional knowledge about K, and therefore, the security of the password encrypted at that session remains intact. Also, the session key a = H(g(x1+x3)Â¢x2Â¢x4Â¢s) is MODULES SECURITY PROPERTY ATTACKER TYPE ASSUMPTIONS Schnorr signature Leak 1bit: whether sender knows discrete logarithm Passive/active DL and random oracle Password encryption Indistinguishable from random Passive/active DDH Session key incomputable passive CDH incomputable Passive(know s) CDH incomputable Passive(know other session keys) CDH incomputable Active(if sâ„¢ s) CDH Key confirmation Leak nothing passive  leak 1bit: whether s' = s active CDH In the protocol, Bob demonstrates that he knows x4 and the exponent of gb, where gb = gx1+x2+x3 . Therefore, the format of the ciphertext sent by Bob can be described as B' = gb x4Â¢s' , where s' is a value that Bob (the attacker) can choose freely. Theorem 5 (Online dictionary attack resistance) Under the SCDH assumption, an active attacker cannot compute the session key if he chose a value s' 6= s. Proof. After receiving B', Alice computes K' = (B'/gx2Â¢x4Â¢s)x2 = gx1Â¢x2Â¢x4Â¢s'Â¢gx2Â¢x3Â¢x4Â¢s'Â¢gx22 Â¢x4Â¢(s' s) To obtain a contradiction, we reveal x1 and s, and assume that the attacker is now able to compute K'. The attacker behaves as an oracle: given inputs {gx2 , x1, x3, x4, s, s'}, it returns K'. Note that the oracle does not need to know x2, and it is still able to compute A = g(x1+x3+x4)Â¢x2Â¢s and B' = g(x1+x2+x3)Â¢x4Â¢s' internally. Thus, the oracle can be used to solve the Square Computational DiffieHellman problem by computing gx2 2= (K'/(gx1Â¢x2Â¢x4Â¢s' Â¢ gx2Â¢x3Â¢x4Â¢s' ))x4 1(s' s)1 . Here7, x4 6= 0 and s'  s 6= 0. This, however, contradicts the SCDH assumption. So, even with x1 and s revealed, the attacker is still unable to compute K' (and hence cannot perform key confirmation later). The above theorem shows that our protocol is zeroknowledge. Because of the knowledge proofs, the attacker is left with the only freedom to choose an arbitrary s'. If s' 6= s, he is unable to derive the same session key as Alice. During the later key confirmation process, the attacker will learn onebit information: whether s' and s are equal. This is the best that any PAKE protocol can possibly achieve, because by nature we cannot stop an imposter from trying a random guess of password. However, consecutively failed guesses can be easily detected, and thwarted accordingly. The security properties of our protocol are summarized in Table 2. 4 COMPARISON In this section, we compare our protocol with the two wellknown balanced schemes: EKE and SPEKE. These two techniques have several variants, which follow very similar constructs . However, it is beyond the scope of this paper to evaluate them all. Also, we will not compare with augmented schemes (e.g., AEKE, BSPEKE, SRP, AMP and OPAKE ), as they have different design goals. 7 This explains why in the protocol definition we need x4 6= 0, and symmetrically, x2 6= 0 Table 2. Summary of JPAKE security properties The design principles underlying EKE and SPEKE are similar; both protocols can be seen as a slight modification of the basic DiffieHellman (DH) key exchange protocol. However, in the protocol design, even the slightest modification could cause profound effects. The EKE and SPEKE designs are no exception, as we explain below. Bellovin and Merrit introduced two EKE constructs: using RSA (which was later shown insecure ) and DH. Here, we only describe the later, which modifies a basic DH protocol by symmetrically encrypting the exchanged items. Let a be a primitive root modulo p. In the protocol, Alice sends to Bob [axa ]s, where xa R Z* p and [. . .]s denotes a symmetric cipher using the password s as the key. Similarly, Bob sends to Alice [axb ]s, where xb R Z* p. Finally, Alice and Bob compute a common key K = axaÂ¢xb . More details can be found in . Apparently, a straightforward implementation of the above protocol is insecure . Since the password is too weak to be used as a normal encryption key, the content within the symmetric cipher must be strictly random. But, for a 1024bit number modulo p, not every bit is random. Hence, a passive attacker can rule out candidate passwords by applying them to decipher [axa ]s, and then checking whether the results fall within [p, 21024  1]. There are suggested countermeasures. In , Bellovin and Merrit recommended to transmit [axa +r Â¢ p]s instead of [axa ]s in the actual implementation, where r Â¢p is added using a nonmodular operation. The details on defining r can be found in . However, this solution was explained in an adhoc way, and it involves changing the protocol of its existing form. Due to lack of a complete description of the final protocol, it is difficult to assess its security. Alternatively, Jaspan suggested to address this issue by choosing p as close to a power of 2 as possible . This might alleviate the issue, but does not resolve it. One implication of the above issues is that proving the security of an EKE is difficult. To address this, Bellare, Pointcheval and Rogaway introduced an idealcipher model, and proved that an EKE is secure under that model . However, the ideal cipher was not concretely defined in ; it was later clarified by Boyd et al. in : the assumed cipher works like a random function in encryption, but must map fixedsize strings to elements of G in decryption (also see ). Yet, no such ciphers are readily available in practice; indeed, several proposed instantiations of such an ideal cipher were easily broken . Another limitation with the EKE protocol is that it does not securely accommodate short exponents. The protocol definition requires axa and axb be uniformly distributed over the whole group Z* p . Therefore, the secret keys xa and xb must be randomly chosen from [1, p  1], and consequently, an EKE must use 1024bit exponents if the modulus p is chosen 1024bit. Unlike our protocol, an EKE cannot operate in groups with distinct features, such as a subgroup with prime order â€œ a passive attacker would then be able to trivially uncover the password by checking the order of the decrypted item. Since the cost of exponentiation is linear with the bitlength of the exponent , one exponentiation in an EKE is equivalent in cost to 67 exponentiations in a JPAKE (for the 1024bit p and 160bit q setting). Hence, though an EKE only requires two exponential operations per user, the computational cost is approximately the same as that of our protocol. Jablon proposed a different protocol, called Simple Password Exponential Key Exchange (SPEKE), by replacing a fixed generator in the basic DH protocol with a passwordderived variable . In the description of a fully constrained SPEKE, the protocol defines a safe prime p = 2q + 1, where q is also a prime. Alice sends to Bob (s2)xa where s is the shared password and xa R Z* q ; similarly, Bob sends to Alice (s2)xb where xb R Z* q . Finally, Alice and Bob compute K = s2Â¢xaÂ¢xb . The squaring operation on s is to make the protocol work within a subgroup of prime order q. Recently, Zhang pointed out the risk of using a passwordderived variable as the base . Since some passwords are exponentially equivalent, an active attacker may exploit that equivalence to test multiple passwords in one go. This problem is particularly serious if a password is a Personal Identification Numbers (PIN). One countermeasure might be to hash the password before squaring, but that does not resolve the problem. Hashed passwords are still confined to a predefined small range. There is no guarantee that an attacker is unable to formulate exponential relationships among hashed passwords; existing hash functions were not designed for that purpose. Hence, at least in theory, this reported weakness disapproves the original claim in that a SPEKE only permits one guess of password in one attempt. Similar to the case with an EKE, a fully constrained SPEKE uses long exponents. For a 1024bit modulus p, the key space is within [1, q  1], where q is 1023bit. In , Jablon suggested to use 160bit short exponents in a SPEKE, by choosing xa and xb within a dramatically smaller range [1, 2160  1]. But, this would give a passive attacker side information that the 1023  160 = 863 most significant bits in a fulllength key are all Ëœ0â„¢s. The security is not reassuring, as the author later acknowledged in. Therefore, for the same reason explained earlier, the computational cost in a SPEKE is roughly the same as ours, despite that a SPEKE only requires two exponentiations per user. To sum up, an EKE requires changing the protocol in its existing form for a secure implementation. As for a SPEKE, it has the drawback that an active attacker may test multiple passwords in one protocol execution. Furthermore, neither protocol â€œ in the original form â€œ accommodates short exponents securely. Finally, neither protocol is provably secure; formal security proofs seem unlikely without introducing new security assumptions or relaxing security requirements . We choose to solve the PAKE problem using a different approach. The novelty of our design is that we encrypt the password by juggling the public keys in a way that can be verified. As a result, our scheme is provably secure, allows flexible use of short exponents, and strictly limits an active attacker to test only one password per protocol execution. A similar use of this juggling technique was seen in solving the Dining Cryptographers problem8 in 2006. One difference is that works in a multiparty setting, while ours in a twoparty one. Yet both schemes 5 CONCLUSION In this paper, we proposed a protocol, called JPAKE, which authenticates a password with zeroknowledge and then subsequently creates a strong session key if the password is correct. We proved that the protocol fulfills the following properties: it prevents offline dictionary attacks; provides forward secrecy; insulates a known session key from affecting any other sessions; and strictly limits an active attacker to guess only one password per protocol execution. A Java implementation of the protocol demonstrates that the total computation time for the session key setup is merely 75 ms. As compared to the de facto internet standard SSL/TLS, JPAKE is more lightweight in password authentication with two notable advantages: It requires no PKI deployments; It protects users from leaking passwords (say to a fake bank website). 6 REFERENCES 1. B. Jaspan, Dualworkfactor Encrypted Key Exchange: efficiently preventing password chaining and dictionary attacks, Proceedings of the Sixth Annual USENIX Security Conference, pp. 4350, July 1996. 2. K. Kobara, H. Imai, Prettysimple passwordauthenticated keyexchange under standard assumptions, IE ICE Transactions, Vol. E85A, No. 10, pp. 2229â€œ2237, 2002. 3. Paul C. Van Oorschot, M.J. Wiener, On DiffieHellman key agreement with short exponents, Advances in Cryptology, EUROCRYPTâ„¢96, LNCS 1070, pp. 332â€œ343, 1996. 4. S. Patel, Number theoretic attacks on secure password schemes, Proceedings of the IEEE Symposium on Security and Privacy, May 1997. 5. R. Perlman, C. Kaufman, Secure passwordbased protocol for downloading a private key, Proceedings of the Network and Distributed System Security, February 1999. 6. Muxiang Zhang, Analysis of the SPEKE passwordauthenticated key exchange protocol, IEEE Communi cations Letters, Vol. 8, No. 1, pp. 6365, January 2004. 7. Z. Zhao, Z. Dong, Y. Wang, Security analysis of a passwordbased authentication protocol proposed to IEEE 1363, Theoretical Computer Science, Vol. 352, No. 1, pp. 280â€œ287, 2006. 


seminar ideas Super Moderator Posts: 10,003 Joined: Apr 2012 
04072012, 09:52 AM
to get information about the topic"Secure and Efficient password based Authenticated key exchange protocol for two serv" full report ppt and related topic refer the link bellow topicideashowtoclassicalauthenticatedkeyexchangeandquantumcryptography topicideashowtopasswordauthenticatedkeyexchangefullreport 


