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.
Your note about an ephemeral generator is apparently also orthogonal, right?
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.
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?
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.
HTH, Yours,
Björn
_______________________________________________
Curves mailing list
Curves@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/curves
