Consensys / gnark-crypto

gnark-crypto provides elliptic curve and pairing-based cryptography on BN, BLS12, BLS24 and BW6 curves. It also provides various algorithms (algebra, crypto) of particular interest to zero knowledge proof systems.
Apache License 2.0
495 stars 160 forks source link

feat: MIMC security considerations #485

Open Soleimani193 opened 7 months ago

Soleimani193 commented 7 months ago

Description of the Problem In the Original MIMC paper, the authors apply Sponge structure over MIMC permutation, while the gnark implementation uses Miyaguchi-Preneel structure.

Miyaguchi-Preneel is vulnerable to the length extension attack and should not be used for applications like MAC (where one hides a secret key inside the hash).

The positive side is a possible efficiency gain for the applications that are irrelevant to the length extension attack (e.g., snark) . Here is an estimation (footnote 19).

Screenshot 2024-02-08 at 09 03 50

Suggestions/Solutions

  1. The user should be warned about the use of MIMC hash based on Miyaguchi-Preneel structure.
  2. The implementation of MIMC based on Sponge structure would be very helpful
  3. A benchmark that can probably assert the efficiency gain of Miyaguchi-Preneel for snark applications.
giuliop commented 4 months ago

In their FAQ the MiMC authors comment against using a Miyaguchi-Preneel structure and add that if going that route they would recommend increasing the number of rounds. The number of rounds in gnark's implementation matches the original paper and does not follow the recommendation to increase it with a Miyaguchi-Preneel structure.

What is the line of thinking followed to make these choices in gnark?

ivokub commented 3 months ago

I am not sure, I haven't been involved in the implementation, but I would assume the main reasoning would have been to have compatibility with alternative libraries. Length-extension attacks are somewhat mitigated as MiMC is mostly used for in-circuit hashing (and we have the native version in gnark-crypto for compatibility), where the input lengths are fixed.

But I do agree that the issue and I think it needs some consideration. There are several parallel lines of work regarding algebraic hashing:

I would definitely add the points raised by @Soleimani193: