[curves] Fwd: Re: Fw: Aw: SPEKE using Curve25519 - elligator2 required or recommended?

[Björn Haase]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20171025/ca2ecf59/attachment.html>