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 DDC17C169409 for ; Fri, 8 Nov 2024 23:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 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_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 fhw4wcD_HYdN for ; Fri, 8 Nov 2024 23:37:55 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 F3B8EC1519A2 for ; Fri, 8 Nov 2024 23:37:49 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id 6a1803df08f44-6cbe3ea8e3fso18636716d6.0 for ; Fri, 08 Nov 2024 23:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tumbolandia.net; s=google; t=1731137868; x=1731742668; darn=irtf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=hJNSFy7nZ2GJAkgg45b7Pnri3pjSissrUbY/+5OAGtA=; b=dm61aAGhr4jHHy3WwHrPtDaYyG0EC5Z8aByXv2E1IOMZTnggmdW6ggsFSNIEC+ZSaO WxxTLpttpczuD++uu9wME0sBZQUmJxow91dHpM2u7V03QvGmJJr4CbST88Eu0t7Jb6Ta BrvFZ1Vpo9jADSJVUcvEgHw+Y9ZnCe+PfsOFw1aLUZ6mj3dROSc423uWMiWtmBT991Nd tIfr+dRaDSr553QF1cOflTL2jkXUlZ5WZFiPEMmd9cFdfOc0TMa+NFlau///s7amqSLU ctFmdge64WbJxah4wp/x9gcJxPbHCzHazpr5AJwJWjl0Jsn4LbIPnevbA/7H/lILHtR2 37Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731137868; x=1731742668; h=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=hJNSFy7nZ2GJAkgg45b7Pnri3pjSissrUbY/+5OAGtA=; b=chE4Z3U1N3DT5PFRwCUoKB7be/Z5WwxpqFQD3XFNuMZNHqsi/O7U0J137xr/z+UCtA MOlEl83Yw8cudCSY5Hb6Rf7TogCZJPYdcxpWlN1nxK3KKuCoTyOAtXCD7zExzlR4iNGf WnL8oJwpyPGi4Jf8XpQR5mioZ3T6Ia/yCajaS2xmD3+iCxqHgEFvVnzm/+kuRBJYeZJD 9W+KjZ4yAESfxQfTs0fzR/1SBGGU7AUjdXyuc/UxR7nl4U2FUhi8hIYF0YixOFWEOmDw 8pmOUWVXjHuei5402xb1iVb1fTrQnBaxh+WtGV7WsVB3rhigN+3ay6+O6uEwaMn62d4j 1GHg== X-Gm-Message-State: AOJu0Yw6qXjSpdHhexI1WIEnOpo7L9/d30XaqDEKOd9c/U0lxFbRBowG 9U4MVU+q80ymp/I4knsZabzIvXBeFD6xCRHjrGJumdUtcJYMoM73E/21i8WMJjWcg6wZ6yegzrG 0RxiRBaKRHwTYHBtk5PYta8Npkmxm1TsJXWLaETDtwPXxf9r4Kbg= X-Google-Smtp-Source: AGHT+IHABfEi0rU9rW+XblTafFtETsZEokby+pF38vwzHBpeg2+MoFDv/smLtg/lj5Cp2ptbD5jF+iD+JWSO6kL2BMs= X-Received: by 2002:a05:6214:3104:b0:6ce:26d0:c7bd with SMTP id 6a1803df08f44-6d39e1ff171mr78157766d6.40.1731137868413; Fri, 08 Nov 2024 23:37:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Michele_Orr=C3=B9?= Date: Sat, 9 Nov 2024 08:37:32 +0100 Message-ID: To: "cfrg@irtf.org" , Vasilis Kalos Content-Type: multipart/alternative; boundary="000000000000b45adb062675f1d2" Message-ID-Hash: FB33SAKMS6433FTNVXV2EXNM7AIU6B2N X-Message-ID-Hash: FB33SAKMS6433FTNVXV2EXNM7AIU6B2N 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 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: --000000000000b45adb062675f1d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vasilis, Let me reiterate my suggestions, providing actionable comments, trying to be more precise, and clarifying some parts of my previous email that might have been misleading. *Suggestion 0: add mentions of Pippenger and fixed-basis algorithms.* *>>> Add in [draft-irtf-cfrg-bbs-signatures , line 280] : * Fixed-basis scalar multiplication algorithms can improve computation time (~4x) while maintaining constant-time operations. Pippenger's algorithm can improve asymptotic complexity to O(N/log N). Common implementations are not constant-time. *Add references for both. * *Suggestion 1: make pairings optional and allow for keyed-verification.* Roughly speaking, one only needs to compute xA and check it is equal to B - eA, whether it's done in a target group or G1 doesn't matter. Concretely, the minimal change to provide compatibility is: *>>> Change [draft-irtf-cfrg-bbs-signatures , line 706] in BBS: * *- *3. if h(A, W + BP2 * e) * h(B, -BP2) !=3D Identity_GT, return INVALID Better: + 3. if h(A, W) !=3D h(B - eA, BP2), return INVALID By the way, this is going to improve performance as well (try to limit as m= any operations as possible over G2) without changing the API and remove the confusing multiplicative/additive group notation. Best: + 3. if DH(W, A, B - eA) =3D 1, return INVALID You can then describe DH as a pairing as above. Other people will override your implementation of DH without making too much of a mess around. For the record, this may be useful for everybody: it can be that the issuer has to re-check some signatures and in that case you're allowing it to do DH as they like. The same can be done for CoreProofVerify. Let's discuss blind BBS, and the server proof, later as it's not as immediately important. *Suggestion 2: make the user proof optional for one-more unforgeability applications.* I think there might have been a misunderstanding here. My proposal (coherent with your response) is: *>>> Change ProofInit [draft-irtf-cfrg-bbs-signatures , line 869-931 ] in BBS* *Move 6-7 (and the relative randomness) into a separate proving function. * *>>> Change CoreCommit [draft-kalos-bbs-blind-signatures , line 582-590 ] in blind BBS* *Move 3-7 into a separate proving function, just like you do for the standard BBS signature.* Reason: If one wants to prove one of the attributes is well-formed (e.g. is binary, or 128-bits, etc), they will be able to do so without overwriting this core function. If you want to support many attributes, it won't make any sense to hardcode =CE=A3-protocols in the spec rather than compressed =CE=A3-protocols ("bull= etproofs"). If one wants to remove the CoreCommit proof for one-more unforgeability, they will be able to set proof to the empty string in a separate spec. *Suggestion 5: better describe the security guarantees in the draft.* *>>> Add in [draft-irtf-cfrg-bbs-signatures , line 1737]:* *A paragraph similar to* [rfc9497 , 7.2.3]. *Suggestion 6: add multiplicative blinding for Blind BBS.* *>>> Add a paragraph similar to [draft-irtf-cfrg-voprf-07 , 6.6]* *>>> Add a paragraph similar to [draft-irtf-cfrg-voprf-06 , 7]* *Suggestion 7: describe the behaviour of the user/prover concerning **attributes set by the server.* *>>> Change the function signatures to match [rfc9474 = , 4] * *The API is similar to the one of VOPRF in rfc9497, which should also be checked for consistency.* In particular, *add a function Finalise, which MAY reject the signature if the user so wishes.* You can leave the function empty (trivially accept everything for now). Let other extensions (and future schemes) do the work but give them an entry point. *Suggestion 10: make proofs extensible with arbitrary statements**>> Add after [draft-irtf-cfrg-bbs-signatures , line 710] the following paragraph:* + We prove the following statement, expressed in Camenish-Stadler notation: + + ``` + ZkPoK{ + "BBS-foobar" + ph, // Label for the proof statement, whatever needs to be added to the challenge + (e, r1, r3, msg_j1, ..., msg_jU), // Secret variables + (Abar, Bbar, D, Bv, H_j1, ..., H_jU), // Public variables unique to each proof + Bbar =3D D * r1 - Abar * e, // Statements to pro= ve + Bv =3D D * r3 + H_j1 * msg_j1 + ... + H_jU * msg_jU + } + ``` *>> Add after [draft-kalos-bbs-blind-signatures , line 590] the following paragraph* + We prove the following statement, expressed in Camenish-Stadler notation: + + ``` + ZkPoK{ + "blind-BBS-foobar" + api_id, // Label for the proof statement, whatever needs to be added to the challenge + (secret_prover_blind, msg_1, ..., msg_M), // Secret variables + (Q_2, J_1, ..., J_M), // Public variables unique to each proof + C =3D Q_2 * secret_prover_blind + J_1 * msg_1 + ... + J_M * msg_M, // Statements to prove + } + ``` Reason: More clarity on the statement to be proven. It will allow people to adopt their own proof system: for L >=3D 8 it won't make much sense to use =CE=A3-protocols in the spec rather than compressed =CE=A3-protocols ("bulletproofs") whose proof size is going to be about 2log_2(L) + 2. Extra features such as pseudonyms, rate limiting etc are just additional "statements to prove". Here are suggestions that I am putting on the side for now. *Suggestion 3: bridge with rfc9576 >.* *Suggestion 4: understand the security and efficiency trade-offs with PS.* *Suggestion 9: simplify Fiat-Shamir and have a generic framework for future= * *proofs.* In particular, I'll follow up as soon as I can on the latter. Julia also rightfully pointed out the limits in the description of your proofs and in the claims of unlinkability. I haven't had time to look properly into it yet, however I am persuaded this is fine in the keyed-verification case [Orru24 , Theorem 21]. However, in keyed-verification, the server also gives an extractable proof of knowledge of the secret key. Ciao, -- Michele. On Fri, Oct 25, 2024 at 12:21=E2=80=AFPM Vasilis Kalos wrote: > Dear Michele and all, > > > > Thank you for the review! I do agree with the suggestions. See some > comments inline. > > > > > *.BBS tokens and keyed-verification* > > > =E2=80=A6 the issuer and redeemer are the same person just like in Priv= acy 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 - eA= . > > That=E2=80=99s true, but I don=E2=80=99t think the User (Client in pp) wi= ll have access to > the Issuer's sk. In the algebraic MAC case, it will be the Verifier (Orig= in > I think in pp) that will have the Issuer=E2=80=99s sk. For the Client to = verify the > signature without pairings, the Issuer will have to generate a ZKP of > knowledge for an x so that pk =3D G * x and A * x =3D C - A * e. That to = say, > although I do really like the idea of a DH oracle, making the pairings > optional may not be that simple. > > > > (We do have a draft on the above here > . > Would be open to merging the documents if there is a need) > > > *.Concrete security of the protocol * > > > *Suggestion 4: understand the security and efficiency trade-offs with P= S > signatures* > > > > The main advantage of BBS Signatures IMHO is the decoupling of the PK fro= m > the number of messages. TMU, in PS each =E2=80=9Ctype=E2=80=9D of credent= ials (with a > different number of attributes) will need a different PK. For that reason= , > BBS Signatures are more suitable for =E2=80=9Cgeneric use cases=E2=80=9D,= providing more > flexibility (like hiding the Issuer use cases). > > > *.Blind BBS multiplicative blinding* > > It is possible to have "blind BBS" as a pair (A, e) consistent with the= signature > using *multiplicative* instead of additive blind. > > > > Note that in the last version of blind signatures > > we removed the =E2=80=9Csigner_blind=E2=80=9D and re-introduced it in pse= udonyms > > only. So, the blind signature currently is (A, e). > > > > *.Blind BBS API design* > > 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 > > We also added `FinalizeBlind > ` > (Section 4.3.3 on the blind BBS signatures draft > ) > which will sign any point B, without checking any user provided proof. > > In any case, the documents are far from final. Any proposal and > contribution will be extremely appreciated. > > > *.On the zero-knowledge proofs* > > > *Suggestion 9: simplify Fiat-Shamir and have a generic framework for > future proofs* > > > > For a generic ZKP I expressed my thoughts here > = . > I=E2=80=99m still not convinced that the core BBS draft is the best place= for such > a description. > > > > Nevertheless, I will be happy to help with that, no matter where it lands= , > since I do find it really useful. > > > Kind regards, > Vasilis Kalos > --000000000000b45adb062675f1d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vasilis,=C2=A0

Let me reiterate my suggestions, providing actionabl= e comments, trying to be more precise, and clarifying some parts of my prev= ious email that=C2=A0might have been misleading.=C2=A0

=
Suggestion 0: add mentions of Pippenger and fixed-basis algorithms= .
>>> Add in [draft-irtf-cfrg-bbs-signatures,=C2=A0= line 280] :=C2=A0
=C2=A0 Fixed-= basis scalar multiplication algorithms can improve computation time (~4x) w= hile maintaining constant-time operations.
=C2=A0 Pippenger's algorithm can improve asymptotic complexit= y to O(N/log N). Common implementations are not constant-time.
=
Add references for both.=C2=A0

Sugg= estion 1: make pairings optional and allow for keyed-verification.
Roughly speaking, one only needs to compute xA and check it is equal = to B - eA, whether it's done in a target group or G1 doesn't matter= .=C2=A0
Concretely, the minimal change to provide compat= ibility is:

>>> Change [<= a href=3D"https://github.com/decentralized-identity/bbs-signature/blob/main= /draft-irtf-cfrg-bbs-signatures.md?plain=3D1#L706" target=3D"_blank">draft-= irtf-cfrg-bbs-signatures, line 706] in BBS:=C2=A0
-=C2=A03. if h(A, W + BP2 * e) * h(B, -BP2) != =3D Identity_GT, return INVALID
Better:
+ 3. if h(A, W) !=3D h(B - eA, BP2), return INVALID
By=C2=A0= the way, this=C2=A0is going to=C2=A0improve performance a= s well (try to limit as=C2=A0many operations as possible=C2=A0over G2) without changing the API and remove the confusing multiplic= ative/additive group notation.
Best:=C2=A0
<= div>+ 3. if DH(W, A, B - eA) =3D 1, return INVALID=
You can then describe DH as =C2=A0a pairing as = above. Other people will override your implementation of DH without making = too much of a mess around.
For the record, this may be useful for= =C2=A0everybody: =C2=A0it can be that the issuer has to re-check some signa= tures and in that case you're allowing it to do DH as they like.
<= div>The same can be done for CoreProofVerify. Let's discuss blind BBS, = and the server proof, later as it's not as immediately important.
=

Suggestion 2: make the user proof optional for one-m= ore unforgeability applications.
I think there migh= t have been a misunderstanding here. My proposal (coherent with your respon= se) is:=C2=A0
>>> Change ProofInit [draft-irtf-cfrg-b= bs-signatures, line 869-931] in BBS
Move 6-7 (and = the relative randomness) into a separate proving function.=C2=A0
<= div>>>> Change CoreCommit [draft-kalos-bbs-blind-signatures,= line 582-590] in blind BBS
Move 3-7 into a separate pr= oving function, just like you do for the standard BBS signature.
<= div>
Reason:
If one wants to prove one of= the attributes is well-formed (e.g. is binary, or 128-bits, etc), they wil= l be able to do so without overwriting this core function.
If you want to support many attributes, it won't make any sense t= o hardcode =CE=A3-protocols in the spec rather than compressed =CE=A3-proto= cols ("bulletproofs").
If one wants to remove the CoreC= ommit proof for one-more unforgeability, they will be able to set proof to = the empty string in a separate=C2=A0spec.

Suggestion 5: better describe the security guarantees in the draf= t.

Suggestion 6: a= dd multiplicative blinding for Blind BBS.
>&= gt;> Add a paragraph similar to [draft-irtf-cfrg-voprf-07, 6.6]
>>&= gt; Add a paragraph similar to [dr= aft-irtf-cfrg-voprf-06, 7]

Suggestion 7= : describe the behaviour of the user/prover concerning=C2=A0attribut= es set by the server.
>>> Change the fu= nction signatures to match [rfc9474, 4]=C2= =A0
The API is similar to the one of VOPRF in rfc9497, whi= ch should also be checked for consistency.
In particular,=C2= =A0add a function Finalise, which MAY reject the signature if the user s= o wishes.=C2=A0=C2=A0

You can leave the functi= on empty (trivially accept everything for now). Let other extensions (and f= uture schemes) do the work but give them an entry point.
Suggestion 10: make proofs extensible with arbitrary statem= ents
>>=C2=A0Add after [draft-irtf-cfrg-bbs-signatures, line= 710] the following paragraph:

+= We prove the following statement, expressed in Camenish-Stadler notation:<= /font>
+
+ ```
+ ZkPoK{
= + =C2=A0 "BBS-foobar" + ph, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // La= bel for the proof statement, whatever needs to be added to the challenge
+ =C2=A0 (e, r1, r3, msg_j1, ..., m= sg_jU),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Secret va= riables
+ =C2=A0 (Abar, Bbar, D, Bv, H_j1, ..., H_jU),=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 // Public variables unique to each proof
+ =C2= =A0 Bbar =3D D * r1 - Abar * e, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Statements to prove
+ =C2=A0= Bv =3D D * r3 + H_j1 * msg_j1 + ... + H_jU * msg_jU
+ }
+ ```

>> Add = after [draft-kalos-bbs-blind-signatures,=C2=A0line 590] the following pa= ragraph
+ We prove the f= ollowing statement, expressed in Camenish-Stadler notation:
+
+ ``= `
+ ZkPoK{
+ =C2=A0 "blind-BBS-foobar" + api_id,=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Label for the pro= of statement, whatever needs to be added to the challenge
= + =C2=A0 (secret_prover_blind, msg_1, ..., msg_M),= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // Secret variables
+ =C2=A0 (Q_2, J_1, ..., J_M),=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 // Public variables unique to each proof
+=C2=A0 =C2=A0C =3D = Q_2 * secret_prover_blind + J_1 * msg_1 + ... + J_M * msg_M,=C2=A0 =C2=A0//= Statements to prove
+ }
+ ```=

Reason:
M= ore clarity on the statement to be proven.=C2=A0
It will al= low people to adopt their own proof system: for L >=3D 8=C2=A0it won'= ;t make much sense to use =CE=A3-protocols in the spec rather than compress= ed =CE=A3-protocols ("bulletproofs") whose proof size is going to= be about 2log_2(L)=C2=A0+ 2.
Extra features such as pseudonyms, = rate limiting etc are just additional "statements to prove".

Here are suggestions that I am putting on the side for now.=

Suggestion 3: bridge with rfc9576 <https://www.r= fc-editor.org/rfc/rfc9576>.
Suggestion 4: understan= d the security and efficiency trade-offs with PS.
Suggesti= on 9: simplify Fiat-Shamir and have a generic framework for future=C2= =A0proofs.
In particular, I'll follow up as soon as I = can on the latter.

Julia also rightfully point= ed out the limits in the description of your proofs and in the claims of un= linkability.=C2=A0
I haven't had time to look properly into i= t yet, however I am persuaded this is fine in the=C2=A0keyed-verification c= ase [Or= ru24, Theorem 21]. However, in keyed-verification, the server also give= s an extractable proof of knowledge of the secret key.

=
Ciao,
--
Michele.

On Fri, Oct 25, 2024 at 12:= 21=E2=80=AFPM Vasilis Kalos <vasilis.kalos@mattr.global> wrote:

Dear <= /span>Michele and all,<= u>

=C2=A0

Thank = you for the review! I do agree with the suggestions. See some comments inli= ne.

=C2=A0

> <= /span>*.BBS tokens and keyed-verification*

> = =E2=80=A6 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) fo= r a message commitment C is valid if xA =3D C - eA.

That= =E2=80=99s true, but I don=E2=80=99t think the User (Client in pp) will hav= e access to the Issuer's sk. In the algebraic MAC case, it will be the = Verifier (Origin I think in pp) that will have the Issuer=E2=80=99s sk. For the Client to verify the signature without pairings, the Issuer wi= ll have to generate a ZKP of knowledge for an x so that pk =3D G * x and A = * x =3D C - A * e. That to say, although I do really like the idea of a DH = oracle, making the pairings optional may not be that simple.

=C2=A0

(We do= have a draft on the above here. Would be open to merging the documents if there is a need)

> *.Concrete security of the proto= col *

> <= /span>*Suggestion 4: understand the security= and efficiency trade-offs with PS signatures*

=C2=A0

The ma= in advantage of BBS Signatures IMHO is the decoupling of the PK from the nu= mber of messages. TMU, in PS each =E2=80=9Ctype=E2=80=9D of credentials (wi= th a different number of attributes) will need a different PK. For that reason, BBS Signatures are more suitable for =E2=80=9Cgeneric= use cases=E2=80=9D, providing more flexibility (like hiding the Issuer use= cases).

> *.Blind BBS multiplicative blind= ing*
> It is possible to have "bli= nd BBS" as a pair (A, e) consistent with the signature using *multiplicative* inst= ead of additive blind.=

=C2=A0

Note t= hat in the last version of blind signatures we removed the =E2=80=9Csigner_bli= nd=E2=80=9D and re-introduced it in pseudonyms only. So, the blind signature currently is (A, e).=


> *.Blind BBS API design*
> 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

We also added `Finaliz= eBlind` (Section 4.3.3 on the blind BBS signatures draft) which will sign any point B, without checking any user provided = proof.

In any case, the documents are far from final. Any proposal and contributio= n will be extremely appreciated.

> <= /span>*.On the zero-knowledge proofs*=

> <= /span>*Suggestion 9: simplify Fiat-Shamir an= d have a generic framework for future proofs*

=C2=A0

For a = generic ZKP I expressed my thoughts here. I=E2=80=99m still not convinced that the core BBS draft is the be= st place for such a description.

=C2=A0

Nevert= heless, I will be happy to help with that, no matter where it lands, since = I do find it really useful.


Kind regards,
Vasilis Kalos

--000000000000b45adb062675f1d2--