Remove Poseidon from PLUME [ERC 7524 incompatibility]

[Divide-By-0]

We noticed that you deviated from ERC 7524 in your implementation of the PLUME nullifier, namely by using the Poseidon hash instead of the recommended hashes. We do not recommend that due to slowdowns in hardware wallets. It is possible that there is something in your implementation that I missed -- open to hearing from your cryptographers!

Edit: Earlier I had mentioned there may be wallet exploits that may be caused by repeated exponentiations of Poseidon hashes, but that is not the case as there is a map_to_curve happening that immunizes against this.

[Trivo25]

Thanks for raising this issue! We talked this through in DMs, but just for the public records:

We use a map to curve algorithm which should allow us to prevent the issues mentioned in the blog post. By using this algorithm, we avoid the issue described below

Why do we not use a hash function like Poseidon? It turns out that Poseidon would actually lead to a critical vulnerability in ECDSA. Because we would know the pre-image of the final curve exponentiation, we would be able to generate a fake normal ECDSA signature for an arbitrary message. Basically, using the terminology of ECDSA Wikipedia, we would know a valid k corresponding to some r (r in this case would be hash(m, pk)), for which we would receive back a PLUME signature that we could use as the last term in the ECDSA signature, add any message hash(m) to, then multiply by k^−1, hence creating an arbitrary ECDSA signing oracle from just one PLUME signature – this would be quite bad. Thus, we must use a hash function for which the final step is not a curve exponentiation.

Please let us know if you have any other concerns with our implementation, we highly appreciate your input - this is super important to deliver a robust and secure SDK for writing zero knowledge applications!

[Divide-By-0]

@Trivo25 Continued discussion with Gregor leads me to conclude that yes, due to map_to_curve, your Poseidon hash to curve function is likely secure in the current implementation, because the final operation of your map to curve is not an exponentiation. However, it could be made faster both for calculation in hardware wallets and the client-side zk proof time.

Signature in Hardware Wallets

• We expect, via Markus's benchmarks, that Poseidon would make the ledger app have a 10-15 second slowdown compared to sha256, and you've noticed similar slowdowns in your ledger implementations: https://github.com/search?q=repo%3Ajspada%2Fledger-app-mina%20poseidon&type=code
• We expect a switch to SHA to make this much faster

ZK Proof

• Geometry's post: https://geometry.xyz/notebook/Hashing-to-the-secp256k1-Elliptic-Curve#the-hashtocurve-algorithm > map_to_curve says that the default Shallue-van de Woestijne method that (that you are using?) is slower than the Simplified SWU method for the secp256k1 curve specifically, which we optimized to make the zk circuit faster to compute client side. We would likely anticipate speedups from switching to Simplified SWU as well!