<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><span lang="EN-US">Hi Arasch,<br>
      </span></p>
    <p><span lang="EN-US">>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.</span></p>
    <div>
      <p class="MsoNormal"><span lang="EN-US">>Your note about an
          ephemeral generator is apparently also orthogonal, right?</span></p>
    </div>
    <div>
      <p class="MsoNormal"><span lang="EN-US">Yes. <br>
        </span></p>
      <p class="MsoNormal"><span lang="EN-US">Actually I fully agree to
          Mike's response. What I would recommend you to do is the
          following:</span></p>
      <p class="MsoNormal"><span lang="EN-US">1.) make *both* sides
          contribute a random number. R_alice and R_bob</span></p>
      <p class="MsoNormal"><span lang="EN-US">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.<br>
        </span></p>
      <p class="MsoNormal"><span lang="EN-US">derive a session-specific
          generator point by using</span></p>
      <p class="MsoNormal"><span lang="EN-US">3.) G = Elligator2 (HASH
          (R_alice || R_bob || paddingZeros || pdk))<br>
        </span></p>
      <p class="MsoNormal"><span lang="EN-US">. 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.<br>
        </span></p>
      <p class="MsoNormal"><span lang="EN-US">The construction sketched
          above is very similar to what I have recently been discussing
          with the guys from the BSI.</span></p>
    </div>
    <div>
      <p class="MsoNormal"><span lang="EN-US">>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?</span></p>
    </div>
    <div>
      <p class="MsoNormal"><span lang="EN-US">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.<br>
        </span></p>
    </div>
    HTH, Yours,<br>
    <br>
    Björn<br>
  </body>
</html>