[CFRG] Re: Adoption Call: Sigma Protocols

[Michele Orrù <[e-mail]>]

Dear CFRG,

Following the community feedback we have updated our spec and split it into:

draft-orru-zkproof-sigma-protocols-01
draft-orru-zkproof-fiat-shamir-00

This call for adoption closed on May 16th 2025 and on July 24th 2025 we
discussed the changes made.
If you believe there is consensus, can you please move forward with both
sigma-protocols and fiat-shamir?

On Fri, May 30, 2025 at 10:00 AM Michele Orrù <[e-mail]> wrote:

> Dear Luís and Rene,
>
> Thank you so much for your thorough reading and for your comments, and
> sorry for the late reply here!
>
> I have created github issues (#43
> <https://github.com/mmaker/draft-zkproof-sigma-protocols/issues/43>, #44
> <https://github.com/mmaker/draft-zkproof-sigma-protocols/issues/44>, #45
> <https://github.com/mmaker/draft-zkproof-sigma-protocols/issues/45>, #46
> <https://github.com/mmaker/draft-zkproof-sigma-protocols/issues/46>, #47
> <https://github.com/mmaker/draft-zkproof-sigma-protocols/issues/47>) to
> address your comments, but let me respond inline as well.
>
>
> # Title
>
> The draft seems to be conflating "Sigma Protocols" (which can be [are?]
>> interactive) with a Sigma-inspired non-interactive (NI) ZKPoK obtained
>> using the Fiat-Shamir (FS) transformation. Note that the draft says:
>>
>>    - "*Sigma protocols, a [...] *non-interactive* zero-knowledge proof
>>    of knowledge*"
>>    - "*Any sigma protocols must define [...] A challenge, computed using
>>    the *Fiat-Shamir transformation* using a hash function.*"
>>
>>
>> *Concern:* This title might induce ambiguity in the future when referred
>> to in the scope of other specifications/discussions about (i)
>> *interactive* sigma protocols, or (ii) sigma-protocol-based NIZKP[oK]s
>> that use a transformation *different* from FS?
>>
>> Suggestion:
>>
>>    1. if the goal is indeed to focus on a Sigma+FS-based NIZKPoK, then
>>    consider revising the title to be more suggestive of the scope/focus.
>>    2. if the goal is to specify Sigma protocols as a 3-move interaction,
>>    then the title seems okay, but then the content could cover more thoroughly
>>    the interactive case. The transformation into a non-interactive
>>    proof/argument of knowledge could then either (i) be an explained option or
>>    (ii) be left to a separate specification.
>>
>>
>> [...]
>
> - 2. Should the concrete set of allowed hash functions be identified in
>> this specification or in a separate one?
>
>
> We are very much open to changing the title and welcome concrete naming
> suggestions.
> Eric Rescorla pointed out a potential confusion with  “SIGMA AKE protocol”
> in a previous email, and “Schnorr Non-interactive Zero-Knowledge Proof”
> already belongs to RFC 8235.
> You are pointing out a larger problem in the field of zero-knowledge
> proofs. For us, it is very common (so common that it's taken for granted)
> to consider in theory interactive protocols and, in practice, publicly
> expose only the Fiat-Shamir transformation for them (some examples:
>  “Schnorr proofs”, “Bulletproofs”, "Marlin”, “Plonk”, “FRI”, etc.). We will
> make this distinction more explicit. My personal approach, after the
> feedback from the BBS and Ethereum folks, would be to separate the
> Fiat-Shamir transformation from the Sigma protocol specification. That
> would help resolve this misunderstanding and be in agreement with your
> comment C5.2. How does everybody feel about this?
>
> # Security model
>
> For better awareness of privacy properties, consider clarifying the cases
>> in which the proofs become transferable (publicly verifiable, namely when
>> using a Fiat-Shamir transformation) or remain deniable (e.g., if
>> interactive, with a honest verifier, and without transferable message
>> authenticity).
>>
> [...]
>
> - 1. Consider initially explaining the required properties of the
>> *(cryptographic)* hash function used by FS transformation.
>>
>
>
> Thanks for this feedback! We added a "security considerations" section. As
> previously mentioned, we aim to specify for the Fiat-Shamir transformation
> and adaptively-secure zero-knowledge in the explicitly programmable ROM,
> but have kept the protocol modular so that all the different protocols you
> mention can be easily built by a separate specification.
> On a separate note, concurrent (interactive) zero-knowledge has been a
> headache for many decades in theory, and even after many years researching
> concurrent soundness, there's no free lunch. We are open to discussing how
> the interactive protocol can be secure in practice if you think it should
> be a priority.
>
> # Other non-interactive transformations
>
>
>> The Fiat-Shamir transformation (although being the most popular) is not
>> the only possibility for converting a Sigma protocol into a non-interactive
>> ZKP. For example, using an equivocable commitment (e.g., see
>> ia.cr/2014/710) instead of a hash function may facilitate obtaining
>> zero-knowledge of the non-transferable kind, i.e., proofs that are not
>> publicly verifiable). Thus, consider whether it may be beneficial to *adjust
>> the title to directly refer to the Fiat-Shamir transformation*.
>> (An alternative would be to leave the current spec be about sigma
>> protocols, and do another [related] spec about the FS transformation.)
>>
> [...]
>
> - 5. There are conceivable scenarios where one could use a purposefully
>> expensive hash function (akin to a key-derivation function with many
>> hashing iterations), as a way of slightly reducing the proof size while
>> retaining a given level of soundness. If those cases are deemed pertinent
>> in the future, would one allow those hash functions via an update to this
>> spec, or in a separate spec about hash functions compatible with FS?
>>
>
>
> We won't address other transformations or proofs of work because we don't
> believe they have an application within the IETF as of now.
> However the internal API does allow for them! In fact, Giacomo (EPFL) and
> Remco (Worldcoin) have already experimented with them in our Fiat-Shamir
> implementation repository:
> https://github.com/arkworks-rs/spongefish/tree/main/spongefish-pow.
>
>
> # Other hash functions
>
>
> - 3. If the intention is to allow a single hash function (i.e., XOF), then
>> (compared with SHAKE128):
>>
>>    - (a) Even though the draft already considers domain separation for
>>    the hash function,) might it make more sense to use cSHAKE128 (customizable
>>    XOF, see SP 800-185), e.g., with S = "Fiat-Shamir", to ensure that the hash
>>    function is different from the one used in different applications?
>>    - (b) might it make more sense to use SHAKE256 or cSHAKE256, to allow
>>    up to 256 bits of security [see FIPS 202 Table 4] for several security
>>    properties (still depending on the specified output length, and in case
>>    other curves are allowed, such as P-521).
>>
>>
>> - 4. Other hash functions?: Might there be applications that would
>> benefit from using "light(er)weight" hash functions / XOFs, such as
>> Ascon-based (See SP 800-232, with Ascon-Hash256 and Ascon-[C]XOF128)?
>>
>
> Thanks for giving us a bigger picture of the different hash function. Our
> current design could in theory support all hash functions above. We will
> discuss which ones can find their place within the IETF.
>
> Thanks to Rene Peralta for reviewing these comments.
>>
>
> Thank you!!!
>