Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9AF0F4B7015C for ; Fri, 25 Jul 2025 19:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=orru-net.20230601.gappssmtp.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVvubZ8mcM8W for ; Fri, 25 Jul 2025 19:46:38 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D2CBD4B7014A for ; Fri, 25 Jul 2025 19:46:38 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-700fee04941so25859766d6.1 for ; Fri, 25 Jul 2025 19:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orru-net.20230601.gappssmtp.com; s=20230601; t=1753497998; x=1754102798; darn=irtf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5T4nbQO0pr08YhK/claQFJWLUZ3aldUjXVnjhYhpYAo=; b=Lbu7VezHh+a/qIaJs9AqiGJXTafeyDyMwdHMw/BmcRLegp3DdZvyZhciYKhNAPy6CH iX6XTYcveajvtzL6vrWnPPncqmZrbFiA6EjOVvDihct78TtIpKwx/FG3aMhl5l22YamC nnM43WHM+P0kx4YuF04M8OBuCypHc6vQcJHoq+LiSeIUepboQONPjytw1L4I+aJEQK0y Y2UhSrSW4F+fIz+wefXKLstiiqj7plng6wnZXgJj8uoMaTCMrBvvmkxGs6F8Fq6bF+zL aAFvSGWHchv09KeJCpsfLxB49pYKos+SeXcaNnVokKXYhM/IpCbuk4onn+toNbWbyZGh lapA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753497998; x=1754102798; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5T4nbQO0pr08YhK/claQFJWLUZ3aldUjXVnjhYhpYAo=; b=bb7hsi91m0BbFDA+SW1+D55+Z30+lt1iqP6+Ay60moWB0jIeSrVYKIHFpB3yyGY/4j nc4BQm7xCH6zRdKuOJEOTRIcL/UwOJ22dVu2N44EWY+65VnUnIPLae3U4Vy82yNAsFMI p4Hz1rPhgxE8kvuMAdqJEbEkLFx23FSnPudBbXj8rCtI0rW3/ZeO36R7LnCRmso7qMn8 umB/KfO1fbYIM8O4o4A/+6Aq2ZJAee35jZ0YY8pQH7pNKTlk10wsdWbGWtvUt7hW+AUn vMF0CjxoTKJaQoTWFpLZkzeWdgK1Y3o2JONpMDZuuwt9SH2Dts9yimzfWMTpPL3igKic NcmA== X-Forwarded-Encrypted: i=1; AJvYcCWxl9zS0LtLV/eG0cVFl7ycdNon1UsJfD0sza329Mm0TwSnWhms33XD1fockKsAO4zyITMI@irtf.org X-Gm-Message-State: AOJu0Yx/Wy1E74ayJpleTWiTO5qjHXfYemqz1Y9wqcnsTyFWyphm/nw4 RsLD25i40ni6DhKh2AH9GkxqzxOvW82oDo89huFwQTlqnlL1dxoECAV5wGaFE52M1vnTlSQi8eM EOWnWSmorVbXSFrzG1xOCohqwUPYVw2b+0gS70tuH9xmKSr3EzX9HGHHHvhyq X-Gm-Gg: ASbGncunB7A1ZGLSosZm5tMKgH996I6CiRF/kUhmpABQxod4B5b8K6xSwuB9R47amQs GOr7zJnn9hKQi+HbYsR1eTzrWR26uoFTKAqDySA898aqNcaaI03HhhfiSPypM6HmO5PRyWC22kk 8KN+obPWtwNTrUWr8viohPgRJ9FmcM/TzLiOG3/ZZEzBh44rvd0/Ujwjik5rqLyqbnDgVRbAu+L 2Pus38T/ynEewbd X-Google-Smtp-Source: AGHT+IEtAZvAc/d/cG1CPi/MS9VawM/gpwH1w5BlBLW4sW/lvwbbOD4yo9yrduKm36qzA3aIuojfXU/xuBE4ODoTgXQ= X-Received: by 2002:a05:6214:2626:b0:704:f8fa:fb18 with SMTP id 6a1803df08f44-707205b2d00mr63770826d6.27.1753497997917; Fri, 25 Jul 2025 19:46:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Michele_Orr=C3=B9?= Date: Fri, 25 Jul 2025 19:46:21 -0700 X-Gm-Features: Ac12FXzK2pvq_mUrHnYgeLjA9fx8gOK4mF6TtKf3XEp6y3DydTtuekgyiHQjCfo Message-ID: To: "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047d3df063acc1170" Message-ID-Hash: CMVYWT6PDZRTY3P7IJXX4ZECVJQQU5GY X-Message-ID-Hash: CMVYWT6PDZRTY3P7IJXX4ZECVJQQU5GY X-MailFrom: m@orru.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: CFRG , "draft-orru-zkproof-sigma-protocols@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Adoption_Call=3A_Sigma_Protocols?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000047d3df063acc1170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Michele Orr=C3=B9 wro= te: > Dear Lu=C3=ADs 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 > , #44 > , #45 > , #46 > , #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 thor= oughly >> the interactive case. The transformation into a non-interactive >> proof/argument of knowledge could then either (i) be an explained opt= ion 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 =E2=80=9CSIGMA AKE = protocol=E2=80=9D > in a previous email, and =E2=80=9CSchnorr Non-interactive Zero-Knowledge = Proof=E2=80=9D > 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: > =E2=80=9CSchnorr proofs=E2=80=9D, =E2=80=9CBulletproofs=E2=80=9D, "Marli= n=E2=80=9D, =E2=80=9CPlonk=E2=80=9D, =E2=80=9CFRI=E2=80=9D, 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 whe= n >> 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. A= s > previously mentioned, we aim to specify for the Fiat-Shamir transformatio= n > and adaptively-secure zero-knowledge in the explicitly programmable ROM, > but have kept the protocol modular so that all the different protocols yo= u > 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 researchin= g > concurrent soundness, there's no free lunch. We are open to discussing ho= w > 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-interact= ive >> 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 *ad= just >> 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 pertinen= t >> in the future, would one allow those hash functions via an update to thi= s >> 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), the= n >> (compared with SHAKE128): >> >> - (a) Even though the draft already considers domain separation for >> the hash function,) might it make more sense to use cSHAKE128 (custom= izable >> XOF, see SP 800-185), e.g., with S =3D "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 securit= y >> properties (still depending on the specified output length, and in ca= se >> 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!!! > --00000000000047d3df063acc1170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CFRG,=C2=A0

Following the communit= y feedback we have updated our spec and split it into:

=
draft-orru-zkproof-sigma-protocols-01
draft-orru-zkproof-fiat-shami= r-00

This call for adoption closed on May 16t= h 2025 and on=C2=A0July=C2=A024th 2025 we discussed the changes made.=C2=A0=
If you believe there is consensus, can you please move for= ward with both sigma-protocols and fiat-shamir?

On Fri, May 30, 2025= at 10:00=E2=80=AFAM Michele Orr=C3=B9 <m@orru.net> wrote:
Dear Lu=C3=ADs and Rene,

Thank you so much for your thorough readi= ng and for your comments, and sorry for the late reply here!

I have = created github issues (#43, #= 44, #45, #46, #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 obtain= ed using the Fiat-Shamir (FS) transformation. Note that the draft says:
  • "Sigma=C2=A0protocols, a [...] *non-interactive* zero-knowledg= e proof of knowledge"
  • "Any sigma protocols must define [...] A challenge, computed u= sing the *Fiat-Shamir transformation* using a hash function."

Concern:=C2=A0This title might induce ambiguity in the future when r= eferred to in the scope of other specifications/discussions about (i) interactive=C2=A0sigma protocols, or (ii) sigma-protocol-based NIZKP= [oK]s that use a transformation different=C2=A0from FS?

Suggestion:=C2=A0
  1. if=C2=A0the 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, the= n the title seems okay, but then the content could cover more thoroughly th= e interactive case. The transformation into a non-interactive proof/argumen= t 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 funct= ions be identified in this specification or in a separate one?
=

We are very much open to changing the title and w= elcome concrete naming suggestions.
Eric Rescorla pointed out a potentia= l confusion with =C2=A0=E2=80=9CSIGMA AKE protocol=E2=80=9D in a previous e= mail, and=C2=A0=E2=80=9CSchnorr Non-interactive Zero-Knowledge Proof=E2=80= =9D already belongs to RFC 8235.
You are pointing out a larger problem i= n 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 protocol= s and, in practice, publicly expose only the Fiat-Shamir transformation for= them (some examples: =C2=A0=E2=80=9CSchnorr proofs=E2=80=9D, =E2=80=9CBull= etproofs=E2=80=9D, "Marlin=E2=80=9D, =E2=80=9CPlonk=E2=80=9D, =E2=80= =9CFRI=E2=80=9D, etc.).=C2=A0We will make this distinction more explicit. M= y personal approach, after the feedback from the BBS and Ethereum folks, wo= uld be to separate the Fiat-Shamir transformation from the Sigma protocol s= pecification. That would help resolve this misunderstanding and be in agree= ment with your comment C5.2. How does everybody feel about this?

# Security model

For better awareness of privacy properties, consider clarifying the cases i= n which the proofs become transferable (publicly verifiable, namely when us= ing a Fiat-Shamir transformation) or remain deniable (e.g., if interactive,= with a honest verifier, and without transferable message authenticity).
[...]=C2=A0
- 1. Conside= r initially explaining the required properties of the=C2=A0(cryptographi= c)=C2=A0hash function used by FS transformation.

=C2=A0
Thanks f= or this feedback! We added a "security considerations" section. A= s previously mentioned, we aim to specify for the Fiat-Shamir transformatio= n 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 separ= ate note, concurrent (interactive) zero-knowledge has been a headache for m= any decades in theory, and even after many years researching concurrent sou= ndness, there's no free lunch. We are open to discussing how the intera= ctive protocol can be secure in practice if you think it should be a priori= ty.

# Other non-interactive transformations
<= /div>
=C2=A0
The Fiat-Shamir transformation (although being the most popular) is not the= only possibility for converting a Sigma protocol into a non-interactive ZK= P. For example, using an equivocable commitment (e.g., see ia.cr/2014/710) instead of a hash f= unction may facilitate obtaining zero-knowledge of the non-transferable kind, i.e., proofs that a= re not publicly verifiable). Thus, consider whether it may be beneficial to adjust the title to directly refer to the Fiat-Shamir transformation= . (An=C2=A0alternative would be to leave the current spec be about sigma pr= otocols, and do another [related] spec about the FS transformation.)
<= /div>
[...]=C2=A0
- 5. There are conceivable scenarios where one could u= se a purposefully expensive hash function (akin to a key-derivation functio= n with many hashing iterations), as a way of slightly reducing the proof si= ze while retaining a given level of soundness. If those cases are deemed pe= rtinent in the future, would one allow those hash functions via an update t= o this spec, or in a separate spec about hash functions compatible with FS?=
=C2=A0
=C2=A0
We wo= n'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 Fi= at-Shamir implementation repository: https://github.c= om/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 =3D "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 proper= ties (still depending on the specified output length, and in case other cur= ves 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)?
=C2=A0
Thanks for giving us a bigg= er picture of the different=C2=A0hash function. Our current design could in= theory support all hash functions above. We will discuss which ones can fi= nd their place within the IETF.

Thanks to R= ene Peralta for reviewing these comments.

Thank you!!!=C2=A0
--00000000000047d3df063acc1170--