[CFRG] Re: Adoption Call: Sigma Protocols

["Brandao, Luis (IntlAssoc)" <[e-mail]>]

Thanks for promoting standardization of zero-knowledge proofs.

--------------------------------
C1. Interest

The specification of a widely-applicable structure for non-interactive zero-knowledge proofs of knowledge (NIZKPoK), such as that based on Sigma protocols and Fiat-Shamir (FS) transformation, is of interest as a building block for simplifying the specification and analysis of more complex protocols. For example, this is of interest in the context of the ZKPoK category of the NIST Threshold Call.

--------------------------------
C2. Title versus content/scope

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.

--------------------------------
C3. Zero-knowledge

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).

--------------------------------
C4. 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.)

--------------------------------
C5. Hash function (if specifying the Fiat-Shamir transformation in this spec)

- 1. Consider initially explaining the required properties of the (cryptographic) hash function used by FS transformation.

- 2. Should the concrete set of allowed hash functions be identified in this specification or in a separate one?

- 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)?

- 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?

--------------------------------
C6. Miscellaneous editorial

  1.
Typos: challange, commmit, Stadtler
  2.
Define acronyms: SHO, VRF, ...
  3.
Define terms, e.g., batchable, ...
  4.
Ref [NISTCurves]: if wanting to cite DSS, consider updating from FIPS 186-4 (2013) to FIPS 186-5 (2023); consider citing SP 800-186 (2023) as a reference for the P-* elliptic curves (such as P-384).
  5.
The expression "A commitment, sometimes also called nonce" is a bit confusing. Isn't nonce also being used to denote the (seed of) the discrete-log of the "commitment". It might be clearer to distinguish between secret nonce and public nonce.
  6.
Section 2.4: why is the nonce algorithm shown after the challenge algorithm (if the nonce is introduced before the challenge)?
  7.
Unclear the utility of declaring "simulate_response", without more guidance on how it would actually be used.
  8.
The draft uses "Equations" to specify the "constraints". Does that mean that range constraints (e.g., based on inequalities) are not allowed? Consider clarifying the relation between "constraints" and "equations".
  9.
Consider adding textual explanation of the syntax of each function, e.g., where the output length of SHAKE128 is specified.

Thanks to Rene Peralta for reviewing these comments.

Regards, Luís

--
Luís Brandão
NIST Associate (Foreign Guest Researcher, Contractor from Strativia)
________________________________
From: Stanislav V. Smyshlyaev <[e-mail]>
Sent: Friday, April 18, 2025 02:30
To: CFRG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [CFRG] Adoption Call: Sigma Protocols

Dear CFRG participants,

This message is starting a 4-week adoption call on "Sigma Protocols" draft, draft-orru-zkproof-sigma-protocols (https://datatracker.ietf.org/doc/draft-orru-zkproof-sigma-protocols/) that will end on April 16th 2025.

More information about the draft: https://mailarchive.ietf.org/arch/msg/cfrg/TkvxLDfjUZvFvh4DcbyLiraa4wM/

Please send your feedback in reply to this email or directly to CFRG chairs <[e-mail]><mailto:[e-mail]>.

Best regards,
Stanislav (for CFRG chairs)