[curves] SPEKE using Curve25519 - elligator2 required or recommended?

Arasch Honarbacht honarbacht at ubisys.de
Tue Oct 24 05:03:10 PDT 2017

Hi all,


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).


The approach as it stands:


Alice generates a secret a, Bob generates a secret b.

Alice computes P = aG and sends it to Bob. Bob computes Q = bG and sends it
to Alice.

Alice computes k = aQ = abG. Bob computes k = bP = baG.


When the base point G is chosen as one of the 12 points listed under the
"contributory" behavior on Bernstein's site (https://cr.yp.to/ecdh.html) the
scalar products P and Q and the shared secret become zero - so these points
need to be avoided.


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:
https://eprint.iacr.org/2017/562.pdf, or section 2.6 here:


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?


Thanks, Arasch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20171024/094794e8/attachment.html>

More information about the Curves mailing list