[curves] SPEKE using Curve25519 - elligator2 required or recommended?
honarbacht at ubisys.de
Tue Oct 24 05:03:10 PDT 2017
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Curves