unnecessity of indifferentiability

[weikengchen]

I am recently reading into the PLUME design and the use of Geometry's map. Note that Geometry's map was designed for a different purpose. If we target at making a nullifier, there is at least one trick that we can use.

Note that for provable indifferentiability, Geometry's map does hashing to curves twice and adds the results together. This is not necessary if we use the signature as the nullifier because you don't need to reveal the signature (see #11, I am referring to the GDH undeniable signature, the signature part), and to hide the signature, just hash the final result.

This ideally should be able to reduce the cost by half (given that clearing the cofactor is not necessary for secp256k1).

[weikengchen]

cc @weijiekoh and @kobigurk for more discussion.

[Divide-By-0]

@weikengchen thanks for the thoughtful analysis! I'm worried that only having a single map to curve might break security. This is because the final step of the hash to curve algorithm is then boiled down to a single exponentiation on the curve. This would cause the hash(m, pk) step to be of the form G^r, where you know r from the last step of the computation. This means the public can iterate through the pks and know for each one what r is. This would allow them to forge an ECDSA signature right? I'm not 100% sure on this and may well be missing/forgetting something -- what do you think?

[weikengchen]

Is the final step of the hash-to-curve algorithm a single exponentiation on the curve? From my understanding, the map on secp256k1 constructs a point on the curve in a way that does not know its discrete log.

[weijiekoh]

I'm very sure there's no point exponentiation involved in hash-to-curve!