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

[Arasch Honarbacht]

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:
https://signal.org/docs/specifications/xeddsa/.

 

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>