Security impact of weakened collision resistance for 128-bit Fiat-Shamir challenges

Question

As I understand, to achieve a security level of $\lambda$, a hash function's output should be at least $2\lambda$ in length, since the search space is halved for collision resistance.

However, I am also under the impression that for many $\Sigma$-protocols, $128$-bit challenges are used, which result in a knowledge error $\kappa=2^{-128}$ and provide $128$ bits of security against first and second pre-image resistance. However, in this case, the FS transform only provides $64$ bits of collision resistance.

What prompted me to ask this question is the sentence ‘We must also choose the number of parallel repetitions $τ$ so that $\tau \cdot bc \ge 128$, for non-interactive security.’ from 2022/1593. For simplicity, let $\tau = 1$. This claim is not explained nor proven in the paper which suggests that this is a well known result. Geoffroy Couteau also seems to hint at this in one answer. However, in section 2.3.5. of 2022/1153 which Couteau is the first author of, the random oracle range is set to $\{0,1\}^{2\lambda}$ which further confuses me on what the general stance is. Then, in the results (e.g. Table 3), the scheme seems to achieve $\lambda=128$ with the challenge size $\Gamma=129$ and no repetitions.

As I understand, for security in FS, we mostly care about second pre-image resistance, since the inputs to the FS transform are fixed. Therefore, it seems to me like $128$-bit challenges can be used in $\Sigma$-protocols made non-interactive with the FS transform while maintaining a security level of $128$ bits. However, have I misunderstood that? Among other papers, I have gone over Does Fiat-Shamir Require a Cryptographic Hash Function? (2020/915), but it does not seem to treat this particular problem.

It seems to me that either way the answer is out there, but I have not been able to find it. Could someone please provide a concrete resource/citation to back up or refute this problem on how collision resistance impacts the security level of a NIZKP? I would be most appreciative for that.

Answer 1

For Fiat-Shamir, we do not need collision resistance of the hash function, and $\lambda$ bits of output typically suffice. It is not too hard to see that collision-resistance is not a must-have: breaking collision-resistance would mean, in this context, that the adversary can find two first flows that map to the same challenge. But how would that help them cheat? Notions such as "second pre-image resistance" and "collision-resistance" are not really relevant here: they are standard properties for hash functions, but they don't capture the properties that a hash function should satisfy for the FS transform.

Characterizing the properties that are needed for FS is actually quite technical (some keywords include "universal computational extractors" or "correlation-intractable hash functions"). However, when modeling the hash function as a random oracle, we can directly bound the winning probability of a cheater, and this bound will typically be of the form $q/2^\lambda$, where $q$ is the number of queries to the random oracle, and $\lambda$ the bitsize of the outputs. We would need $2\lambda$ bits of outputs if the numerator was $q^2$ instead. If you want to understand why, I suggest looking at the FS transform applied to a simple protocol, such as Schnorr's $\Sigma$-protocol for discrete logarithms, and trying to see what an adversary can do (proving the bound can be a bit more involved as it requires some probability lemma, such as the forking lemma).

Eventually, about section 2.3.5 of 2022/1153: apologies if this sentence created confusion. In this work, we use hash functions both for the FS transform and to instantiate a standard trick that reduces communication in $\Sigma$-protocols by hashing the first flow with a collision-resistant hash function. The latter is unrelated to FS, and for FS we only need $\lambda$ bits of hash output.

One last thing: I am the "first author" of this paper only because authors are ordered alphabetically on cryptography papers (and generally in computer science) :)