[quantumgarbage]

Yes, what you are missing is that attacks on Fiat Shamir were very contrived up to now.

However the paper shows that there in fact exists a pretty simple way to break the Fiat Shamir heuristic, for a protocol operating in the RO model. And such kind of efficient attacks are rather concerning in cryptography land.

So this isn't about the attack per se, rather it's about the existence of such an easy one.

[GTP]

I understand that this is the claim being made, but I think I'm still missing what is the attack's heart. From the article, it seems to boil down to "if you use a malicious program, then Fiat-Shamir is broken". But to me it seems more like that Fiat-Shamir would still give a correct proof of the program's output, it's just that the output itself was wrong from the start (I'm referring to the point in the article where they say such a malicious program behaves differently than intended when it detects its own hash being used). Is this attack actually letting you generate a valid proof for an output that the program doesn't generate under the given input?

[less_less]

As I understand the paper, the point is that Fiat-Shamir does *not* give a correct proof of the program's output.

They gave a (maliciously constructed) program whose outputs are pairs (a,b) where certainly a != b (instead the program is constructed such that a = b+1 always). But you can get the corresponding Fiat-Shamir protocol to accept the statement "I know a secret x such that Program(x) = (0,0)", which is clearly a false statement.

[nyrikki]

I haven't done a real review yet, but skimming it seems to relate to Arthur-Merlin[0] oracles and public fair coins.

If you view random numbers as normal numbers, they will seem to be algorithmically random, or at least exceed the complexity of any proof, or even practical proof.

Basically the work of Chatlin, where given the kolmogorov complexity of your verifier, you only have a limited number of bits in any L that you can prove anything.

Probably simpler to think about the challenges of proving a fair coins is fair.

They just have to produce an unfair coin that looks fair as a flawed analogy.

Fiat-Shamir depends on interactive proofs, which equals PSPACE, which seems huge, but it can be a hay in the haystack, and if you are using a magnet to reach into the haystack you will almost never pull out a piece of hay.

They are basically choosing the magnet for you.

[0] https://complexityzoo.net/Complexity_Zoo:A#am

[quantumgarbage]

The protocol is in charge of producing the proof. Fiat Shamir is a heuristic, some kind of rule of thumb, which consists in using a hash function as a source of randomness.

Cryptographic protocols often feature coin tosses. The idea is that if we replace a hash function in place of the protocol coin tosses, it should still be hard for a malicious prover to craft a false statement with an accepting proof - making the protocol unsound.

Roughly, the meat of the attack consists in baking in the statement being proven the ability for the prover to predict upfront how the hash function is going to behave - hereby breaking the Fiat Shamir heuristic and making the prover able to craft a false statement with an accepting proof.

That’s it, this is “How to Prove False Statements“!

[ShroudedNight]

What does "easy" mean in this context? From my [ignorant] reading, it sounds like it requires being able compute a fixed point for the hash function in order to be able to integrate it into the program and respond differently under test. I thought that was one of the things cryptographically secure hash functions explicitly made difficult?

[quantumgarbage]

By "easy" I mean straightforward.

Previous examples which showed how instantiating Fiat Shamir leads to an unsound protocol were so contrived that people use to think that they were a testament to how unlikely breaking FS would be [1].

In "How to Prove False Statements", you can actually build what they show.

[1]: e.g. see https://eprint.iacr.org/1998/011.pdf

[yorwba]

The attack does not require a fixed point of the hash function to be integrated into the program, it merely involves an implementation of the hash function included in the program, being fed the exact same input as the hash function used as part of the protocol. This is possible because the input is entirely attacker-controlled, so it's easy to duplicate some values as necessary.