Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5877C1D4A70 for ; Sun, 20 Oct 2024 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tumbolandia.net Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDtpCzVXh3Lm for ; Sun, 20 Oct 2024 08:30:48 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 72BF4C1840D2 for ; Sun, 20 Oct 2024 08:30:48 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-7b15467f383so226026185a.3 for ; Sun, 20 Oct 2024 08:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tumbolandia.net; s=google; t=1729438247; x=1730043047; darn=ietf.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=QsoJx3bbQJ8qzK+7dM27/bsV7y73D2WtOTyfScSom0E=; b=YfTN876hN+t/i9OTa2yYxS0gAJoqAJqKtUgA5iACkUCqtueIyKeGtbvNFMQDEcXedT WZ6PjAvLnOKuQG32iqydq5EiglmyVFtVY1hDlCMYX1FzoYsXR0XBw+OwYBnZVs7XM6c1 REm4H1o74+hOX9FdLDo3fxn1SctF18MmGJqRxWulNyENAOmCULrp0vNvueoqm9FSLAWq nh00lqqXu2bpYubDx0rE+Y65ESEt3ail48CPSkFcqLeOkqFZSLqBzs+QSxmIeJmIywKt RgTHE0k+TLcoyMZHWmE/GVy2WpEXkUlbmgmZfs6HeUxPHSRZm6Fsc1wNE6RTSV4YuxZv 5dTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729438247; x=1730043047; 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=QsoJx3bbQJ8qzK+7dM27/bsV7y73D2WtOTyfScSom0E=; b=b8qOqZ7IESPx7iCuNnMa8foLgrK0r2r9UO0GtnHofV7ZwgERzJG9HbiM64hFD5lP2k +mdyqaHjWZcUV7CrlbK5U2xz4tJOql5bHDTVlIJkW0COKQMifC1qZMgdNtHcS1qu5/ml 2BEWz/A/Cr9rcNH6P5waBZuV0cDDimvuUcBANGH+zb1iuOe00uOO7tRbzKj5h54NSVdw lp546MIoVxj94xrhvtU1r8S9yZhC3qIT2lpg809lm00Ga5lx4RwoTll6FdLNj8pUjXyx zvVawDbZRiItFP+oE2AY/6KPZJ02e5Vpbv4puoExewhDHrH7RmYVhUCnYan28mZ5nDlK 6j0A== X-Forwarded-Encrypted: i=1; AJvYcCV1eNN81Ld2/PW8Wh6Jbb07RfEFf5C4iLjQNAoZnDkSXLwAQLGqVV3PlsElM/0rfOqmPbya@ietf.org X-Gm-Message-State: AOJu0Yz0ghuqlvl9fC3rdpainRs0UvU0ljJqKKnzKemzKTQmDbdO5Kxg 2yOwGLQYfkmhXN7TwdTsiqd+8pbRaCxQabEJZ1QwE40z9neRGw7gjK7rev9NxfscQaucBASLNng 1Cs/1Ed+Ku3qLpDhUJgsu8NDXYLOQ7DqzN/LfXg== X-Google-Smtp-Source: AGHT+IHVHQnFHUDuhNra8lboNcsprT8m9LOYhqtvfb840vi4Tleuh8Q2/4u+Q+pVL/JTzssoXTLOttB1LirHHhD/NwA= X-Received: by 2002:a05:6214:31a1:b0:6cc:2de:1dbc with SMTP id 6a1803df08f44-6cde1610a96mr113838816d6.44.1729438247285; Sun, 20 Oct 2024 08:30:47 -0700 (PDT) MIME-Version: 1.0 References: <9ac990f3-b6c4-4bdb-b2a8-d4e12927b954@gmail.com> In-Reply-To: <9ac990f3-b6c4-4bdb-b2a8-d4e12927b954@gmail.com> From: =?UTF-8?Q?Michele_Orr=C3=B9?= Date: Sun, 20 Oct 2024 17:30:31 +0200 Message-ID: To: crypto-panel@irtf.org, cfrg@ietf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006414e70624ea3830" Message-ID-Hash: LUQPLU2XWCXQFHSUGLURZL7U6UAKCT65 X-Message-ID-Hash: LUQPLU2XWCXQFHSUGLURZL7U6UAKCT65 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; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Vasileios Kalos , Andrew Whitehead , Jonathan Katz , Sam Schlesinger X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Review_of_BBS_Signatures_draft-07?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006414e70624ea3830 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Following Julia's excellent points, I=E2=80=99d like to add a high-level re= view after discussing the topic with other researchers. The comments below address both the BBS specification and the blind BBS specification. I=E2=80= =99m adding Jonathan Katz and Sam Schlesinger (both from Google) in CC, who support this specification, but note that they haven=E2=80=99t reviewed thi= s email, and any mistakes are my own. Each paragraph is preceded by a one-liner that summarises the suggestion I am trying to argue for. As Julia mentioned, standardising this protocol is challenging, so I want to start by saying that I greatly appreciate the authors' efforts in making this happen. *.Fast algorithms for scalar multiplication* *Suggestion 0: add mentions of Pippenger and fixed-basis algorithms.* The specification should provide guidance on computing fast, generic algebraic operations. This was also evident in Jaromil's implementation shared earlier. Given the generators are fixed and the signature involves multi-scalar multiplication, pointers to fixed-basis scalar multiplication and Pippenger's algorithms would help improve efficiency. *.BBS tokens and keyed-verification* *Suggestion 1: make pairings optional and allow for keyed-verification. * *Suggestion 2: make the user proof optional for one-more unforgeability applications.* *Suggestion 3: bridge with rfc9576 .* By "tokens", I mean blind signatures and anonymous tokens in the way they are being used in rfc9576 . Fact #1: Tessaro and Zhu [TZ23 , Thm. 3] showed that Blind BBS without the user proof (commitment_with_proof with= out proof) is one-more unforgeable. Fact #2: Barki et al. [BBDT16 ] showed that it's possible to use trade off pairings in BBS+ signatures with keyed-verification -- the issuer and redeemer are the same person just like in Privacy Pass (this is called "algebraic MAC" in cryptography). In fact, if the verifier has x, then we don't need a pairing map to check signatures: a BBS signature (A, e) for a message commitment C is valid if x= A =3D C - eA. This provides a natural integration with rfc9576 , enabling features like keyed-verification, public verifiability, pseudonyms, and rate-limiting, with only one-more unforgeability required. Could offering an option to remove pairings via a DH oracle in the API encourage adoption? Removing the user proof might also make this competitive with Privacy Pass extensions. @Watson Ladd has already put significant effort into implementing and describing the requirements for a rate-limiting BBS variant, so I=E2=80=99m not the only one seeing the potential. *.Concrete security of the protocol * *Suggestion 4: understand the security and efficiency trade-offs with PS signatures* *Suggestion 5: better describe the security guarantees in the draft* In the algebraic group model: (1) BBS signatures are tightly secure under the q-DL assumption where q is the number of signing queries. (2) PS [PS16 , Orru24 : Thm. 7] signatures are tightly secure under the 2-DL assumption (3-DL for keyed-verification) Given the differences in best-attacks for these schemes, why choose (1) if (2) offers stronger guarantees? This isn=E2=80=99t to discredit the authors= ' hard work; I support their efforts, but I want to challenge the reasoning. If the response is "BBS is more efficient," then what is the actual efficiency gain for 1-5 attributes with equivalent security levels? I=E2=80=99ve only = seen comparisons that don=E2=80=99t align with the spec. Shouldn=E2=80=99t we in= form implementers about best-attacks, like in [rfc9497 , Sec. 7.2.3]? *.Blind BBS multiplicative blinding* *Suggestion 6: add multiplicative blinding for Blind BBS.* Currently, the spec defines a valid BBS signature as a pair (A, e). Instead, blindly issued BBS signatures are a triple (A, e, s) where s is called secret_prover_blindand is an extra element of the message array. It's part of the message, but also implementations MUST never reveal it, lest the user will lose anonymity. This is inconvenient because: A-1. It's part of the message but requires special handling A-2. requires a new group generator A-3. adds one extra element of which we must know upon every presentation, even if not needed It is possible to have "blind BBS" as a pair (A, e) consistent with the signature using *multiplicative* instead of additive blind. This has been already done by Durak, Marco, Talayhan, Vaudenay [DMTV24 ] and myself [Orru24 ]. To do so, 1. the user selects a secret_prover_blinduniformly distributed in the scalar field as before, 2. the user computes B =3D (1/secret_prover_blind) * (P1 + Q_1 * domain + H= _1 * msg_1 + ... + H_L * msg_L + J_1 * msg_1 + ... + J_M * msg_M) Note that here we're committing to the public and private messages, and then blinding them with 1/secret_prover_blind 3. the user computes the user proof proving that Q_1 * domain + H_1 * pub_msg_1 + ... + H_L * pub_msg_L =3D secret_prover_blind * B - (J_1 * msg_= 1 + ... + J_M * msg_M) 4. the server computes A' =3D B * (1 / (SK + e)) 5. the user unblinds A'via A =3D secret_prover_blind * A' This has some disadvantages: M-1. requires the user to be aware of the server (signer) messages in order to issue a signing request. This disadvantage seems to me "manageable", and in fact much better than the alternative of carrying around a value that will uniquely identify the user. Although it is *not* possible to have the server set attributes of the user, it is possible to have the server re-randomise user attributes, which is a desirable feature in many cases. See [Orru24 , Figure 10] as blind_factor =3D secret_prover_blind * rnd_signer_msg_i + rnd_prover_msg_i where rnd_signer_msg_i is contributed by the signed and added to the commitment upon signing, and rnd_prover_msg_i is contributed by the user. I would argue that I'd never want the user to accept a signature without knowing what's up with the public attributes. What is the user supposed to do if, as a malicious issuer, I put your passport number as a public attribute? Are you going to just silently accept, complain and ask me once again? This is also part of a separate point that I will make later about the API. The Privacy Pass working group had to face a similar problem already: for VOPRFs we have a similar problem where additive and multiplicative blindings provide different features, and they do mention both options in the spec. I think this might be useful also for BBS signatures. *.Blind BBS API design* *Suggestion 7: describe the behaviour of the user/prover with respect to attributes set by the server.* *Inconsistency: Commit is capitalised, verify_commitment is not. * *Suggestion 8: separate zero-knowledge proofs from the scheme.* The functions Commit/verify_commitment are at the same time computing the message request and the representation proof for the server. I think it would be more helpful to have it separate for the following reasons: - readability. For me, it was hard to understand where the zero-knowledge proof is starting and the user commit ends. - one-more unforgeable tokens. If the user proof can be optional, it's easy to just have another specification say that that function is just a nop - extensions built on top. If the user needs to prove that one of the attributes was authenticated from another credential this makes the thing more messy than it should. It would be instructive to have a description of what is being proven, possibly in Camenish-Stadler notation. It would be helpful to have ProofChallengeCalculate provide some information on what parts can be pre-processed (similarly to BIP340). The spec currently does not specify what the user should do when a "server" attribute (a public metadata attribute) is unexpectedly set by the server. This is potentially harmful to anonymity, the user shouldn't just accept everything that makes a signature verify. I tried to find also information there about public metadata, and how it's handled in this case, but haven't found anything under the keywords *Token Challenge, Attestation information, Origin information. *Maybe @Christopher Wood can help us understand? If we copy from what they do, you're not wrong I guess.. *.On the zero-knowledge proofs* *Suggestion 9: simplify Fiat-Shamir and have a generic framework for future proofs* *Suggestion 10: make proofs extensible with arbitrary statements* This is a more general comment for the CFRG. We currently have the following RFCs, drafts, and external initiatives, all using Sigma protocols + Fiat-Shamir: rfc8235 Schnorr Non-interactive Zero-Knowledge Proof rfc9497, section-2.2 Discrete Logarithm Equivalence Proofs draft-irtf-cfrg-bbs-signatures (this draft) draft-ladd-privacypass-bbs MPTC , C2.7: ZKPoK: ZKPoK of private key If I think about what a standard should provide I think about (1) interoperability, (2) security, (3) quality. Currently, we have all these instantiations of Schnorr proofs that implement the same proof system, but implemented slightly differently for a specific statement. Unfortunately, they are at best not interoperable, and at worst exposing implementers to weird reuse attacks. Specifically for this RFC draft, we're weighing whether the authors properly handled Schnorr and Fiat-Shamir, which they shouldn't have had to do in the first place. A potential example is that BBS in the keyed-verification setting requires a server proof. The server proof is a DLEQ proof, just like in rfc9497, sec. 2.2. I am persuaded that the BBS specification should only describe the representation proof to be shown, and have them handled by a separate specification. BBS extensions should be able to add "rows" to those statements to be proven. In the actual state, because BBS can't be a spec about everything, we're limiting the scope of what BBS signatures can do to selective disclosure of messages, which is woefully insufficient for concrete applications (for instance, it is for rate-limiting and pseudonyms). Is the CFRG of the same view? Would you be open to helping an effort on Fiat-Shamir (useful also for post-quantum primitives) and Sigma Protocols? Best, -- Michele. --0000000000006414e70624ea3830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

F= ollowing Julia's excellent points, I=E2=80=99d like to add a high-level= review after discussing the topic with other researchers. The comments bel= ow address both the BBS specification and the blind BBS specification. I=E2= =80=99m adding Jonathan Katz and Sam Schlesinger (both from Google) in CC, = who support this specification, but note that they haven=E2=80=99t reviewed= this email, and any mistakes are my own. Each paragraph is preceded by a o= ne-liner that summarises the suggestion I am trying to argue for.

As Julia mentioned, standardising this protocol is challe= nging, so I want to start by saying=C2=A0that I greatly appreciate the auth= ors' efforts in making this happen.


<= b>.Fast algorithms for scalar multiplication
Suggestion 0:= add mentions of Pippenger and fixed-basis algorithms.
The specification should provide guidance on computing fast= , generic algebraic operations. This was also evident in Jaromil's impl= ementation shared earlier. Given the generators are fixed and the signature= involves multi-scalar multiplication, pointers to fixed-basis scalar multi= plication and Pippenger's algorithms would help improve efficiency.<= br>

.BBS tokens and keyed-verificatio= n
Suggestion 1: make pairings optional and allow for keyed= -verification.=C2=A0
Suggestion 2: make the user proof opt= ional for one-more unforgeability applications.
Suggestion= 3: bridge with=C2=A0rfc9576.

By "to= kens", I mean blind signatures and anonymous tokens in the way they ar= e being used in=C2=A0rfc9576.
Fact #1: Tessaro and Zhu [TZ23, Thm. 3] s= howed that Blind BBS without the user proof (commi= tment_with_proof=C2=A0without proof)= is one-more unforgeable.
Fact #2: Barki et al. = [BBDT16]=C2=A0show= ed that it's possible to use trade off pairings in BBS+ signatures with= keyed-verification -- the issuer and redeemer are the same person just lik= e in Privacy Pass (this is called "algebraic MAC" in cryptography= ).
In fact, if the verifier has x= , then we don't need a pairing map to check signatures: a BBS signature= (A, e) for a message commitment C is valid if xA =3D C -=C2= =A0eA.

This provides a natural integration = with=C2=A0rfc9576, enabling features like keyed-verification, public verifiab= ility, pseudonyms, and rate-limiting, with only one-more unforgeability req= uired. Could offering an option to remove pairings via a DH oracle in the A= PI encourage adoption? Removing the user proof might also make this competi= tive with Privacy Pass extensions.=C2=A0@Watson Ladd=C2=A0has already p= ut significant effort into implementing and describing the requirements for= a rate-limiting BBS variant, so I=E2=80=99m not the only one seeing the po= tential.

.Concrete security of the pr= otocol=C2=A0
Suggestion 4: understand the security an= d efficiency trade-offs with PS signatures
Suggestio= n 5: better describe the security guarantees in the draft
In the algebraic group model:=C2=A0
(1) BBS signature= s are tightly secure under the q-DL assumption where q is the number of sig= ning queries.
(2) PS [PS16, Orru24: Thm. 7] signatures are tightly secure un= der the 2-DL assumption (3-DL for keyed-verification)
Given the d= ifferences in best-attacks for these schemes, why choose (1) if (2) offers = stronger guarantees? This isn=E2=80=99t to discredit the authors' hard = work; I support their efforts, but I want to challenge the reasoning. If th= e response is "BBS is more efficient," then what is the actual ef= ficiency gain for 1-5 attributes with equivalent security levels? I=E2=80= =99ve only seen comparisons that don=E2=80=99t align with the spec. Shouldn= =E2=80=99t we inform implementers about best-attacks, like in [rfc9497, Se= c. 7.2.3]?=C2=A0

.Blind BBS multiplicativ= e blinding
Suggestion 6: add multiplicative blinding for B= lind BBS.

Currently, the spec defines a valid = BBS signature as a pair (A, e).
Instead, blindly issued BBS signa= tures are a triple (A, e, s) where s=C2=A0is called secret_pr= over_blindand is an extra element of the message array. It's par= t of the message, but also implementations MUST never reveal it, lest the u= ser will lose anonymity.=C2=A0
This is inconvenient because:=C2= =A0
A-1. It's part of the message but requires special handli= ng
A-2. requires a new group generator
A-3. adds one ex= tra element of which we must=C2=A0know upon every presentation, even if not= needed

It is possible to have "blind BBS&quo= t; as a pair (A, e) consistent with the sig= nature using multiplicative instead of additive blind. This has been= already done by=C2=A0Durak, Marco, Talayh= an, Vaudenay=C2=A0[DMTV24] and myself [Orru24].
To do so,=C2=A0
1. the user selects a=C2=A0secret_prover_bl= induniformly distributed in the scalar field as before,=C2=A0
<= div>2. the user computes B =3D (1/secret_prover_bl= ind) * (P1 + Q_1 * domain + H_1 * msg_1 + ... + H_L * msg_L + J_1 * msg_1 += ... + J_M * msg_M)=C2=A0
Note that here we're committ= ing to the public and private messages, and then blinding them with 1/secret_prover_blind
3. the user comput= es the user proof proving that=C2=A0Q= _1 * domain + H_1 * pub_msg_1 + ... + H_L * pub_msg_L =3D secret_prover_blind * B - (J_1 * msg_1 + ... + J_M * msg_M)
4. the server computes=C2=A0A' =3D B * (1 / (SK + e))
5. the user unblinds=C2=A0A'via A =3D=C2=A0secret_prover_blind=C2=A0* A'

This has som= e disadvantages:=C2=A0
M-1. requires the user to be aware of the = server (signer) messages in order to issue a signing request.
Thi= s disadvantage=C2=A0seems to me "manageable", and in fact much be= tter than the alternative of carrying around a value that will uniquely ide= ntify the user.=C2=A0

Although it is not possible to have the server set attributes of the user, it is possible to= have the server re-randomise user attributes, which is a desirable feature= in many cases. See [Orru24, Figure 10] as
= blind_factor =3D secret_prover_blind * rnd_signer_msg_i=C2=A0+ rnd_prover_m= sg_i
where=C2=A0rnd_= signer_msg_i=C2=A0is contributed by= the signed and added to the commitment upon signing, and=C2=A0rnd_prover_msg_i=C2=A0is contributed by the user.
<= div>I would argue that I'd never want the user to accept a signature wi= thout knowing what's up with the public attributes. What is the user su= pposed to do if, as a malicious issuer, I put your passport number as a pub= lic attribute? Are you going to just silently accept, complain and ask me o= nce again?=C2=A0
This is also part of a separate point that I= will make later about the API.

The Privacy Pass w= orking group had to face a similar problem already: for VOPRFs we have a si= milar problem where additive and multiplicative blindings provide different= features, and they do mention both options in the spec.=C2=A0
I = think this might be useful also for BBS signatures.=C2=A0
<= /div>

.Blind BBS API design
=
Suggestion 7: describe=C2=A0the behaviour of the user/prover w= ith respect to attributes set by the server.
Inconsi= stency: Commit is capitalised, verify_commitment is not.=C2=A0
Suggestion 8: separate zero-knowledge proofs from the scheme.=

The functions=C2=A0Commit/ve= rify_commitment=C2=A0are at the same time computing the message requ= est and the representation proof for the server.
I th= ink it would be more helpful to have it separate for the following reasons:= =C2=A0
- readability. For=C2=A0me, it was hard to und= erstand where the zero-knowledge proof is starting and the user commit ends= .
- one-more unforgeable tokens. If the user proof ca= n be optional, it's easy to just have another specification say that th= at function is just a nop
- exten= sions built on top. If the user needs to prove that one of the attributes w= as authenticated from another credential this makes the thing more messy th= an it should.=C2=A0
It would be instructive to have a description= of what is being proven, possibly in Camenish-Stadler notation.
= It would be helpful to have=C2=A0ProofChallengeCal= culate=C2=A0provide some informatio= n on what parts can be pre-processed (similarly to BIP340).

The spec currently does not specify what the user should do = when a "server" attribute (a public metadata attribute) is=C2=A0<= /font>unexpectedly set by the server. This is potentially harmful to anonymit= y, the user shouldn't just accept everything that makes a signature ver= ify.
I tried to find also information there about pub= lic metadata, and how it's handled in this case, but haven't found = anything under the keywords Token Challenge, Attestation information, Or= igin information.=C2=A0Maybe=C2=A0@Christopher= Wood=C2=A0can help us understand? If we copy from what they do, you= 9;re not wrong I guess..

.On the zero-knowledge proofs
Suggestion 9: simplify= Fiat-Shamir and have a generic framework for future proofs
Suggestion 10: make proofs extensible with arbitrary statements
This is a more general comment for the CFRG.
We currently have = the following RFCs, drafts, and external=C2=A0initiatives, all using Sigma = protocols + Fiat-Shamir:
rfc8235 Schnorr Non-interactive Zer= o-Knowledge Proof
rfc9497, section-2.2=C2=A0Discrete Lo= garithm Equivalence Proofs
draft-irtf-cfrg-bbs-signatures=C2= =A0(this draft)
MPTC, C2.7: ZKPoK: ZKPoK of private key

If I think about what a standard should provide I thin= k about (1) interoperability, (2) security, (3) quality.
Currently, we have all these instantiations of Schnorr proofs that impleme= nt the same proof system, but implemented slightly differently for a specif= ic statement. Unfortunately, they are at best not interoperable, and at wor= st exposing implementers to weird reuse attacks.
Specifically for this R= FC draft, we're weighing whether the authors properly handled Schnorr a= nd Fiat-Shamir, which they shouldn't have had to do in the first place.= =C2=A0
A potential example is that BBS in the keyed-verification = setting requires a server proof. The server proof is a DLEQ proof, just lik= e in rfc9497, sec. 2.2.
I am persuaded that the BBS specification= should only describe the representation proof to be shown, and have them h= andled by a separate specification.
BBS extensions should be = able to add "rows" to those statements to be proven.
In the actual=C2=A0state, because BBS can't be a spec abou= t everything, we're limiting the scope of what BBS signatures can do to= selective disclosure of messages, which is woefully insufficient for concr= ete applications (for instance, it is for rate-limiting and pseudonyms).
Is the CFRG of the same view? Would you be open to helping an effor= t on Fiat-Shamir (useful also for post-quantum primitives) and Sigma Protoc= ols?

Best,
--
Michele.


--0000000000006414e70624ea3830--