<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Arasch, >In fact, the hash could incorporate a random session ID (as I understood there is an attack against SPEKE where you create multiple >concurrent sessions), but those are separate concerns – and therefore I was referring to a random base point. <div> >Your note about an ephemeral generator is apparently also orthogonal, right? </div> <div> Yes. Actually I fully agree to Mike's response. What I would recommend you to do is the following: 1.) make *both* sides contribute a random number. R_alice and R_bob 2.) use a salted hash for hashing the password with the salt s and the password pw, such that the password-derived key is pdk = PBKDF(s, pw) with the PBDKF function of your choice and the computational effort that you could realistically spend. derive a session-specific generator point by using 3.) G = Elligator2 (HASH (R_alice || R_bob || paddingZeros || pdk)) . I'd recommend you to add some padding zeros behind the random values in case that you are using SHA2 or SHA512 as hash such that one block is filled only with the hash. E.g. in case of SHA512 fill up the data up to 128 bytes. This is useful as defense against chosen-plaintext power-analysis attacks against the hash. Padding costs nothing with regarding to code size and also nothing in comparison to the PBKDF and the X25519 protocol calculations. The construction sketched above is very similar to what I have recently been discussing with the guys from the BSI. </div> <div> >So to better understand your point, if for example the hash of the password has n bits of effective security, say 128, then we would >leak one bit of the hash (not the password itself), correct? Put differently, how could this information practically be exploited? Is it a >realistic attack today or e.g. a potential weakness that could be attacked using a quantum computer and a nuclear power plant in >e.g. 20 years from now? </div> <div> As Mike has pointed out, the attack is completely realistic if you are either incorporating a session-specific random value or a salt. You will be leaking one bit per sniffed login. After listening to 5-20 logins the attacker will be able to mount an offline attack. </div> HTH, Yours, Björn </body> </html>