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
_______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves