<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi,</div>
<div> </div>
<div name="quoted-content">
<div>first of all, I agree that using a PAKE scheme for password-based authentication on zigbee networks is a good idea. Also, SPEKE-based protocols are IMHO the fastest choice available. Since SPEKE patents have expired, there is no need to avoid that the password itself enters the calculation of the generator, which was (IIUC) the main reason for the patent circumvention approach for that PACE has been developped.</div>
<div> </div>
<div>Regarding the base point selection, I'd strongly recommend to use Elligator2 and not just the hash of the password. The reason is, that depending on your construction, you will at least leak one bit of the password. If you just use the hash, you will either be having a point on the curve or on it's twist and this information could be exploited.<br/>
<br/>
IMO there are a couple of things to consider when suggesting standardization: I'd recommend to combine the construction with use of a sound password hash, such as scrypt or argon2, mainly because it's likely that you will never enter the password on the small node. At least one should use PBKDF2 with a strong parameter set.<br/>
<br/>
The second thing is consideration of side-channel stuff. I'd advocate on using an ephemeral generator. This costs essentially one additional communication round, but this might be worth the effort, since you anyway might be having a communication telegram exchange before the actual PAKE scheme.<br/>
<br/>
When combining some ephemeral (and publicly known) random with the password hash for generating an ephemeral generator with Elligator2, you will be ending up with something very similar to our PACE paper at chess (<a href="https://eprint.iacr.org/2017/562.pdf" target="_blank">https://eprint.iacr.org/2017/562.pdf</a>).<br/>
<br/>
Note that the fact that you are using an ephemeral generator comes virtually at no added cost. I'd suggest to use a permutation or a hash for combining random values from both sides, and the password hash and feed the result into elligator2 to get an ephemeral generator. The patent circumvention step in our PACE paper (that forced us to use a symmetric cipher, in our case Salsa20, on top) is now no longer necessary.<br/>
<br/>
Yours,<br/>
<br/>
Björn</div>
<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Dienstag, 24. Oktober 2017 um 14:03 Uhr<br/>
<b>Von:</b> "Arasch Honarbacht" <honarbacht@ubisys.de><br/>
<b>An:</b> curves@moderncrypto.org<br/>
<b>Betreff:</b> [curves] SPEKE using Curve25519 - elligator2 required or recommended?</div>
<div>
<div>
<div class="WordSection1">
<p class="MsoNormal">Hi all,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span>I’m working on a proposal for key agreement in zigbee networks. The idea is to use SPEKE and Curve25519. My understanding is that Curve25519 accepts all 32-byte strings as valid public keys. Now, instead of the default base point 9, the base point is generated using a hash of the password. For argument’s sake, assume the base point would be a random number. I’ve implemented a test bench and tested this approach and it works well (for the small set of experiments I made, i.e. a couple of thousand executions).</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>The approach as it stands:</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Alice generates a secret a, Bob generates a secret b.</span></p>
<p class="MsoNormal"><span>Alice computes P = aG and sends it to Bob. Bob computes Q = bG and sends it to Alice.</span></p>
<p class="MsoNormal"><span>Alice computes k = aQ = abG. Bob computes k = bP = baG.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>When the base point G is chosen as one of the 12 points listed under the “contributory” behavior on Bernstein’s site (<a href="https://cr.yp.to/ecdh.html" target="_blank">https://cr.yp.to/ecdh.html</a>) the scalar products P and Q and the shared secret become zero – so these points need to be avoided.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Now, I saw in literature that reverse elligator2 mapping is used to map a random string to a Montgomery x coordinate u, e.g. instead of G simply being the hash, G = elligator2(hash), c.f. Figure 1 in this paper: <a href="https://eprint.iacr.org/2017/562.pdf" target="_blank">https://eprint.iacr.org/2017/562.pdf</a>, or section 2.6 here: <a href="https://signal.org/docs/specifications/xeddsa/" target="_blank">https://signal.org/docs/specifications/xeddsa/</a>.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>My question is: Would a elligator2 mapping be required for the SPEKE use case outlined above, or is any point, except for the 12 points mentioned above suitable as a generator?</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Thanks, Arasch</span></p>
</div>
_______________________________________________ Curves mailing list Curves@moderncrypto.org <a href="https://moderncrypto.org/mailman/listinfo/curves" target="_blank">https://moderncrypto.org/mailman/listinfo/curves</a></div>
</div>
</div>
</div>
</div></div></body></html>