<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-vasilis-bbs-per-verifier-linkability-00" submissionType="IETF" category="info" xml:lang="en" indexInclude="true" consensus="true">

<front>
<title abbrev="BBS per Verifier Linkability">BBS per Verifier Linkability</title><seriesInfo value="draft-vasilis-bbs-per-verifier-linkability-00" status="informational" name="Internet-Draft"/>
<author initials="V." surname="Kalos" fullname="Vasilis Kalos"><organization>MATTR</organization><address><postal><street/>
</postal><email>vasilis.kalos@mattr.global</email>
</address></author><author initials="G." surname="Bernstein" fullname="Greg M. Bernstein"><organization>Grotto Networking</organization><address><postal><street/>
</postal><email>gregb@grotto-networking.com</email>
</address></author><date/>
<area>Internet</area>
<workgroup>CFRG</workgroup>

<abstract>
<t>The BBS Signatures scheme describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, build using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases where that require from the Verifier, to be able to track the BBS proofs they receive from the same entity. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with different parties. This provides a way for a recipient to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>BBS Signatures, defined in <xref target="I-D.irtf-cfrg-bbs-signatures"/> and originally described in the academic work by Dan Boneh, Xavier Boyen, and Hovav Shacham <xref target="BBS04"/>, is a signature scheme able to sign multiple messages at once, allowing for selectively disclosing those message while not revealing the signature it self. It does so by creating unlinkable, zero-knowledge proofs-of-knowledge of a signature value on (among other) the disclosed set of messages. More specifically, the BBS Prover, will create a BBS proof that if validated by the Verifier, guarantees that the prover knows a BBS signature on the disclosed messages, guaranteeing this way the revealed messages authenticity and integrity.</t>
<t>The BBS Proof is by design unlinkable, meaning that given 2 different BBS proofs, there is no way to tell if they originated from the same BBS signature. This means that if a Prover does not reveal any other identifying information (for example if they are using proxies to hide their IP address etc.), the Verifier of the proof will not be able "track" the different proof presentations or the Provers activity. This is done to guarantee privacy in applications where the Verifier only needs to know that the Prover is in possession of a valid BBS signature over a list of disclosed messages. In a lot of applications however, the Verifier needs to track the presentations made by the Prover over time, as to provide security monitoring, monetization services, configuration persistance etc.. That said, for obvious privacy reasons, the Prover should not reveal a unique identifier that would remain constant across proof presentations to different Verifiers (like their IP address).</t>
<t>The goal of this document is to provide a way for a Verifier to track the proof presentations that are intended for them, while at the same time not allowing the tracking of the Prover's activity to other Verifiers. This is done through the use of Pseudonyms. A pseudonym as defined by this document, is a value that will be constant when the Prover presents BBS proofs to the same Verifier, but will change when the Prover interacts with different recipients (with no way to link the 2 distinguee pseudonym values together). This is done by constructing the pseudonym value by combining a unique Verifier identifier with a unique Prover identifier. To avoid forging requests, the Prover's identifier will be signed by the same BBS signature used to generate the BBS proof. This allows extending the BBS proof generation and verification operations with some additional computations, that will be used to prove correctness of the pseudonym, i.e., that it was correctly calculated using the Verifier identifier, as well as, the undisclosed and signed Prover identifier. The Prover identifier MUST be considered secret from the Prover, since, if it is revealed, any entity will be able to track the Prover's activity across all Verifiers.</t>
<t>This document will define a new BBS Interface for use with pseudonyms, however it will not define new ciphersuites. Rather it will re-use the ciphersuites defined in <eref target="https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-03.html#name-ciphersuites">Section 6</eref> of <xref target="I-D.irtf-cfrg-bbs-signatures"/>).</t>

<section anchor="terminology"><name>Terminology</name>
<t>The following terminology is used throughout this document:</t>

<dl spacing="compact">
<dt>SK</dt>
<dd>The secret key for the signature scheme.</dd>
<dt>PK</dt>
<dd>The public key for the signature scheme.</dd>
<dt>L</dt>
<dd>The total number of signed messages.</dd>
<dt>R</dt>
<dd>The number of message indexes that are disclosed (revealed) in a proof-of-knowledge of a signature.</dd>
<dt>U</dt>
<dd>The number of message indexes that are undisclosed in a proof-of-knowledge of a signature.</dd>
<dt>scalar</dt>
<dd>An integer between 0 and r-1, where r is the prime order of the selected groups, defined by each ciphersuite (see also <eref target="#notation">Notation</eref>).</dd>
<dt>generator</dt>
<dd>A valid point on the selected subgroup of the curve being used that is employed to commit a value.</dd>
<dt>signature</dt>
<dd>The digital signature output.</dd>
<dt>presentation_header (ph)</dt>
<dd>A payload generated and bound to the context of a specific spk.</dd>
<dt>INVALID, ABORT</dt>
<dd>Error indicators. INVALID refers to an error encountered during the Deserialization or Procedure steps of an operation. An INVALID value can be returned by a subroutine and handled by the calling operation. ABORT indicates that one or more of the initial constraints defined by the operation are not met. In that case, the operation will stop execution. An operation calling a subroutine that aborted must also immediately abort.</dd>
</dl>
</section>

<section anchor="notation"><name>Notation</name>
<t>The following notation and primitives are used:</t>

<dl spacing="compact">
<dt>a || b</dt>
<dd>Denotes the concatenation of octet strings a and b.</dd>
<dt>I \ J</dt>
<dd>For sets I and J, denotes the difference of the two sets i.e., all the elements of I that do not appear in J, in the same order as they were in I.</dd>
<dt>X[a..b]</dt>
<dd>Denotes a slice of the array <tt>X</tt> containing all elements from and including the value at index <tt>a</tt> until and including the value at index <tt>b</tt>. Note when this syntax is applied to an octet string, each element in the array <tt>X</tt> is assumed to be a single byte.</dd>
<dt>range(a, b)</dt>
<dd>For integers a and b, with a &lt;= b, denotes the ascending ordered list of all integers between a and b inclusive (i.e., the integers "i" such that a &lt;= i &lt;= b).</dd>
<dt>length(input)</dt>
<dd>Takes as input either an array or an octet string. If the input is an array, returns the number of elements of the array. If the input is an octet string, returns the number of bytes of the inputted octet string.</dd>
</dl>
<t>Terms specific to pairing-friendly elliptic curves that are relevant to this document are restated below, originally defined in <xref target="I-D.irtf-cfrg-pairing-friendly-curves"/>.</t>

<dl spacing="compact">
<dt>E1, E2</dt>
<dd>elliptic curve groups defined over finite fields. This document assumes that E1 has a more compact representation than E2, i.e., because E1 is defined over a smaller field than E2. For a pairing-friendly curve, this document denotes operations in E1 and E2 in additive notation, i.e., P + Q denotes point addition and x * P denotes scalar multiplication.</dd>
<dt>G1, G2</dt>
<dd>subgroups of E1 and E2 (respectively) having prime order r.</dd>
<dt>GT</dt>
<dd>a subgroup, of prime order r, of the multiplicative group of a field extension.</dd>
<dt>e</dt>
<dd>G1 x G2 -&gt; GT: a non-degenerate bilinear map.</dd>
<dt>r</dt>
<dd>The prime order of the G1 and G2 subgroups.</dd>
<dt>BP1, BP2</dt>
<dd>base (constant) points on the G1 and G2 subgroups respectively.</dd>
<dt>Identity_G1, Identity_G2, Identity_GT</dt>
<dd>The identity element for the G1, G2, and GT subgroups respectively.</dd>
<dt>hash_to_curve_g1(ostr, dst) -&gt; P</dt>
<dd>A cryptographic hash function that takes an arbitrary octet string as input and returns a point in G1, using the hash_to_curve operation defined in <xref target="I-D.irtf-cfrg-hash-to-curve"/> and the inputted dst as the domain separation tag for that operation (more specifically, the inputted dst will become the DST parameter for the hash_to_field operation, called by hash_to_curve).</dd>
<dt>point_to_octets_g1(P) -&gt; ostr, point_to_octets_g2(P) -&gt; ostr</dt>
<dd>returns the canonical representation of the point P for the respective subgroup as an octet string. This operation is also known as serialization.</dd>
<dt>octets_to_point_g1(ostr) -&gt; P, octets_to_point_g2(ostr) -&gt; P</dt>
<dd>returns the point P for the respective subgroup corresponding to the canonical representation ostr, or INVALID if ostr is not a valid output of the respective point_to_octets_g* function. This operation is also known as deserialization.</dd>
</dl>
</section>
</section>

<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
</section>

<section anchor="preliminaries"><name>Preliminaries</name>

<section anchor="pseudonyms"><name>Pseudonyms</name>
<t>This document defines a pseudonym as point of the G1 group different from the Identity (<tt>Identity_G1</tt>) or the base point (<tt>BP1</tt>) of G1. A pseudonym remains constant for each Prover and Verifier pair, but is unique (and unlinkable) across different Provers or Verifiers. In other words, when the Prover presents multiple BBS proofs with a pseudonym to a Verifier, the pseudonym value will be constant across those presentations. When presenting a BBS proof with a pseudonym to another Verifier however, the pseudonym value will be different. Note that since pseudonyms are group points, their value will necessarily change if a different a ciphersuite with a different curve will be used. This document specifies pseudonyms to be BBS Interface specific (see Section TBD of <xref target="I-D.irtf-cfrg-bbs-signatures"/> for the definition of the BBS Interface). It is outside the scope of this document to provide a procedure for "linking" the pseudonyms that are used by different Interfaces or that are based on different ciphersuites. An option is for the Prover to present both Pseudonyms with the relevant BBS proofs to the Verifier, and upon validation of both, the Verifier to internally link the 2 pseudonyms together.</t>
</section>

<section anchor="prover-identifier"><name>Prover Identifier</name>
<t>Each pseudonym is constructed from a unique Prover Identifier (<tt>pid</tt>), which is an octet string that MUST be at least 32 octets long. The <tt>pid</tt> value will be the last message signed by the BBS signature. In this document the Prover Identifier is chosen by the BBS Signer. This gives the Signer the ability to track the Prover even when they present BBS proofs with pseudonyms to different Verifiers. To avoid this threat, the Prover can choose and "commit" the <tt>pid</tt> value themselves, using Blind BBS Signatures, as defined in TBD. In any case, the <tt>pid</tt> value MUST be the last signed message. It also MUST unique across different Provers with very high probability. Additionally, it MUST be indistinguishable from a random value, drawn from the uniform distribution over the space of all octet strings that are at least 32 octets long. Such value could be generated from a cryptographically secure pseudo-random number generator. See <xref target="DRBG"/> for requirements and suggestions on generating randomness.</t>
<t>As mentioned above, the pseudonym value is defined as a point of the G1 group. Serialization and deserialization of the pseudonym point MUST be done using the <tt>point_to_octets_g1</tt> and <tt>octets_to_point_g1</tt> defined by the BBS ciphersuite used (see <eref target="https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-03.html#name-ciphersuites">Section 6</eref> of <xref target="I-D.irtf-cfrg-bbs-signatures"/>).</t>
</section>

<section anchor="mapping-messages-to-scalars"><name>Mapping Messages to Scalars</name>
<t>Each BBS Interface defines an operation that will map the inputted messages to scalar values, required by the core BBS operations. Each Interface can use a different mapping procedure, as long as it comforts to the requirements outlined in TBD. For using BBS with pseudonyms, the mapping operation used by the interface is REQUIRED to additionally adhere the following rule;</t>

<artwork>For each set of messages and separate message msg',
if C1 = messages_to_scalars(messages.push(msg')),
and msg_prime_scalar = messages_to_scalars((msg')),
and C2 = messages_to_scalars(messages).push(msg_prime_scalar),
it will always hold that C1 == C2.
</artwork>
<t>Informally, the above means that each message is mapped to a scalar independently from all the other messages. For example, if <tt>a = messages_to_scalars((msg_1))</tt> and <tt>b = messages_to_scalars((msg_2))</tt>, then <tt>(a, b) = messages_to_scalars((msg_1, msg_2))</tt>. Its trivial to see that the <tt>messages_to_scalars</tt> operation that is defined in Section TBD of <xref target="I-D.irtf-cfrg-bbs-signatures"/>, has the required property. That operation will be used by the Interface defined in this document to map the messages to scalars. Note that the above operation (and hence the defined by this document Interface), only accepts messages that are octet strings.</t>
</section>
</section>

<section anchor="bbs-with-pseudonym-interface"><name>BBS with Pseudonym Interface</name>
<t>The following section defines a BBS Interface that will make use of per-origin pseudonyms. The identifier of the Interface is defined as <tt>ciphersuite_id || H2G_HM2S_PSEUDONYM_</tt>, where <tt>ciphersuite_id</tt> the unique identifier of the BBS ciphersuite used, as is defined in <eref target="https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-03.html#name-ciphersuites">Section 6</eref> of <xref target="I-D.irtf-cfrg-bbs-signatures"/>). Each BBS Interface MUST define operations to map the inputted messages to scalar values and to create the generators set, required by the core operations. The inputted messages to the defined in this document BBS Interface will be mapped to scalars using the <tt>messages_to_scalars</tt> operation defined in Section TBD of <xref target="I-D.irtf-cfrg-bbs-signatures"/>. The generators will be created using the <tt>create_generators</tt> operation defined in Section TBD of <xref target="I-D.irtf-cfrg-bbs-signatures"/>.</t>
<t>This document also defines 2 alternative core proof generation and verification operations (see <xref target="core-operations"/>), to accommodate the use of pseudonyms. Those operations will be used by the defined proof generation and verification Interface operations, in place of the <tt>CoreProofGen</tt> and <tt>CoreProofVerify</tt> operations defined in Section TBD of <xref target="I-D.irtf-cfrg-bbs-signatures"/>.</t>

<section anchor="signature-generation-and-verification"><name>Signature Generation and Verification</name>
<t>The Issuer of the BBS signature will include a constant unique prover identifier (<tt>pid</tt>) as one of the signed messages. The format of that identifier is outside the scope of this document. An options is to use a pseudo random generator to return 32 random octets. The <tt>pid</tt> value MUST be the last one in the set of signed messages.</t>
<t>More specifically, the Signer to generate a signature from a secret key (SK), a constant Prover identifier (<tt>pid</tt>) and optionally over a <tt>header</tt> and or a vector of <tt>messages</tt>, MUST execute the following steps,</t>

<artwork>1. messages = messages.push(pid)
2. signature = Sign(SK, PK, header, messages)
</artwork>
<t>Where <tt>Sign</tt> is defined in <eref target="https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-03.html#name-signature-generation-sign">Section 3.4.1</eref> of <xref target="I-D.irtf-cfrg-bbs-signatures"/>, instantiated with the <tt>api_id</tt> parameter set to the value <tt>ciphersuite_id || H2G_HM2S_PSEUDONYM_</tt>, where <tt>ciphersuite_id</tt> the unique identifier of the ciphersuite.</t>
<t>To verify the above <tt>signature</tt>, for a given <tt>pid</tt>, <tt>header</tt> and vector of <tt>messages</tt>, against a supplied public key (<tt>PK</tt>), the Prover MUST execute the following steps,</t>

<artwork>1. messages = messages.push(pid)
2. signature = Verify(PK, signature, header, messages)
</artwork>
<t>The <tt>Verify</tt> operation is defined in <eref target="https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-03.html#name-signature-verification-veri">Section 3.4.2</eref> of <xref target="I-D.irtf-cfrg-bbs-signatures"/>, instantiated with the <tt>api_id</tt> parameter set to the value <tt>ciphersuite_id || H2G_HM2S_PSEUDONYM_</tt>, where <tt>ciphersuite_id</tt> the unique identifier of the ciphersuite.</t>
</section>

<section anchor="proof-generation-with-pseudonym"><name>Proof Generation with Pseudonym</name>
<t>This section defines operations for generating a pseudonym, as well as using it to calculate a BBS proof. The BBS proof is extended to include a zero-knowledge proof of correctness of the pseudonym value, i.e., that is correctly calculated using the (undisclosed) id of the Prover (<tt>pid</tt>), and that is "bound" to the underlying BBS signature (i.e., that the <tt>pid</tt> value is signed by the Signer).</t>

<section anchor="calculate-pseudonym"><name>Calculate Pseudonym</name>
<t>The following operation describes how to calculate a pseudonym from the Prover's and the Verifier's unique identifiers (IDs), as well as a BBS Interface identifier (<tt>api_id</tt>, see TBD). The pseudonym will be unique for different Verifier and interface IDs and constant under constant inputs (i.e., the same <tt>verifier_id</tt>, <tt>pid</tt> and <tt>api_id</tt> values).</t>

<artwork>pseudonym = CalculatePseudonym(verifier_id, pid, api_id)

Inputs:

- verifier_id (REQUIRED), an octet string, representing the unique proof
                          Verifier identifier.
- pid (REQUIRED), an octet string, representing the unique Prover
                  identifier.
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").


Outputs:

- pseudonym, A point of G1, different from the Identity_G1, BP1 and P1
             (see the Parameters of this operation); or INVALID.

Parameters:

- hash_to_curve_g1, the hash_to_curve operation defined by the Hash to
                    Curve suite determined by the ciphersuite, through
                    the hash_to_curve_suite parameter.
- P1, fixed point of G1, defined by the ciphersuite.

Procedure:

1. OP = hash_to_curve_g1(verifier_id, api_id)
2. if OP is INVALID, return INVALID
3. if OP == Identity_G1 or OP == BP1 or OP == P1, return INVALID
3. pid_scalar = messages_to_scalars((pid), api_id)
4. return OP * pid_scalar
</artwork>
</section>

<section anchor="proof-generation"><name>Proof Generation</name>
<t>Thi operation computes a BBS proof with a pseudonym, which is a zero-knowledge, proof-of-knowledge, of a BBS signature, while optionally disclosing any subset of the signed messages. The BBS proof is extended to also include a zero-knowledge proof of correctness of the pseudonym, meaning that it is correctly calculated, using a signed Prover identifier and the supplied Verifier's ID.</t>
<t>Validating the proof (see <tt>ProofVerifyWithPseudonym</tt> defined in <xref target="proof-verification-with-pseudonym"/>), guarantees authenticity and integrity of the header, presentation header and disclosed messages, knowledge of a valid BBS signature as well as correctness and ownership of the pseudonym.</t>
<t>This operation makes use of <tt>CoreProofGenWithPseudonym</tt> as defined in <xref target="core-proof-generation"/>.</t>

<artwork>proof = ProofGenWithPseudonym(PK,
                              signature,
                              Pseudonym,
                              verifier_id,
                              pid,
                              header,
                              ph,
                              messages,
                              disclosed_indexes)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), an octet string of the form outputted by the
                        Sign operation.
- Pseudonym (REQUIRED), A point of G1, different from the Identity of
                        G1, as outputted by the CalculatePseudonym
                        operation.
- verifier_id (REQUIRED), an octet string, representing the unique proof
                          Verifier identifier.
- pid (REQUIRED), an octet string, representing the unique Prover
                  identifier.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to an empty string.
- ph (OPTIONAL), an octet string containing the presentation header. If
                 not supplied, it defaults to an empty string.
- messages (OPTIONAL), a vector of octet strings. If not supplied, it
                       defaults to the empty array "()".
- disclosed_indexes (OPTIONAL), vector of unsigned integers in ascending
                                order. Indexes of disclosed messages. If
                                not supplied, it defaults to the empty
                                array "()".

Parameters:

- api_id, the octet string ciphersuite_id || "H2G_HM2S_PSEUDONYM_",
          where ciphersuite_id is defined by the ciphersuite and
          "H2G_HM2S_PSEUDONYM_" is an ASCII string comprised of
          9 bytes.

Outputs:

- proof, an octet string; or INVALID.

Procedure:

1. message_scalars = messages_to_scalars(messages, api_id)
2. pid_scalar = messages_to_scalars((pid), api_id)
3. generators = create_generators(length(messages) + 2, PK, api_id)

4. proof = CoreProofGenWithPseudonym(PK,
                                     signature,
                                     Pseudonym,
                                     verifier_id,
                                     pid_scalar,
                                     generators,
                                     header,
                                     ph,
                                     message_scalars,
                                     disclosed_indexes,
                                     api_id)

5. if proof is INVALID, return INVALID
6. return proof
</artwork>
</section>
</section>

<section anchor="proof-verification-with-pseudonym"><name>Proof Verification with Pseudonym</name>
<t>This operation validates a BBS proof with a pseudonym, given the Signer's public key (PK), the proof, the pseudonym and the Verifier's identifier that was used to create it, a header and presentation header, the disclosed messages and lastly, the indexes those messages had in the original vector of signed messages. Validating the proof also validates the correctness and ownership by the Prover of the received pseudonym.</t>
<t>This operation makes use of <tt>CoreProofVerifyWithPseudonym</tt> as defined in <xref target="core-proof-verification"/>.</t>

<artwork>result = ProofVerifyWithPseudonym(PK,
                                  proof,
                                  Pseudonym,
                                  verifier_id,
                                  header,
                                  ph,
                                  disclosed_indexes,
                                  disclosed_messages)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- proof (REQUIRED), an octet string of the form outputted by the
                    ProofGen operation.
- Pseudonym (REQUIRED), A point of G1, different from the Identity of
                        G1, as outputted by the CalculatePseudonym
                        operation.
- verifier_id (REQUIRED), an octet string, representing the unique proof
                          Verifier identifier.
- header (OPTIONAL), an optional octet string containing context and
                     application specific information. If not supplied,
                     it defaults to an empty string.
- ph (OPTIONAL), an octet string containing the presentation header. If
                 not supplied, it defaults to an empty string.
- disclosed_messages (OPTIONAL), a vector of octet strings. If not
                                 supplied, it defaults to the empty
                                 array "()".
- disclosed_indexes (OPTIONAL), vector of unsigned integers in ascending
                                order. Indexes of disclosed messages. If
                                not supplied, it defaults to the empty
                                array "()".

Parameters:

- api_id, the octet string ciphersuite_id || "H2G_HM2S_PSEUDONYM_",
          where ciphersuite_id is defined by the ciphersuite and
          "H2G_HM2S_PSEUDONYM_" is an ASCII string comprised of
          9 bytes.
- (octet_point_length, octet_scalar_length), defined by the ciphersuite.

Outputs:

- result, either VALID or INVALID.

Deserialization:

1. proof_len_floor = 2 * octet_point_length + 3 * octet_scalar_length
2. if length(proof) &lt; proof_len_floor, return INVALID
3. U = floor((length(proof) - proof_len_floor) / octet_scalar_length)
4. R = length(disclosed_indexes)
5. L = U + R

Procedure:

1. message_scalars = messages_to_scalars(disclosed_messages, api_id)
2. generators = create_generators(L + 1, PK, api_id)

3. result = CoreProofVerifyWithPseudonym(PK,
                                         proof,
                                         Pseudonym,
                                         verifier_id,
                                         generators,
                                         header,
                                         ph,
                                         message_scalars,
                                         disclosed_indexes,
                                         api_id)
4. return result
</artwork>
</section>
</section>

<section anchor="core-operations"><name>Core Operations</name>
<t>This section defines the core operations used by the <tt>ProofGenWithPseudonym</tt> and <tt>ProofVerifyWithPseudonym</tt> operations defined in <xref target="proof-generation-with-pseudonym"/> and <xref target="proof-verification-with-pseudonym"/> correspondingly. Those operations are handling the main mathematical procedures required to compute and validate the BBS with pseudonym proof.</t>

<section anchor="core-proof-generation"><name>Core Proof Generation</name>
<t>This operations computes a BBS proof and a zero-knowledge proof of correctness of the pseudonym in "parallel" (meaning using common randomness), as to both create a proof that the pseudonym was correctly calculated using an undisclosed value that the Prover knows (i.e., the <tt>pid</tt> value), but also that this value is "signed" by the BBS signature (the last undisclosed message). As a result, validating the proof guarantees that the pseudonym is correctly computed and that it was computed using the Prover identifier that was included in the BBS signature.</t>
<t>The operation uses the <tt>ProofInit</tt> and <tt>ProofFinalize</tt> operations defined in TBD and the <tt>ProofWithPseudonymChallengeCalculate</tt> defined in <xref target="challenge-calculation"/>.</t>

<artwork>proof = CoreProofGenWithPseudonym(PK,
                                  signature,
                                  Pseudonym,
                                  verifier_id,
                                  pid_scalar,
                                  generators,
                                  header,
                                  ph,
                                  messages,
                                  disclosed_indexes,
                                  api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), an octet string of the form outputted by the
                        Sign operation.
- Pseudonym (REQUIRED), A point of G1, different from the Identity of
                        G1, as outputted by the CalculatePseudonym
                        operation.
- verifier_id (REQUIRED), an octet string, representing the unique proof
                          Verifier identifier.
- pid_scalar (REQUIRED), a scalar value, representing the unique Prover
                         identifier after it is mapped to a scalar.
- generators (REQUIRED), vector of points in G1.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to an empty string.
- ph (OPTIONAL), an octet string containing the presentation header. If
                 not supplied, it defaults to an empty string.
- messages (OPTIONAL), a vector of scalars representing the messages.
                       If not supplied, it defaults to the empty
                       array "()".
- disclosed_indexes (OPTIONAL), vector of unsigned integers in ascending
                                order. Indexes of disclosed messages. If
                                not supplied, it defaults to the empty
                                array "()".
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

- P1, fixed point of G1, defined by the ciphersuite.

Outputs:

- proof, an octet string; or INVALID.

Deserialization:

1.  signature_result = octets_to_signature(signature)
2.  if signature_result is INVALID, return INVALID
3.  (A, e) = signature_result

4.  messages = messages.push(pid_scalar)
5.  L = length(messages)
6.  R = length(disclosed_indexes)
7.  (i1, ..., iR) = disclosed_indexes
8.  if R &gt; L, return INVALID
9.  U = L - R
10. undisclosed_indexes = range(1, L) \ disclosed_indexes
11. disclosed_messages = (messages[i1], ..., messages[iR])

ABORT if:

1. for i in disclosed_indexes, i &lt; 1 or i &gt; L - 1

Procedure:

1.  random_scalars = calculate_random_scalars(3+U)
2.  init_res = ProofInit(PK,
                         signature_res,
                         header,
                         random_scalars,
                         generators,
                         messages,
                         undisclosed_indexes,
                         api_id)
3.  if init_res is INVALID, return INVALID

4.  OP = hash_to_curve_g1(verifier_id)
5.  pid~ = random_scalars[3+U] // last element of random_scalars
6.  U = OP * pid~
7.  pseudonym_init_res = (Pseudonym, OP, U)

8.  challenge = ProofWithPseudonymChallengeCalculate(init_res,
                                                     pseudonym_init_res,
                                                     disclosed_indexes,
                                                     disclosed_messages,
                                                     ph,
                                                     api_id)

9.  proof = ProofFinalize(challenge, e, random_scalars, messages,
                                                    undisclosed_indexes)
10. return proof_to_octets(proof)
</artwork>
</section>

<section anchor="core-proof-verification"><name>Core Proof Verification</name>
<t>This operation validates a BBS proof that also includes a pseudonym. Validating the proof, other than the correctness and integrity of the revealed messages, the header and the presentation header values, also guarantees that the supplied pseudonym was correctly calculated, i.e., that it was produced using the Verifier's identifier and the signed (but undisclosed) Prover's identifier, following the <tt>CalculatePseudonym</tt> operation defined in <xref target="calculate-pseudonym"/>.</t>
<t>The operation uses the <tt>ProofVerifyInit</tt> operation defined in TBD and the <tt>ProofWithPseudonymChallengeCalculate</tt> defined in <xref target="challenge-calculation"/>.</t>

<artwork>result = CoreProofVerifyWithPseudonym(PK,
                                      proof,
                                      Pseudonym,
                                      verifier_id,
                                      generators,
                                      header,
                                      ph,
                                      disclosed_messages,
                                      disclosed_indexes,
                                      api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- proof (REQUIRED), an octet string of the form outputted by the
                    ProofGen operation.
- Pseudonym (REQUIRED), A point of G1, different from the Identity of
                        G1, as outputted by the CalculatePseudonym
                        operation.
- verifier_id (REQUIRED), an octet string, representing the unique proof
                          Verifier identifier.
- generators (REQUIRED), vector of points in G1.
- header (OPTIONAL), an optional octet string containing context and
                     application specific information. If not supplied,
                     it defaults to an empty string.
- ph (OPTIONAL), an octet string containing the presentation header. If
                 not supplied, it defaults to an empty string.
- disclosed_messages (OPTIONAL), a vector of scalars representing the
                                 messages. If not supplied, it defaults
                                 to the empty array "()".
- disclosed_indexes (OPTIONAL), vector of unsigned integers in ascending
                                order. Indexes of disclosed messages. If
                                not supplied, it defaults to the empty
                                array "()".
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

- P1, fixed point of G1, defined by the ciphersuite.

Outputs:

- result, either VALID or INVALID.

Deserialization:

1. proof_result = octets_to_proof(proof)
2. if proof_result is INVALID, return INVALID
3. (Abar, Bbar, r2^, r3^, commitments, cp) = proof_result
4. W = octets_to_pubkey(PK)
5. if W is INVALID, return INVALID
6. R = length(disclosed_indexes)
7. (i1, ..., iR) = disclosed_indexes

ABORT if:

1. for i in disclosed_indexes, i &lt; 1 or i &gt; R + length(commitments) - 1

Procedure:

1.  init_res = ProofVerifyInit(PK, proof_result, header, generators,
                                    messages, disclosed_indexes, api_id)

2.  OP = hash_to_curve_g1(verifier_id)
3.  U = length(commitments)
4.  pid^ = commitments[U] // last element of the commitments
5.  Uv = OP * pid^ - Pseudonym * cp
6.  pseudonym_init_res = (Pseudonym, OP, Uv)

7.  challenge = ProofWithPseudonymChallengeCalculate(init_res,
                                                     pseudonym_init_res,
                                                     disclosed_indexes,
                                                     messages,
                                                     ph,
                                                     api_id)
8.  if cp != challenge, return INVALID
9.  if e(Abar, W) * e(Bbar, -BP2) != Identity_GT, return INVALID
10. return VALID
</artwork>
</section>
</section>

<section anchor="utility-operations"><name>Utility Operations</name>

<section anchor="challenge-calculation"><name>Challenge Calculation</name>

<artwork>challenge = ProofWithPseudonymChallengeCalculate(init_res,
                                                 pseudonym_init_res,
                                                 i_array,
                                                 msg_array,
                                                 ph)

Inputs:
- init_res (REQUIRED), vector representing the value returned after
                       initializing the proof generation or verification
                       operations, consisting of 3 points of G1 and a
                       scalar value, in that order.
- pseudonym_init_res (REQUIRED), vector representing the value returned
                                 after initializing the pseudonym proof,
                                 consisting of 3 points of G1.
- i_array (REQUIRED), array of non-negative integers (the indexes of
                      the disclosed messages).
- msg_array (REQUIRED), array of scalars (the disclosed messages after
                        mapped to scalars).
- ph (OPTIONAL), an octet string. If not supplied, it must default to
                 the empty octet string ("").

Outputs:

- challenge, a scalar.

Deserialization:

1. R = length(i_array)
2. (i1, ..., iR) = i_array
3. (msg_i1, ..., msg_iR) = msg_array
4. (Abar, Bbar, C, domain) = init_res
5. (Pseudonym, OP, U) = pseudonym_init_res

ABORT if:

1. R &gt; 2^64 - 1 or R != length(msg_array)
2. length(ph) &gt; 2^64 - 1

Procedure:

1. c_arr = (Abar, Bbar, C, Pseudonym, OP, U, R, i1, ..., iR,
                                            msg_i1, ..., msg_iR, domain)
2. c_octs = serialize(c_array)
3. return hash_to_scalar(c_octs || I2OSP(length(ph), 8) || ph)
</artwork>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>TODO Security</t>
</section>

<section anchor="ciphersuites"><name>Ciphersuites</name>
<t>This document does not define new BBS ciphersuites. Its ciphersuite defined in <eref target="https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-03.html#name-ciphersuites">Section 6</eref> of <xref target="I-D.irtf-cfrg-bbs-signatures"/>) can be used to instantiate the operations of the described scheme.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.irtf-cfrg-bbs-signatures.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.irtf-cfrg-hash-to-curve.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.irtf-cfrg-pairing-friendly-curves.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="BBS04" target="https://link.springer.com/chapter/10.1007/978-3-540-28628-8_3">
  <front>
    <title>Short Group Signatures</title>
    <author fullname="Dan Boneh" initials="D." surname="Boneh"/>
    <author fullname="Xavier Boyen" initials="X." surname="Boyen"/>
    <author fullname="Hovav Scacham" initials="H." surname="Shacham"/>
    <date year="2004"/>
  </front>
  <seriesInfo name="In" value="Advances in Cryptology"/>
  <seriesInfo name="pages" value="41-55"/>
</reference>
<reference anchor="DRBG" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf">
  <front>
    <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators</title>
    <author>
      <organization>NIST</organization>
    </author>
  </front>
</reference>
</references>

<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>TODO acknowledge.</t>
</section>

</back>

</rfc>
