The BBS Signature Scheme

The BBS Signature Scheme MATTR

tobias.looker@mattr.global

MATTR

vasilis.kalos@mattr.global

Portage

andrew.whitehead@portagecybertech.com

CryptID

redmike7@gmail.com

Internet CFRG This document describes the BBS Signature scheme, a secure, multi-message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. Source for this draft and an issue tracker can be found at .

Introduction A digital signature scheme is a fundamental cryptographic primitive that is used to provide data integrity and verifiable authenticity in various protocols. The core premise of digital signature technology is built upon asymmetric cryptography where-by the possessor of a private key is able to sign a message, where anyone in possession of the corresponding public key matching that of the private key is able to verify the signature. Beyond the core properties of a digital signature scheme, the BBS signatures and proofs provide multiple additional unique properties. Three key ones are: Selective Disclosure - The scheme allows a Signer to sign multiple messages and produce a single -constant size- output signature. A Prover then possessing the messages and the signature can generate a proof whereby they can choose which messages to disclose, while revealing no information about the undisclosed messages. The proof itself guarantees the integrity and authenticity of the disclosed messages (e.g. that they were originally signed by the Signer). Unlinkable Proofs - The proofs generated by the scheme are zero-knowledge, proofs of knowledge of the signature, meaning a verifying party in receipt of a proof is unable to determine which signature was used to generate the proof, removing a common source of correlation. In general, the value of a BBS proof is indistinguishable from random even if generated from the same signature. Proof of Possession - The proofs generated by the scheme prove to a Verifier that the party who generated the proof (Prover) was in possession of a signature without revealing it. The scheme also supports binding a presentation_header to the generated proof, which acts as a message signed by the Prover. The presentation_header can include arbitrary information such as a cryptographic nonce, an audience/domain identifier and or time based validity information (for more details on the presentation_header, see ). Refer to the for an elaboration on situations where these properties are useful. Below is a basic diagram describing the main entities involved in the scheme

Basic diagram capturing the main entities involved in using the scheme | Holder/ | | | | Prover | | | | | | | | | +----------+ +-----------+ | | | (4)* Send proof + disclosed msgs | | \ / +-----------+ | | | | | | | Verifier | | | | | | | +-----------+ | / \ | | | | +----- (5) ProofVerify ]]> Note The protocols implied by the items annotated by an asterisk are out of scope for this specification The name BBS is derived from the authors of the original academic work by Dan Boneh, Xavier Boyen, and Hovav Shacham , where the scheme was first described as part of a group signatures protocol. Soon after, the scheme was described by Camenisch and Lysyanskaya as a stand-alone signatures scheme in , for anonymous credentials applications. Later, Au, Susilo an Mu presented the first, provably secure version of BBS Signatures in . Following, works by Camenisch, Drijvers and Lehmann and by Barki, Brunet, Desmoulins and Traore , proved the security of the scheme in settings where more efficient computations are possible, thereby improving performance. Finally, in 2023, Tessaro and Zhu, presented in further performance improvements, shrinking the BBS signature. This document is mainly based on that work. More specifically, the BBS signature generation and verification algorithms are as defined in Section 3.1 of while the BBS proof generation and verification algorithms are as defined in Appendix B of the same work. Note that the BBS Signatures scheme is based on the discrete logarithm problem. This means that it is not "post-quantum secure". However, the privacy and hiding properties of BBS proofs are resilient even against an attacker utilizing a Cryptographically Relevant Quantum Computer (). See for an elaboration on the security properties of BBS Signatures against such a computer.

Terminology The following terminology is used throughout this document:

SK: The secret key for the signature scheme.
PK: The public key for the signature scheme.
message: An octet string, representing a signed message.
L: The total number of signed messages.
R: The number of message indexes that are disclosed (revealed) in a proof-of-knowledge of a signature.
U: The number of message indexes that are undisclosed in a proof-of-knowledge of a signature.
scalar: An integer between 0 and r-1, where r is the prime order of the selected groups, defined by each ciphersuite (see also ).
generator: A valid point on the selected subgroup of the curve being used that is employed to commit a value.
signature: The digital signature output.
header: A payload chosen by the Signer and bound to a BBS signature, as well as the BBS proofs generated using that signature.
presentation_header (ph): A payload generated and bound to a specific BBS proof.
dst: The domain separation tag.
I2OSP: An operation that transforms a non-negative integer into an octet string, defined in Section 4 of . The output of this operation is in big-endian order.
OS2IP: An operation that transforms a octet string into an non-negative integer, defined in Section 4 of . The input of this operation must be in big-endian order.
INVALID, ABORT: 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.

Notation The following notation and primitives are used:

a || b: Denotes the concatenation of octet strings a and b.
I \ J: Denotes the difference of the two sets I and J, i.e., all the elements of I that do not appear in J, in the same order as they were in I.
X[a..b]: Denotes a slice of the array X containing all elements from and including the value at index a until and including the value at index b. Note when this syntax is applied to an octet string, each element in the array X is assumed to be a single byte.
length(input): 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.
X[i]: Denotes the element of array X at index i. Note that arrays in this document are considered "zero-indexed", meaning that element indexing starts from 0 rather than 1. For example, if X = [a, b, c, d] then X[0] = a, X[1] = b, X[2] = c and X[3] = d.

Terms specific to pairing-friendly elliptic curves that are relevant to this document are restated below, originally defined in .

E1, E2: 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 P * x denotes scalar multiplication, where x is a scalar.
G1, G2: subgroups of E1 and E2 (respectively) having prime order r.
GT: a subgroup, of prime order r, of the multiplicative group of a field extension.
h: G1 x G2 -> GT: a non-degenerate bilinear map.
r: The prime order of the G1 and G2 subgroups.
BP1, BP2: base (constant) points on the G1 and G2 subgroups respectively.
Identity_G1, Identity_G2, Identity_GT: The identity element for the G1, G2, and GT subgroups respectively.
hash_to_curve_g1(ostr, dst) -> P: 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 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).
expand_message(msg, dst, len) -> ostr: returns a uniformly random octet string of len octets, deterministically on input a message msg to be hashed as an octet string, another octet string representing a domain separation tag dst and the number of octets to be returned (len).
point_to_octets_E1(P) -> ostr, point_to_octets_E2(P) -> ostr: returns the canonical representation of the point P of the elliptic curve E1 or E2 as an octet string. This operation is also known as serialization. Note that we assume that when the point is valid, all the serialization operations will always succeed to return the octet string representation of the point.
octets_to_point_E1(ostr) -> P, octets_to_point_E2(ostr) -> P: returns the point P for the respective elliptic curve corresponding to the canonical representation ostr, or INVALID if ostr is not a valid output of the respective point_to_octets_E* function. This operation is also known as deserialization.
subgroup_check_G1(P), subgroup_check_G2(P) -> VALID or INVALID: returns VALID when the point P is an element of the subgroup G1 or G2 correspondingly, and INVALID otherwise. This function can always be implemented by checking that r * P is equal to the identity element. In some cases, faster checks may also exist, e.g., . Note that these functions should always return VALID, on input the Identity point of the corresponding subgroup.

Document Organization This document is organized as follows:

Scheme Definition (), defines the core operations and parameters for the BBS signature scheme.
Utility Operations (), defines utilities used by the BBS signature scheme.
Security Considerations (), describes a set of security considerations associated to the signature scheme.
Ciphersuites (), defines the format of a ciphersuite, alongside a concrete ciphersuite based on the BLS12-381 curve.

Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in .

Scheme Definition This section defines the BBS signature scheme, including the parameters required to define a concrete instantiation of the protocol.

Parameters The schemes operations defined in this section depend on the following parameters:

A pairing-friendly elliptic curve, plus associated functionality given in .
A hash-to-curve suite as defined in , using the aforementioned pairing-friendly curve. This defines the hash_to_curve and expand_message operations, used by this document.
get_random(n): returns a random octet string with a length of n bytes, sampled uniformly at random using a cryptographically secure pseudo-random number generator (CSPRNG) or a pseudo random function. See for recommendations and requirements on the generation of random numbers.

Interfaces The BBS signature scheme is organized as follows:

A set of low level (core) operations, taking care of the main cryptographic functionality.
An Application Interface, that uses the core operations in a secure way.

Together with a set of utility procedures, defining functionality that is common between different interface procedures or core operations, a full BBS Signatures deployment can be defined. Each of the core operations (see ) expects a list of points (called the generators, see ) and a list of messages represented as scalar values (see ). It is the job of the Interface to:

Create the necessary generators.
Map the inputted messages to scalars.

This allows for extensibility of the core scheme without exposing the resulting complexity to all applications. To ensure proper separation between BBS Interfaces with distinct functionality, each Interface is parametrized by a unique identifier (called api_id) that will be used as a domain separation tag (dst) by the core () and utility () procedures. A document extending the core functionality of BBS Signatures by defining a new Interface, MUST ensure that it adheres to the requirements described in .

Considerations

Subgroup Selection For defining BBS signatures there are two possible variations regarding the subgroup selection, namely where public keys are defined in G2 and signatures in G1 OR the opposite where public keys are defined in G1 and signatures in G2. Some pairing-based digital signature schemes such as elect to allow for both variations, because they optimize for different use cases. However, in case of BBS Signatures, due to the operations involved in both signature and proof generation being computationally inefficient when performed in G2 and in the pursuit of simplicity, the BBS Signatures scheme as defined in this document is limited to a construction where public keys are in G2 and signatures in G1.

Generators Throughout the operations of this signature scheme, each message that is signed is paired with a specific point of G1, called a generator. Specifically, if a generator H_1 is multiplied with msg_1 during signing, then H_1 MUST be multiplied with msg_1 in all other operations (signature verification, proof generation and proof verification). As a result, the messages must be passed to the operations of the BBS scheme in the same order. Aside from the message generators, the scheme uses one additional generator Q_1 to sign the signature's domain, which binds both the signature and generated proofs to a specific context and cryptographically protects any potential application-specific information (for example, messages that must always be disclosed, ciphersuite parameters or an application identifier). This document uses the procedures defined in to create the generators. See on more details.

Messages In this document, the messages to be signed are defined as octet strings. Each message must be mapped to a scalar value before passed to one of the core BBS operations (). There are various ways to map a message to a scalar value. The BBS Signatures Interface defined in this document (see ), makes use of a hash function (see ). See on further details on how the each message is mapped to a scalar value and for more details and guidance on using alternative mapping methods.

Indexing of Arrays Note that arrays in this document use the zero-based numbering common in many programming languages, meaning that element indexing starts from 0 (see ). This is distinct from naming used during deserialization of arrays, where natural (one-based) numbering might be used as part of the names of the array's elements for clarity in that context. For example, if X is an array of n elements, we may write, The above would indicate that

Serializing to Octets When serializing one or more values to produce an octet string, each element will be encoded using a specific operation determined by its type. More concretely,

Points in E* will be serialized using the point_to_octets_E* implementation for a particular ciphersuite.
Non-negative integers will be serialized using I2OSP with an output length of 8 bytes.
Scalars will be serialized using I2OSP with a constant output length defined by a particular ciphersuite.

We also use strings in double quotes to represent ASCII-encoded literals. For example "BBS" will be used to refer to the octet string, 010000100100001001010011. Those rules will be used explicitly on every operation. See also serialize defined in .

Header and Presentation Header Usage There are two special values defined by the BBS Scheme; the header and the presentation_header. The header value is chosen by the Signer and is bound to both a BBS signature and to any BBS proofs generated using that signature. Specifically, the Prover is required to reveal the header to the proof Verifier during every BBS proof presentation. As a result, the Signer SHOULD NOT include in the header any identifying information that may have the potential of compromising the Prover's privacy (see ). Suitable use cases taking advantage of the header value include binding a BBS signature (and subsequent BBS proofs) to a specific application, deployment or domain, (in general, binding the signature to specific sets of metadata). Similarly, the Prover can choose a presentation_header value to be bound to the BBS proof (in contrast to the header value that is chosen by the Signer and is bound to both BBS proof and signature). Verifying a BBS proof will guarantee the authenticity and integrity of the presentation_header value. This makes it suitable for ensuring the freshness of a BBS proof, for example, by including in it a (possibly supplied by the Verifier) random value. Other use cases include binding the BBS proof to a certain domain/audience or validity period. The presentation_header can also be used by the Prover to sign a message. In this case, the Prover will add to the presentation_header the message they want to sign. A valid BBS proof guarantees that the message contained in the presentation_header was signed by the same Prover that generated that proof (similar to how group signatures work , where the group in this case will be all the Provers having received valid signatures under a specific public key).

Unlinkability As mentioned in the Introduction, a BBS proof is unlinkable. In this section we will define the term in more detail. Formally, we use unlinkability to refer to the fact that a BBS proof is zero-knowledge . In practice, this guarantees that an adversary (a Verifier, the Issuer or coalitions between one or more Verifiers and the Issuer) will not be able to infer any information from the BBS proof value, other than what the Prover decided to provide, even with access to multiple proof values. Consequently, the Verifier will not be able to correlate multiple proofs generated by the same signature or Prover. Note however, that this holds only for the value of the BBS proof. In other words, other values revealed by the Prover during their interaction with a Verifier, may still be used to correlate their activity and compromise their privacy. Examples of such values include the disclosed messages (if the same message of high enough entropy is revealed between multiple proofs), the header and presentation_header values (see Section ), or the total number of signed messages. See Section for privacy considerations and recommendations on minimizing these sources of correlation.

Key Generation Operations

Secret Key This operation generates a secret key (SK) deterministically from a secret octet string (key_material). This operation is the RECOMMENDED way of generating a secret key, but its use is not required for compatibility, and implementations MAY use a different key generation procedure. For security, such an alternative MUST output a secret key that is statistically close to uniformly random in the range from 1 to r - 1. An example of an HKDF-based alternative is the KeyGen operation defined in Section 2.3 of (with an appropriate, BBS specific, salt value, like "BBS_SIG_KEYGEN_SALT_"). For security, key_material MUST be random and infeasible to guess, e.g. generated by a trusted source of randomness and with enough entropy. See for suggestions on generating randomness. key_material MUST be at least 32 bytes long, but it MAY be longer. KeyGen takes an optional input, key_info. This parameter MAY be used to derive distinct keys from the same key material. Because KeyGen is deterministic, implementations MAY choose either to store the resulting SK or to store key_material and key_info and call KeyGen to derive SK when necessary. 65535, return INVALID 3. derive_input = key_material || I2OSP(length(key_info), 2) || key_info 4. SK = hash_to_scalar(derive_input, key_dst) 5. if SK is INVALID, return INVALID 6. return SK ]]>

Public Key This operation takes a secret key (SK) and outputs a corresponding public key (PK).

BBS Signatures Interface This section defines a BBS Signatures Interface (see ), that makes use of the core operations defined in , to perform the functions of signing and verifying the signature, as well as generating and validating the BBS proof. To create the generators (see ) it uses the create_generators operation defined in . Each input message is an octet string (see ). To map the messages to scalars, it uses the messages_to_scalars operation defined in . Generated signatures and proofs may optionally be bound to a header value. A BBS proof may additionally be bound to a presentation_header value. See for more details on the header and presentation_header usage. The api_id parameter for this Interface is defined as, where ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_" is an ASCII string comprised of 9 bytes, wherein "H2G_" refers to the identifier of the create_generators operation used (see ) and "HM2S_" is the identifier of the used messages_to_scalars mapping (see ).

Signature Generation (Sign) The Sign operation returns a BBS signature from a secret key (SK), over a header and a set of messages.

Signature Verification (Verify) The Verify operation validates a BBS signature, given a public key (PK), a header and a set of messages.

Proof Generation (ProofGen) The ProofGen operation creates a BBS proof, which is a zero-knowledge, proof-of-knowledge of a BBS signature, while optionally disclosing any subset of the signed messages. Validating the proof (see ProofVerify defined in ) guarantees authenticity and integrity of the header and disclosed messages, as well as knowledge of a valid BBS signature. Other than the Signer's public key (PK), the BBS signature and the signed header and messages, the operation also accepts a presentation_header value. That value, chosen by the Prover, will also be integrity protected (signed) by the resulting proof (see ). Finally, to indicate which of the messages should be disclosed, the operation accepts a list of integers in ascending order, representing the indexes of those messages.

Proof Verification (ProofVerify) The ProofVerify operation validates a BBS proof, given the Signer's public key (PK), a header and presentation_header values, the disclosed messages and the indexes those messages had in the original vector of signed messages.

Core Operations The operations defined in this section perform the low-level cryptographic functionality of BBS Signatures. Those core functions MUST only be invoked by an Application Interface that conform to the requirements outlined in . The operations of this section make use of functions and sub-routines defined in Utility Operations. More specifically,

hash_to_scalar is defined in
calculate_domain is defined in .
serialize, signature_to_octets, octets_to_signature, proof_to_octets, octets_to_proof and octets_to_pubkey are defined in .
h is the pairing operation used (see ), defined as part of the ciphersuite.

Each core operation will accept a vector of generators (points of G1) and optionally, a vector of messages. The generators MUST be unique and pseudo-random i.e., with no known relationship to each other. See for more details. Each message is represented as a scalar value. See for ways to map a message to a scalar and the corresponding security requirements. Furthermore, all core operations accept the Signer's public key (PK) as well as an optional octet string representing an Interface identifier (api_id). Note Some of the utility functions used by the core operations of this section could fail (ABORT). In that case, the calling operation MUST also immediately abort.

CoreSign This operation computes a deterministic signature from a secret key (SK), a set of generators (points of G1) and optionally a header and a vector of messages. Note that signature generation is deterministic, in contrast to the academic literature, where signature generation, and more specifically the calculation of the e value (Procedure step 2 below), is randomized (i.e., the e value is drawn at random, instead of been deterministically calculated by hashing the Signer's secret key and the list of messages). This alteration protects the scheme (at least the signature generation part) from vulnerabilities related to bad entropy sources, as well as some of the the best currently known attacks, as suggested in . Additionally, it makes testing of the CoreSign operation easier, as it avoids the need for a mocked random scalar. Note When computing step 4 of the above procedure there is an extremely small probability (around 2^(-r)) that the condition (SK + e) = 0 mod r will be met. How implementations evaluate the inverse of the scalar value 0 may vary, with some returning an error and others returning 0 as a result. If the returned value from the inverse operation 1/(SK + e) does evaluate to 0 the value of A will equal Identity_G1 thus an invalid signature. Implementations MAY elect to check (SK + e) = 0 mod r prior to step 4, and or A != Identity_G1 after step 4 to prevent the production of invalid signatures.

CoreVerify This operation checks that a signature is valid for a given set of generators, header and vector of messages, against a supplied public key (PK). The set of messages MUST be supplied in this operation in the same order they were supplied to CoreSign () when creating the signature.

CoreProofGen This operation computes a zero-knowledge proof-of-knowledge of a signature, while optionally selectively disclosing from the original set of signed messages. The Prover may also supply a presentation_header (denoted as ph on the input definitions of the CoreProofGen operation). See for more details. Validating the resulting proof (using the CoreProofVerify algorithm defined in ), guarantees the integrity and authenticity of the revealed messages, as well as the possession of a valid signature (for the public key PK) by the Prover. See for a high level explanation on the inner-workings of the algorithm. The CoreProofGen operation will accept that signature as an input. It is RECOMMENDED to validate that signature, using the inputted public key PK and generators set, against the supplied messages and header, with the CoreVerify operation defined in . The messages supplied in this operation MUST be in the same order as when supplied to CoreSign (). To specify which of those messages will be disclosed, the Prover can supply the list of indexes (disclosed_indexes) that the disclosed messages have in the array of signed messages. Each element in disclosed_indexes MUST be a non-negative integer, in the range from 0 to length(messages) - 1. The operation works by first calculating a set of random scalars using the calculate_random_scalars operation defined in , utilized to blind the signature and the undisclosed messages (see for considerations and requirements on random scalars generation). It then initializes the proof using the ProofInit subroutine defined in . The result will be passed to the challenge calculation operation (ProofChallengeCalculate, defined in ). The outputted challenge, together with the initialization result, will be used by the ProofFinalize subroutine defined in , which will return the proof value. L, return INVALID 7. U = L - R 8. for i in disclosed_indexes, if i < 0 or i > L - 1, return INVALID 9. undisclosed_indexes = (0, 1, ..., L - 1) \ disclosed_indexes 10. (i1, ..., iR) = disclosed_indexes 11. (j1, ..., jU) = undisclosed_indexes 12. disclosed_messages = (messages[i1], ..., messages[iR]) 13. undisclosed_messages = (messages[j1], ..., messages[jU]) Procedure: 1. random_scalars = calculate_random_scalars(5+U) 2. init_res = ProofInit(PK, signature_result, generators, random_scalars, header, messages, undisclosed_indexes, api_id) 3. if init_res is INVALID, return INVALID 4. challenge = ProofChallengeCalculate(init_res, disclosed_messages, disclosed_indexes, ph, api_id) 5. if challenge is INVALID, return INVALID 6. proof = ProofFinalize(init_res, challenge, e, random_scalars, undisclosed_messages) 7. return proof ]]>

CoreProofVerify This operation checks that a proof is valid for a header, vector of disclosed messages (disclosed_messages) along side their index corresponding to their original position when signed (disclosed_indexes) and presentation_header (denoted as ph on the input definitions of the CoreProofVerify operation) against a public key (PK). The inputted disclosed messages (disclosed_messages) MUST be supplied to this operation in the same order as they had as part of the messages input of the CoreSign operation defined in . Similarly, the indexes of the disclosed messages (disclosed_indexes) MUST be the same and in the same order as the disclosed_indexes input of CoreProofGen (). Failure to comply with these requirements will result to the proof verification procedure returning INVALID. The operation works by first initializing the proof verification procedure using the ProofVerifyInit subroutine defined in . The result will be inputted to the challenge calculation operation (ProofChallengeCalculate, defined in ). The resulting challenge and the two first components of the received proof (points of G1) will be checked for correctness (steps 5 and 6 in the following procedure), to verify the proof.

Proof Protocol Subroutines This section describes the subroutines used by the CoreProofGen () and CoreProofVerify () operations. See , for a high-level intuitive overview of the procedure used to generate and verify a BBS proof.

Proof Initialization This operation initializes the proof and returns one of the inputs passed to the challenge calculation operation (i.e., ProofChallengeCalculate, ), during the CoreProofGen operation defined in . The inputted messages MUST be supplied to this operation in the same order they had when inputted to the CoreSign operation (). The defined procedure needs the messages the Prover decided to not disclose. For this purpose, along the list of signed messages, the operation also accepts a set of integers in the range from 0 to length(messages) - 1 (inclusive) in ascending order, representing the indexes of the undisclosed messages (undisclosed_indexes). To blind the inputted signature and the undisclosed messages, the operation will also accept a set of uniformly random scalars (random_scalars). This set must have exactly 5 more items than the list of undisclosed indexes (i.e., it must hold that length(random_scalars) = length(undisclosed_indexes) + 5). This operation makes use of the calculate_domain function defined in . L - 1 2. U > L Procedure: 1. domain = calculate_domain(PK, Q_1, (H_1, ..., H_L), header, api_id) 2. B = P1 + Q_1 * domain + H_1 * msg_1 + ... + H_L * msg_L 3. D = B * r2 4. Abar = A * (r1 * r2) 5. Bbar = D * r1 - Abar * e 6. T1 = Abar * e~ + D * r1~ 7. T2 = D * r3~ + H_j1 * m~_j1 + ... + H_jU * m~_jU 8. return (Abar, Bbar, D, T1, T2, domain) ]]>

Proof Finalization This operation finalizes the proof calculation during the CoreProofGen operation defined in and returns the serialized proof value. As inputs, this operation accepts the proof initialization result as returned by the ProofInit operation defined in (init_res) as well as a scalar value representing the proof's challenge as calculated by the ProofChallengeCalculate operation defined in . It also requires the scalar part of the BBS signature (e_value), the random scalars used to generate the proof (random_scalars, as inputted to the ProofInit operation) and a set of scalars, representing the messages the Prover decided to not disclose (undisclosed_messages). Those messages MUST be supplied to this operation in the same order as they had as part of the messages input of the CoreSign operation (). This operation makes use of the proof_to_octets function defined in .

Proof Verification Initialization This operation initializes the proof verification operation and returns part of the input that will be passed to the challenge calculation operation (i.e., ProofChallengeCalculate, ), during the CoreProofVerify operation defined in . Note that, the scalars representing the disclosed messages (disclosed_messages) MUST be supplied to this operation in the same order as they had as part of the messages input of the CoreSign operation defined in (otherwise, proof verification will fail). Similarly, the indexes of the disclosed messages in the set of signed messages MUST be supplied to this operation as a set of integers in accenting order (disclosed_indexes). This operation makes use of the calculate_domain function defined in . L - 1, return INVALID 7. (j1, ..., jU) = (0, 1, ..., L - 1) \ disclosed_indexes 8. if length(disclosed_messages) != R, return INVALID 9. (msg_i1, ..., msg_iR) = disclosed_messages 10. (m^_j1, ...., m^_jU) = commitments 11. if length(generators) != L + 1, return INVALID 12. (Q_1, MsgGenerators) = generators 13. (H_1, ..., H_L) = MsgGenerators 14. (H_i1, ..., H_iR) = (MsgGenerators[i1], ..., MsgGenerators[iR]) 15. (H_j1, ..., H_jU) = (MsgGenerators[j1], ..., MsgGenerators[jU]) Procedure: 1. domain = calculate_domain(PK, Q_1, (H_1, ..., H_L), header, api_id) 2. T1 = Bbar * c + Abar * e^ + D * r1^ 3. Bv = P1 + Q_1 * domain + H_i1 * msg_i1 + ... + H_iR * msg_iR 4. T2 = Bv * c + D * r3^ + H_j1 * m^_j1 + ... + H_jU * m^_jU 5. return (Abar, Bbar, D, T1, T2, domain) ]]>

Challenge Calculation This operation calculates the challenge scalar value, used during the CoreProofGen () and CoreProofVerify (), as part of the Fiat-Shamir heuristic, for making the proof protocol non-interactive (in a interactive setting, the challenge would be a random value supplied by the Verifier). As inputs, this operation will accept the proof generation or verification initialization result, as outputted by the ProofInit () or ProofVerifyInit () operations (init_res). It will additionally accept the set of scalars representing the messages the Prover disclosed (disclosed_messages) as well as the list of indexes those messages had in the vector of signed messages (disclosed_indexes), together with the presentation_header (denoted as ph on the inputs of the ProofChallengeCalculate operation). At a high level, the challenge will be calculated as the digest (using hash_to_scalar defined in , to map it to a scalar value) of the following values:

The total number of disclosed messages R.
Each index in the disclosed_indexes list, followed by the corresponding disclosed message (i.e., if disclosed_indexes = [i1, i2] and disclosed_messages = [msg_i1, msg_i2], the input to the challenge digest, after R, will include i1 || msg_i1 || i2 || msg_i2).
The points Abar, Bbar, D, T1, T2 and the domain scalar, calculated during the proof initialization phase of CoreProofGen (see ).
The input presentation_header (ph) values.

This operation makes use of the serialize function, defined in . 2^64 - 1 2. length(ph) > 2^64 - 1 Procedure: 1. c_arr = (R, i1, msg_i1, i2, msg_i2, ..., iR, msg_iR, Abar, Bbar, D, T1, T2, domain) 2. c_octs = serialize(c_arr) || I2OSP(length(ph), 8) || ph 3. return hash_to_scalar(c_octs, hash_to_scalar_dst) ]]> Note: If the presentation_header (ph) is not supplied in ProofChallengeCalculate, 8 bytes representing a length of 0 (i.e., 0x0000000000000000), must still be appended after the serialize(c_arr) value, during the concatenation step of the above procedure (step 2).

Defining New Interfaces This document defines a BBS Interface to be a set of operations that use the core functions defined in , to generate and validate BBS signatures and proofs. These core operations require a set of generators, and optionally, a set of scalars representing the messages. The Interface operations are tasked with creating the generators, as well as mapping the received set of messages to a set of scalar values. The created generators MUST follow the requirements listed in . If a set of messages is supplied, the mapping to scalars procedure MUST follow the requirements listed in . Each Interface MUST also define a unique identifier as a parameter, called api_id. It is RECOMMENDED from the operations that create generators and map messages to scalars, to also define a unique identifiers (see ). Assuming that CREATE_GENERATORS_ID is the unique identifier of the operation that creates the generators and MAP_TO_SCALAR_ID is the unique identifier of the operation that maps the messages to scalars, the RECOMMENDED format for the api_id is the following: Where ciphersuite_id is defined by the ciphersuite and the ADD_INFO value is an optional octet string indicating any additional information used to uniquely qualify the Interface. When ADD_INFO is present, it MUST only contain ASCII encoded characters with codes between 0x21 and 0x7e (inclusive) and MUST end with an underscore (ASCII code: 0x5f), other than the last character the string MUST NOT contain any other underscores (ASCII code: 0x5f). The api_id value, MUST be used by all subroutines an Interface calls, to ensure proper domain separation. Interfaces are meant to make it easier to use BBS Signature as part of other protocols with different requirements (for example, different types of input messages or different ways to create the generators), or to extend BBS Signatures with additional functionality (for example, using blinded messages as in ). Documents defining new BBS Interfaces, other than adhering to the requirements listed in this section, should also include a detailed and peer reviewed analyses showcasing that, under reasonable cryptographic assumptions, the documented scheme is secure under the required security definitions and threat model of each protocol. In other words, Interfaces must be treated like Ciphersuites (), in the sense that applications should avoid creating their own, proprietary Interfaces.

Utility Operations This section defines utility operations that are used by either the BBS Interface or the BBS Core Operations.

Interface Utilities This section defines the create_generators and messages_to_scalars operations that are used by the BBS Signatures Interface defined in . It also defines requirements for alternative operations that calculate generators and map messages to scalars. It is RECOMMENDED that the create_generators and messages_to_scalars operations define a unique identifier, called CREATE_GENERATORS_ID and MAP_TO_SCALAR_ID respectively. Those identifiers will be used to construct the Interface identifier (see ).

Generators Calculation The create_generators procedure defines how to create a set of randomly sampled points from the G1 subgroup, called the generators. It makes use of the primitives defined in (more specifically of hash_to_curve and expand_message) to hash a seed to a set of generators. Those primitives are implicitly defined by the ciphersuite, through the choice of a hash-to-curve suite (see the hash_to_curve_suite parameter in ). Since create_generators generates constant points, as an optimization, implementations MAY cache its result for a specific count (which can be arbitrarily large, depending on the application). Care must be taken, to guarantee that the generators will be fetched from the cache in the same order they had when they where created (i.e., an application should not sort or in any way rearrange the cached generators). 2^64 - 1 Procedure: 1. v = expand_message(generator_seed, seed_dst, expand_len) 2. for i in (1, 2, ..., count): 3. v = expand_message(v || I2OSP(i, 8), seed_dst, expand_len) 4. generator_i = hash_to_curve_g1(v, generator_dst) 5. return (generator_1, ..., generator_count) ]]> The value of v MAY also be cached in order to efficiently extend an existing list of cached generator points. The CREATE_GENERATORS_ID of the above operation is define as,

Defining new Generators When defining a new create_generators procedure, the most important property is that the points are pseudo-randomly chosen from the G1 group, with no known relationship to each other, given reasonable assumptions and cryptographic primitives. More specifically, the required properties are

The generators should be indistinguishable from uniformly random points of G1 (even given the knowledge of the system's public parameters, like the generator_seed value in ). This means that given only the points H_1, ..., H_i it should be infeasible to guess H_(i+1) (or any H_j with j > i), for any i. This also means that it should be infeasible to represent any of the generators as multi-exponentiation product (i.e., of the form H_i1 * a_1 + H_i2 * a_2 + ... + H_in * a_n) of any of the other generators.
The returned points must be unique with very high probability, that would not lessen the targeted security level of the ciphersuite. Specifically, for a security level k, the probability of a collision should be at most 1/2^k.
The returned points must be different from the Identity point of G1 as well as the constant point P1 defined by the ciphersuite.

Every operation that is used to return generator points for use with the core BBS operations (), MUST return points that conform to the aforementioned rules. Such operation must also follow the rules outlined bellow,

It MUST be deterministic and constant time for a specific number of generators.
It MUST use proper domain separation for both the create_generators procedure, as well as all of the internally-called procedures.

Messages to Scalars The messages_to_scalars operation is used to map a list of messages to their respective scalar values, which are required by the core BBS operations defined in . 2^64 - 1 Procedure: 1. L = length(messages) 2. for i in (1, ..., L): 3. msg_scalar_i = hash_to_scalar(messages[i], map_dst) 4. return (msg_scalar_1, ..., msg_scalar_L) ]]> The MAP_TO_SCALAR_ID of the above operation is defines as,

Define a new Map to Scalar The most important property that a new operation that will map a set of messages to a set of scalars must have, is that each message should be mapped to a scalar independently from all the other messages. More specifically, the following MUST hold, Note that the above property ensures that if a message is mapped to a scalar on its own or as part of a set of messages, it will not affect the resulting scalar value. Additionally, the new operation MUST conform to the following requirements:

The returned scalars MUST be independent. More specifically, knowledge of any subset of the returned scalars MUST NOT reveal any information about the scalars not in that subset.
Unique inputs MUST result in unique outputs.
If the inputted vector of messages does not include any duplicates, the outputted scalars MUST NOT include any duplicates either.
It MUST be deterministic and constant time on the length of the inputted vector of messages.

Core Utilities This section defines utility procedures that are used by the Core operations defined in .

Random Scalars This operation returns the requested number of pseudo-random scalars, using the get_random operation (see ). The operation makes multiple calls to get_random. It is REQUIRED that each call will be independent from each other, as to ensure independence of the returned pseudo-random scalars. Note: The security of the proof generation algorithm (ProofGen defined in ) is highly dependant on the quality of the get_random function. Care must be taken to ensure that a cryptographically secure pseudo-random generator is chosen, and that its outputs are not leaked to an adversary. See also for more details and guidance.

Hash to Scalar This operation describes how to hash an arbitrary octet string to a scalar value in the multiplicative group of integers mod r (i.e., values in the range from 1 to r - 1). This procedure acts as a helper function, used internally in various places within the operations described in the spec. The operation takes as input an octet string representing the octet string to hash (msg) and a domain separation tag (dst). The length of the dst MUST be less than 255 octets. See section 5.3.3 of for guidance on using larger dst values. Note This operation makes use of expand_message defined in . The operation expand_message may fail (abort). In that case, hash_to_scalar MUST also ABORT. 255 Procedure: 1. uniform_bytes = expand_message(msg_octets, dst, expand_len) 2. return OS2IP(uniform_bytes) mod r ]]>

Domain Calculation This operation calculates the domain value, a scalar representing the distillation of all essential contextual information for a signature. The same domain value must be calculated by all parties (the Signer, the Prover and the Verifier) for both the signature and proofs to be validated. The input to the domain value includes the header value chosen by the Signer to encode any information that is required to be revealed by the Prover (such as an expiration date, or an identifier for the target audience). This is in contrast to the signed message values, which may be withheld during a proof. When a signature is calculated, the domain value is combined with a specific generator point (Q_1, see CoreSign defined in ) to protect the integrity of the public parameters and the header. This operation makes use of the serialize function, defined in . 2^64 - 1 or L > 2^64 - 1 Procedure: 1. dom_array = (L, Q_1, H_1, ..., H_L) 2. dom_octs = serialize(dom_array) || api_id 3. dom_input = PK || dom_octs || I2OSP(length(header), 8) || header 4. return hash_to_scalar(dom_input, hash_to_scalar_dst) ]]> Note: If the header is not supplied in calculate_domain, it defaults to the empty octet string (""). This means that in the concatenation step of the above procedure (step 3), 8 bytes representing a length of 0 (i.e., 0x0000000000000000), will still need to be appended at the end, even though a header value is not provided.

Serialization

Serialize This operation describes how to transform multiple elements of different types (i.e., elements that are not already in a octet string format) to a single octet string (see ). The inputted elements can be points, scalars (see ) or integers between 0 and 2^64-1. The resulting octet string will then either be used as an input to a hash function (i.e., in CoreSign , CoreVerify , CoreProofGen and CoreProofVerify ), or to serialize a signature or proof (see signature_to_octets and proof_to_octets ).

Signature to Octets This operation describes how to encode a signature to an octet string. Note this operation deliberately does not perform the relevant checks on the inputs A and e because its assumed these are done prior to its invocation, e.g., as is the case with the CoreSign operation.

Octets to Signature This operation describes how to decode an octet string, validate it and return the underlying components that make up the signature. = r, return INVALID 12. return (A, e) ]]>

Proof to Octets This operation describes how to encode as an octet string, a proof as computed by CoreProofGen in (or, more precisely, by step 5 of the ProofFinalize operation defined in ). The inputted proof value must consist of the following components, in that order:

Three (3) valid points of the G1 subgroup, different from the identity point of G1 (i.e., Abar, Bbar, D, in ProofGen)
Three (3) integers representing scalars in the range of 1 to r - 1 inclusive (i.e., e^, r1^, r3^, in ProofGen).
A number of integers representing scalars in the range of 1 to r - 1 inclusive, corresponding to the undisclosed from the proof messages (i.e., m^_j1, ..., m^_jU, in ProofGen, where U the number of undisclosed messages).
One (1) integer representing a scalar in the range 1 to r-1 inclusive (i.e., c in ProofGen).

Octets to Proof This operation describes how to decode an octet string representing a proof, validate it and return the underlying components that make up the proof value. The proof value outputted by this operation consists of the following components, in that order:

Three (3) valid points of the G1 subgroup, each of which must not equal the identity point.
Three (3) integers representing scalars in the range of 1 to r - 1 inclusive.
A set of integers representing scalars in the range of 1 to r - 1 inclusive, corresponding to the undisclosed from the proof message commitments. This set can be empty (i.e., "()").
One (1) integer representing a scalar in the range of 1 to r - 1 inclusive, corresponding to the proof's challenge (c).

= r, return INVALID 15. index += octet_scalar_length 16. j += 1 17. if index != length(proof_octets), return INVALID 18. msg_commitments = () 19. if j > 4, set msg_commitments = (s_3, ..., s_(j-2)) 20. return (A_0, A_1, A_2, s_0, s_1, s_2, msg_commitments, s_(j-1)) ]]>

Octets to Public Key This operation describes how to decode an octet string representing a public key, validates it and returns the corresponding point in G2. Steps 2 to 5 check if the public key is valid. As an optimization, implementations MAY cache the result of those steps, to avoid unnecessarily repeating validation for known public keys.

Privacy Considerations This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Signer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Signer. Bear in mind that those guarantees concern only the proof value, as outputted by the CoreProofGen (Section ) and of course the ProofGen (Section ) operations. Correspondingly, the unlinkability property does not include other values that a Prover could either knowingly or unknowingly provide to a Verifier. Those values can include disclosed messages of high entropy, the header and presentation_header values, their network address, or generally any information disclosed during an interaction with the Verifier having the potential to identify the user. Such threats, if exploited, could lead to correlation of the Prover's interactions with different Verifiers, resulting to fingerprinting attacks against the Prover's activity. The following sections will describe possible privacy threats, resulting from such values and side channels, that could compromise the unlinkability property of the BBS proof. Note that, the following sections describe ways to minimize possible identifying information revealed during a BBS proof presentation, related to the BBS Signatures scheme. To minimize the privacy threats of an entire system, other protections may also need to be employed, for example, using an IP hiding proxy network like TOR ().

Header and Presentation Header As mentioned in Section , the header value is chosen by the Signer and bound to a BBS Signature and proof. Consequently, it must be revealed to the Verifier, together with a BBS proof. If that header value is chosen to have high entropy (i.e., unique per credential, Prover or small group of Provers), it can be used as a correlation vector to trace and link together all BBS proofs made by a signature bound to that header value. This will result in significantly worse privacy guarantees, by allowing adversaries to trace and link together all generated proofs bound to that header value (for example, if a random header is used during each BBS signature generation, adversaries will be able to link and trace the BBS proofs generated from that signature). The Issuer MUST choose a low entropy header value and it MUST be the same for a large number of users (Provers). Examples of acceptable values include, an application identifier, a country identifier or a low cardinality version number. Examples of unacceptable values include, random values, high cardinality expiration dates, the Prover's email address or any other identifying information. On the other hand, the misuse of a presentation_header, chosen by the Prover and only bound to a BBS proof, does not incur as many privacy risks as the header value. For example, since a new presentation_header can be chosen each time a BBS proof is generated, random values are a viable choice. Still, to not break the unlinkability property, care must be taken that the presentation_header does not identify a single or small group of Provers. If the presentation_header is chosen to have high entropy (for example, to be a random value, a high accuracy locality identifier or a specific software build number), then the same value must not be used for more than one Proof generations. Note however, that even though the presentation_header can include high entropy values (as long as they are used only once), its a good practice for the Prover to avoid revealing personally identifying information (like their name, email address or phone number), to minimize the danger of correlating that information with other data sources, potentially unrelated to the specific application.

Total Number and Index of Signed Messages When a Prover presents a BBS proof to a Verifier, other than the messages they decide to disclose, there are two additional pieces of information that will be revealed. First, the total number of signed messages, which can be inferred from the size of the BBS proof and the length of the disclosed messages list. Second, the indexes that the disclosed messages had in the list of signed messages (see ). This information, if unique to each Prover, could be employed to correlate multiple proof presentations together. As a result, the Signer should not sign lists of messages with unique lengths or unique indexing. For this reason, it is RECOMMENDED that signed lists of messages are padded to a common length (using either random, or an unused by the application message, like 0 or 1). It is also RECOMMENDED that a constant ordering of messages will be preserved when possible. For example, if an application creates signatures for the messages [<user_name>, <user_affiliation>, <user_country>], then those messages should always be signed in the same order, i.e., first message should always be the user's name (<user_name>), second message should always be the user's affiliation (<user_affiliation>) and the last message should always be the user's country of origins (<user_country>). Provers can employ consistency validation mechanisms, like the ones described in , to validate that those values are not used to correlate them.

Signer Public Keys As with most systems based on public key cryptography, multiple BBS signatures (and the subsequent BBS proofs) could be correlated with each other, if the Signer does not use the same key for a large set of produced signatures. For example, the Signer could use a different key to generate the signatures intended for a specific user, or a small set of users. Every proof generated by that set of users would then be linked to that group (since it will be validated by a different public key). To avoid fragmentation of the user space by different public keys, an application could use the same mechanisms that where proposed to check the consistency of the total number of messages and their indexes (i.e., , see ).

Disclosed Messages Although multiple BBS proofs cannot be linked to each other, privacy also depends on the uniqueness of the disclosed messages during proof generation. If a unique message (or unique combination of messages) is revealed multiple times, it could be used to link the corresponding proofs together. Examples of such messages include full names, government IDs, email addresses and phone numbers. If not required by the use case, the Prover should avoid disclosing such information when constructing a BBS proof. For certain types of message values, set membership proofs (for example, ) or range proofs (for example, ) could be used to further mitigate the above issue. With a set membership proof, the BBS proof Verifier will be able to validate that one of the Prover's signed (and undisclosed) messages, belongs to a pre-defined set (for example that the Prover's government ID belongs to a set of valid government IDs). The inverse is also possible, where the Prover showcases that one of the undisclosed messages is not part of a set (for example, that a signed unique revocation identifier is not part of the set of revoked identifiers). If a message is represented by a numeric value (see ), range proofs can be used to prove that it is within a specific range. As an example, a Prover, instead of revealing their age, they could use a range proof to showcase that they are over 18 years old.

Security Considerations

Validating Public Keys Note that all core operations as defined in expect the Signer's public key as input. It is RECOMMENDED for all those operations, that they deserialize the public key first using the octets_to_pubkey procedure defined in , even if they only require the octet string representation of the public key. If the octets_to_pubkey procedure returns INVALID, the calling operation should also return INVALID and abort. This recommendation applies to the CoreSign () and CoreProofGen () operations. An explicit invocation to the octets_to_pubkey operation is already defined and therefore required in the CoreVerify () and CoreProofVerify () operations. If the required checks for the validity of the Signer's public key are not performed, the results are unpredictable, leading to unexpected vulnerabilities (for example, the output of the pairing operation on input of an invalid elliptic curve point can be highly irregular and implementation-dependent, with some returning the identity point of the elliptic curve and others returning errors).

Skipping Membership Checks The subgroup check subgroup_check_G* invocation during either signature deserialization (octets_to_signature, defined in ), proof deserialization (octets_to_proof, defined in ) or public key deserialization (octets_to_pubkey, define in ) is REQUIRED by all implementations. Failure to comply would lead to unpredicted behavior and vulnerabilities. Note that some libraries implementing the pairing-friendly curves functionality, may incorporate that check as part of a octets_to_point_G1 or octet_to_point_G2 operation (i.e., operations that both deserialize an octet string to get an elliptic curve point and then check if the resulting point is part of the G1 or G2 group accordingly). In those cases, the implementer must make sure that those checks are executed correctly. Note that checking that the points are in the correct subgroup is essential to avoid possible forgeries of a BBS signature or proof (). Furthermore, the pairing operation is undefined when its input points are not in G1 and G2. As a result, applications MUST execute all the subgroup checks defined by this document.

Side Channel Attacks There are two places where side channel attacks could be relevant in the BBS Signatures scheme. First, against the Signer, where side channel leakage during signature generation could reveal their secret key. Second, against the Prover, where a side channel attack could be used during proof generation to either directly reveal the undisclosed messages and signature value, or reveal the random scalars used, leading again to the leakage of the undisclosed messages or the hidden signature. Therefore, implementations MUST apply proper side channel attack protection. One method to achieve this, is by using elliptic curve implementations that execute curve operations in constant time.

Presentation Header Selection The signature proofs of knowledge generated in this specification are created using a specified presentation_header. A Verifier-specified cryptographically random value (e.g., a nonce) featuring in the presentation_header provides strong protections against replay attacks, and is RECOMMENDED in most use cases. In some settings, proofs can be generated in a non-interactive fashion, in which case verifiers MUST be able to verify the uniqueness of the presentation_header values.

Implementing hash_to_curve_g1 The security analysis models hash_to_curve_g1 as random oracles. It is crucial that these functions are implemented using a cryptographically secure hash function. For this purpose, implementations MUST meet the requirements of . In addition, ciphersuites MUST specify unique domain separation tags for hash_to_curve. Some guidance around defining this can be found in .

Choice of Underlying Curve BBS signatures can be implemented on any pairing-friendly curves suitable for type 3 pairing computations. However care must be taken when selecting one that is appropriate, to guarantee the desired security level for the targeted application. This specification defines a ciphersuite for using the BLS12-381 curve in which as a curve achieves around 117 bits of security .

Randomness Requirements The key_material input to the KeyGen operation defined in MUST be infeasible to guess and MUST be kept secret. One possibility is to generate the key_material from a trusted, cryptographically secure pseudo random function . Secret keys MAY be generated using other methods; in this case they MUST be infeasible to guess and MUST be indistinguishable from uniformly random modulo r. The ProofGen operation defined in is by its nature a randomized algorithm, requiring the generation of multiple uniformly distributed, pseudo random scalars. This makes ProofGen vulnerable to attacks caused by bad entropy (like the ones described in ). If randomness is re-used or is in any way predictable or maliciously constructed, an adversary may be able to unveil undisclosed information from the proof messages or the hidden signature value. More subtle attacks are also possible, where the security properties of the BBS proof may not be broken, but a system making use of the BBS scheme may still be compromised. As an example, consider systems that needs to monitor and potentially restrict outbound traffic, in order to minimize data leakage during a breach. In such cases, the attacker could manipulate couple of bits in the output of the get_random function () to create an undetected channel out of the system. Although the applicability of such attacks is limited for most of the targeted use cases of the BBS scheme, some applications may want to take measures towards mitigating them. To that end, it is RECOMMENDED to use a deterministic RNG (like a ChaCha20 based deterministic RNG), seeded with a unique, uniformly random, single seed . This will limit the amount of bits the attacker can manipulate (note that some randomness is always needed). In any case, the randomness used in ProofGen MUST be unique in each call and MUST have a distribution that is indistinguishable from uniform. If the random scalars are re-used, created from "bad randomness" (for example with a known relationship to each other) or are in any way predictable, the undisclosed messages or the signature value may be compromised. Naturally, a cryptographically secure pseudorandom number generator or pseudo random function is REQUIRED to implement the get_random functionality. See for guidance on implementing such functionality. See also , for recommendations on generating good randomness in cases where the Prover has direct or in-direct access to a secret key.

Mapping Messages to Scalars In an application using BBS Signatures, there are two places where messages could be processed. First, before the messages are passed to the BBS Interface operations, and second, after they are passed to the BBS Interface operations but before they are passed to the BBS Core operations. To allow for re-usability of software, it is RECOMMENDED that application specific processing (like UTF-8 encoding or Base-64 decoding ) would happen before messages are passed to the BBS Interface operations. In those cases, the application should ensure that all protocol participants have a clear and consistent understanding of which method should be used to process a message. This can be achieved by associating specific Interfaces (with unique api_id values, see ) or unique header values (see ) with different pre-processing methodologies. Note that the BBS Interface defined in this document (see ) only accepts messages that are represented as octet strings. However, in some more advanced applications, like the ones using range proofs () to prove that a signed message is within some range (without disclosing that message), the pre-processing of messages may result to some of them being mapped to scalar values, before they are passed to the BBS Interface (for example, an application could use to represent dates as integers or map the user's age directly to a number) that should directly be signed (e.g., to not be further processed by hash_to_scalar). If a BBS Interface accepts both octet strings and scalar values as messages, where depending on the message's type different operations will be used to map it to a scalar (e.g., hash_to_scalar for octet strings and the identity operation for scalars), it must still ensure that the properties described in holds. To that end, the application MUST ensure that it is clear to all participants, which message should be considered an octet string and which a scalar. As an example, if the type (i.e., octet string or scalar) of the messages inputted to the BBS Interface, is uniquely determined by its index in the messages list (for example, first message is an octet string, second message a scalar etc.,), the map between message index and message type (determined by the Signer), could be made available as part of the Signer's public parameters (similar to ). This map would then be passed to the BBS Interface, which will use it to correctly map each message to a scalar. Another option, is to sign such configurations as part of the header parameter of the BBS signature (see ). In this case, the map does not need to be published by the Signer. If the application defines that the first (or last) n messages will be scalars and everything else octet strings, it could just publish the n value as part of the Signer's public parameters or again sign it as part of the header value. In any case, the privacy considerations described in MUST NOT be violated, for example, by using unique pre-processing rules or maps between message index and type. To validate the consistency of the message processing rules, the Prover could use mechanisms like the ones described in .

Post-quantum Security BBS Signatures combine two security properties; data authenticity and data confidentiality. Data authenticity refers to the inability of anyone other that the Signer being able to generate BBS signatures that are valid under the Signer's public key (this property is often referred to as unforgeability, or in the case of BBS Signatures, strong unforgeability, e.g., by ). It also means that no one should be able to generate valid BBS proofs disclosing sets of messages, without first obtaining a valid BBS signature on those messages (in academic works, this is referred to as the BBS proof being a proof-of-knowledge of a BBS signature ). Data confidentiality means that no one (not even the Signer) should be able to use a BBS proof to extract information about the messages the Prover decided not to disclose during the proof generation process, or the signature that was used to generate that proof (something that is referred to as the zero-knowledge property of the BBS proof ). On the presence of a Cryptographically Relevant Quantum Computer (CRQC), meaning a computer that will be able to break the discrete logarithm problem in the groups used by BBS Signatures (see ), the data authenticity property will not hold. Specifically, an adversary could use a CRQC to reveal the Signer's secret key from their public key, hence giving them the ability to generate BBS signatures on behalf of that Signer, for messages of their choosing, as well as BBS proofs using those signatures. On the other hand, data confidentiality cannot be broken, even by adversaries with unbounded computational resources and in possession of the Signer's secret key. This means that even by utilizing a CRQC, adversaries will not be able to compromise the data confidentiality property of BBS proofs. As a result, an adversary with access to such a quantum computer, will not be able to reveal either the messages undisclosed by a BBS proof, or the hidden signature value (which the Prover showcases possession of). This guarantees that the privacy and hiding properties of BBS proofs that are currently used, will not be compromised by future quantum-attacks (a property that is often referred to as everlasting privacy). Note that this only considers BBS proofs, not BBS signatures, which do not possess the same hiding properties as the BBS proofs.

Ciphersuites This section defines the format for a BBS ciphersuite. It also gives concrete ciphersuites based on the BLS12-381 pairing-friendly elliptic curve .

Ciphersuite Format

Ciphersuite ID The following section defines the format of the unique identifier for the ciphersuite denoted ciphersuite_id, which will be represented as an ASCII encoded octet string. The REQUIRED format for this string is

H2C_SUITE_ID is the suite ID of the hash-to-curve suite used to define the hash_to_curve function.
ADD_INFO is an optional octet string indicating any additional information used to uniquely qualify the ciphersuite. When present this value MUST only contain ASCII encoded characters with codes between 0x21 and 0x7e (inclusive) and MUST end with an underscore (ASCII code: 0x5f). The last character MUST be the only underscore.

Additional Parameters The parameters that each ciphersuite needs to define are generally divided into three main categories; the basic parameters (a hash function, a pairing operation, the octet length of points and scalars, the hash to curve related operations and parameters as well as the base point of the G1 subgroup), the serialization operations (mapping points from each elliptic curve to an octet string and vice versa) and the generator parameters. See below for more details. Basic parameters:

hash: a cryptographic hash function.
octet_scalar_length: Number of bytes to represent a scalar value, in the multiplicative group of integers mod r, encoded as an octet string. It is RECOMMENDED this value be set to ceil(log2(r)/8).
octet_point_length: Number of bytes to represent a point encoded as an octet string outputted by the point_to_octets_E* function.
hash_to_curve_suite: The hash-to-curve ciphersuite id, in the form defined in . This defines the hash_to_curve_g1 (the hash_to_curve operation for the G1 subgroup, see the Notation defined in ) and the expand_message (either expand_message_xmd or expand_message_xof) operations used in this document.
expand_len: Must be defined to be at least ceil((ceil(log2(r))+k)/8), where log2(r) and k are defined by each ciphersuite (see Section 5 in for a more detailed explanation of this definition).
P1: A fixed point in the G1 subgroup, different from the point BP1 (i.e., the base point of G1, see ). This leaves the base point "free", to be used with other protocols, like key commitment and proof of possession schemes (for example, like the one described in Section 3.3 of ).
h: The pairing operation used.

Serialization functions:

point_to_octets_E1: a function that returns the canonical representation of the point P of the E1 elliptic curve as an octet string.
point_to_octets_E2: a function that returns the canonical representation of the point P of the E2 elliptic curve as an octet string.
octets_to_point_E1: a function that returns the point P in the elliptic curve E1 corresponding to the canonical representation ostr, or INVALID if ostr is not a valid output of point_to_octets_E1.
octets_to_point_E2: a function that returns the point P in the elliptic curve E2 corresponding to the canonical representation ostr, or INVALID if ostr is not a valid output of point_to_octets_E2.

BLS12-381 Ciphersuites The following two ciphersuites are based on the BLS12-381 elliptic curves defined in Section 4.2.1 of . The targeted security level of both suites in bits is k = 128 (the actual security level is closer to 126 bits). The number of bits of the order r, of the G1 and G2 subgroups, is log2(r) = 255. The base points BP1 and BP2 of G1 and G2 are the points BP and BP' correspondingly, as defined in Section 4.2.1 of . For completeness, BLS12-381 and the relevant functionality (base points BP1 and BP2, the pairing h as well as the point encoding and decoding operations) are defined in . The first ciphersuite uses the hash-to-curve suite BLS12381G1_XOF:SHAKE-256_SSWU_RO_, defined by this document in Appendix A.1, which is based on the SHAKE-256 extendable output function, as defined in Section 6.2 of . The second ciphersuite uses the hash-to-curve suite BLS12381G1_XMD:SHA-256_SSWU_RO_, defined in Section 8.8.1 of the document, which is based on the SHA-256, as defined in Section 6.2 of . For both ciphersuites defined in this section, the fixed point P1 of G1 is defined as the output of the create_generators procedure defined in instantiated with the parameters defined by each ciphersuite, with the inputs count = 1, not supplying an api_id value and making use of the following "Definitions" for the seed_dst, generator_dst and generator_seed variables; In the above, ciphersuite_id is the unique identifier defined by each ciphersuite. Note that the P1 point is independent from the BBS Interface that may use it and it remains constant for each ciphersuite. The similarity of the above "Definitions" with the Interface identifier (api_id) defined in , is only for compatibility reasons with previous versions of this document. Note that these two ciphersuites differ only in the hash-to-curve suites used. The hash-to-curve suites differ in the expand_message variant and underlying hash function. More concretely, the BLS12-381-SHAKE-256 ciphersuite makes use of expand_message_xof with SHAKE-256, while BLS12-381-SHA-256 makes use of expand_message_xmd with SHA-256. Curve parameters are common between the two ciphersuites.

BLS12-381-SHAKE-256 Basic parameters:

ciphersuite_id: "BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_"
octet_scalar_length: 32, based on the RECOMMENDED approach of ceil(log2(r)/8).
octet_point_length: 48, based on the RECOMMENDED approach of ceil(log2(p)/8).
hash_to_curve_suite: "BLS12381G1_XOF:SHAKE-256_SSWU_RO_" as defined in Appendix A.1 for the G1 subgroup.
expand_len: 48 ( = ceil((ceil(log2(r))+k)/8))
P1: the following point of G1, serialized using the point_to_octets_E1 procedure defined by this ciphersuite and hex encoded
h: the optimal Ate pairing (Appendix A.2 of ), defined in .

Serialization functions:

point_to_octets_E1: as defined in for points of the curve E1 (which follows the format documented in Appendix C.1 of for the E1 elliptic curve, using compression).
point_to_octets_E2: as defined in for points of the curve E2 (which follows the format documented in Appendix C.1 of for the E2 elliptic curve, using compression).
octets_to_point_E1: as defined in (which follows the format documented in Appendix C.2 of ), returning INVALID if the resulting point is not in E1.
octets_to_point_E2: as defined in (which follows the format documented in Appendix C.2 of ), returning INVALID if the resulting point is not in E2.

BLS12-381-SHA-256 Basic parameters:

Ciphersuite_ID: "BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_"
octet_scalar_length: 32, based on the RECOMMENDED approach of ceil(log2(r)/8).
octet_point_length: 48, based on the RECOMMENDED approach of ceil(log2(p)/8).
hash_to_curve_suite: "BLS12381G1_XMD:SHA-256_SSWU_RO_" as defined in Section 8.8.1 of the for the G1 subgroup.
expand_len: 48 ( = ceil((ceil(log2(r))+k)/8))
P1: the following point of G1, serialized using the point_to_octets_E1 procedure defined by this ciphersuite and hex encoded
h: the optimal Ate pairing (Appendix A.2 of ), defined in .

Serialization functions:

point_to_octets_E1: as defined in for points of the curve E1 (which follows the format documented in Appendix C.1 of for the E1 elliptic curve, using compression).
point_to_octets_E2: as defined in for points of the curve E2 (which follows the format documented in Appendix C.1 of for the E2 elliptic curve, using compression).
octets_to_point_E1: as defined in (which follows the format documented in Appendix C.2 of ), returning INVALID if the resulting point is not in E1.
octets_to_point_E2: as defined in (which follows the format documented in Appendix C.2 of ), returning INVALID if the resulting point is not in E2.

Test Vectors The following section details a basic set of test vectors that can be used to confirm an implementation's correctness. NOTE All binary data below is represented as octet strings in big endian order, encoded in hexadecimal format. NOTE These fixtures are a work in progress and subject to change.

Mocked Random Scalars For the purpose of presenting fixtures for the ProofGen operation (), we describe here a way to mock the calculate_random_scalars operation (), used by CoreProofGen () to create all the necessary random scalars. To that end, the seeded_random_scalars operation is defined, which will deterministically calculate count random-looking scalars from a single SEED, given a domain separation tag (DST). The proof test vector will then define a SEED (as a nothing-up-my-sleeve value) and a DST and then set The mocked_calculate_random_scalars operation will be used in place of calculate_random_scalars during the CoreProofGen operation. Note For the BLS12-381-SHA-256 ciphersuite (), if more than 170 mocked random scalars are required, the operation will return INVALID. Similarly, for the BLS12-381-SHAKE-256 ciphersuite (), if more than 1365 mocked random scalars are required, the operation will return INVALID. For the purpose of describing ProofGen () test vectors, those limits are inconsequential. 65535 Procedure: 1. out_len = expand_len * count 2. v = expand_message(SEED, DST, out_len) 3. if v is INVALID, return INVALID 4. for i in (1, ..., count): 5. start_idx = (i-1) * expand_len 6. end_idx = i * expand_len - 1 7. r_i = OS2IP(v[start_idx..end_idx]) mod r 8. return (r_1, ...., r_count) ]]>

Messages The following messages are used by the test vectors of both ciphersuites (unless otherwise stated). All the listed messages represent hex-encoded octet strings.

BLS12-381-SHAKE-256 Test Vectors Test vectors of the BLS12-381-SHAKE-256 ciphersuite defined in ciphersuite. Further fixtures are available in .

Key Pair Following the procedure defined in with an input key_material value as follows the following key_info value and the following key_dst value, defined by api_id || KEYGEN_DST_, where api_id the identifier of the BBS Interface defined in , using the BLS12-381-SHAKE-256 ciphersuite defined in , meaning that api_id = BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_H2G_HM2S_, Outputs the following SK value Following the procedure defined in with an input SK value as above produces the following PK value

Map Messages to Scalars The messages in are mapped to scalars during the Sign, Verify, ProofGen and ProofVerify operations. Presented below, are the output scalar values of the messages_to_scalars operation (), on input the messages defined in and the api_id defined in , using the BLS12-381-SHAKE-256 ciphersuite defined in , meaning that api_id = BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_H2G_HM2S_. Each output scalar value is encoded to octets using I2OSP and represented in big endian order,

Message Generators Following the procedure defined in for the BLS12-381-SHAKE-256 suite, with an input count value of 11 and an api_id value of api_id = BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_H2G_HM2S_ (as defined in for the BLS12-381-SHAKE-256 ciphersuite), outputs the following values (note that the first one corresponds to Q_1, while the next 10, to the message generators H_1, ..., H_10).

Signature Fixtures This section presents test vectors for the Sign operation, as defined in , for the BLS12-381-SHAKE-256 ciphersuite ().

Valid Single Message Signature

Valid Multi-Message Signature

Proof Fixtures This section presents test vectors for the ProofGen operation, as defined in , for the BLS12-381-SHAKE-256 ciphersuite (). For the generation of the following test vectors, the mocked_calculate_random_scalars defined in is used, in place of the calculate_random_scalars operation, with the following SEED value (hex encoding of the ASCII-encoded 30 first digits of pi) and the domain separation tag DST = api_id || "MOCK_RANDOM_SCALARS_DST_", where api_id is the identifier of the BBS Interface defined in , i.e., api_id = ciphersuite_id || H2G_HM2S_, where ciphersuite_id is the unique identifier of the BLS12-381-SHAKE-256 ciphersuite as defined in and "MOCK_RANDOM_SCALARS_DST_" is an ASCII string composed of 24 bytes. More specifically, Given the above SEED and DST values, the first 10 scalars (i.e., with count = 10) returned by the mocked_calculate_random_scalars operation will be,

Valid Single Message Proof

Valid Multi-Message, All Messages Disclosed Proof

Valid Multi-Message, Some Messages Disclosed Proof

BLS12381-SHA-256 Test Vectors Test vectors of the BLS12-381-SHA-256 ciphersuite. Further fixtures are available in .

Key Pair Following the procedure defined in with an input key_material value as follows the following key_info value and the following key_dst value, defined by api_id || KEYGEN_DST_, where api_id the identifier of the BBS Interface defined in , using the BLS12-381-SHA-256 ciphersuite defined in , meaning that api_id = BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_H2G_HM2S_, Outputs the following SK value Following the procedure defined in with an input SK value as above produces the following PK value

Map Messages to Scalars The messages in are mapped to scalars during the Sign, Verify, ProofGen and ProofVerify operations. Presented below, are the output scalar values of the messages_to_scalars operation (), on input the messages defined in and the api_id defined in , using the BLS12-381-SHA-256 ciphersuite defined in , meaning that api_id = BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_H2G_HM2S_. Each output scalar value is encoded to octets using I2OSP and represented in big endian order, The output scalars, encoded to octets using I2OSP and represented in big endian order, are the following,

Message Generators Following the procedure defined in for the BLS12-381-SHA-256 suite, with an input count value of 11 and an api_id value of api_id = BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_H2G_HM2S_ (as defined in for the BLS12-381-SHA-256 ciphersuite), outputs the following values (note that the first one corresponds to Q_1, while the next 10, to the message generators H_1, ..., H_10).

Signature Fixtures This section presents test vectors for the Sign operation, as defined in , for the BLS12-381-SHA-256 ciphersuite ().

Valid Single Message Signature

Valid Multi-Message Signature

Proof Fixtures This section presents test vectors for the ProofGen operation, as defined in , for the BLS12-381-SHA-256 ciphersuite (). For the generation of the following test vectors, the mocked_calculate_random_scalars defined in is used, in place of the calculate_random_scalars operation, with the following SEED value (hex encoding of the ASCII-encoded 30 first digits of pi) and the domain separation tag DST = api_id || "MOCK_RANDOM_SCALARS_DST_", where api_id is the identifier of the BBS Interface defined in , i.e., api_id = ciphersuite_id || H2G_HM2S_, where ciphersuite_id is the unique identifier of the BLS12-381-SHA-256 ciphersuite as defined in and "MOCK_RANDOM_SCALARS_DST_" is an ASCII string composed of 24 bytes. More specifically, Given the above SEED and DST values, the first 10 scalars (i.e., with count = 10) returned by the mocked_calculate_random_scalars operation will be, Note that the returned scalars will be unique for different count values, i.e., for different output lengths.

Valid Single Message Proof

Valid Multi-Message, All Messages Disclosed Proof

Valid Multi-Message, Some Messages Disclosed Proof

IANA Considerations This document does not make any requests of IANA.

Acknowledgements The authors would like to acknowledge the significant amount of academic work that preceded the development of this document. In particular the original work of which was subsequently developed in and in . This last academic work is the one mostly used by this document. The current state of this document is the product of the work of the Decentralized Identity Foundation Applied Cryptography Working group, which includes numerous active participants. In particular, the following individuals contributed ideas, feedback and wording that influenced this specification: Orie Steele, Christian Paquin, Alessandro Guggino, Tomislav Markovski and Greg Bernstein. Additionally, the authors would like to acknowledge Jacques Traore and Antoine Dumanois, for their crucial contributions to this document.

References Normative References Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST Secure Hash Standard (SHS) NIST SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions NIST Informative References On the Security of Joint Signature and Encryption SoftMax Inc. New York University IBM T.J. Watson Research Center Constant-Size Dynamic k-TAA Bulletproofs: Short Proofs for Confidential Transactions and More Stanford University University College London Stanford University Blockstream Blockstream Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials Orange Labs Orange Labs Orange Labs Orange Labs Short Group Signatures Faster subgroup checks for BLS12-381 Electric Coin Company Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited IBM Research Department of Computer Science, ETH Zurich IBM Research Signature Schemes and Anonymous Credentials from Bilinear Maps Tor: The Second-Generation Onion Router The Free Haven Projecth The Free Haven Projecth Naval Research Lab Mining your Ps and Qs: Detection of widespread weak keys in network devices University of California, San Diego The University of Michigan The University of Michigan The University of Michigan Date and time - Representations for information interchange - Part 1: Basic rules ISO Revisiting BBS Signatures University of Washington University of Washington U-Prove Cryptographic Specification V1.1 Revision 5 Microsoft Research Dynamic universal accumulator with batch update over bilinear groups University of Luxembourg University of Luxembourg Zcash Overwinter Consensus and Sapling Cryptography Review NCC Group

BLS12-381 hash_to_curve Definition Using SHAKE-256 The following defines a hash_to_curve suite for the BLS12-381 curve for both the G1 and G2 subgroups using the extendable output function (xof) of SHAKE-256 as per the guidance defined in section 8.9 of . Note the notation used in the below definitions is sourced from .

BLS12-381 G1 The suite of BLS12381G1_XOF:SHAKE-256_SSWU_RO_ is defined as follows: Note that the h_eff values for this suite are copied from that defined for the BLS12381G1_XMD:SHA-256_SSWU_RO_ suite defined in section 8.8.1 of . An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to BLS12-381 G1 is given in Appendix F.2 .

The BLS12-381 Curve This section defines BLS12-381. The definitions of this section have been originally described in , where they are discussed in greater detail. BLS12-381 are Barreto-Lynn-Scott curves, defined by two elliptic curves E1 and E2, parameterized by an integer t. In the case of BLS12-381, t is defined as, The curves E1 and E2 are defined over the finite fields GF(p) and GF(p^2) correspondingly, where p is defined as, Let (1, I) be the bases of the finite field GF(p^2), where I ^ 2 + 1 = 0 in GF(p^2). We will denote an element y of GF(p^2) as a tuple y = (y_0, y_1), where y_0 and y_1 elements of GF(p) for which it holds y = y_0 * 1 + y_1 * I. The two elliptic curves are defined by the following equations, The group G1 and G2 are defined as the the order r subgroup of E1 defined over GF(p) and E2 defined over GF(p^2) correspondingly, where r is defined as, Note that r is a prime factor of p. The target group G_T is defined as the finite group GF(p^12) minus the element 0. The base points of BLS12-381, encoded to octets using the procedure defined in and then represented in hexadecimal format, are defined as,

Optimal Ate pairing This section describes the optimal Ate pairing for BLS12-381. The pairing computation uses the following utility function. Let c = t for t as defined above () and c_0, c_1, ... , c_L in (-1, 0, 1) such that the sum of c_i * 2^i for i = 0, 1, ..., L equals c. Given a point P of G1, and a point Q of G2, the output h(P, Q) where h the Ate pairing for BLS12-381 is calculated as follows,

Point Encoding This section defines point encoding and decoding procedures for BLS12-381. Although more flexible point encoding procedures may exist (for example ), the vast majority of current libraries implementing BLS12-381 use (most of them explicitly) the encoding method defined in Appendix C of . For this reason, the ciphersuites defined in , use those encoding and decoding procedures. For completeness, those operations are defined in this section as well. See for a more detailed explanation of the encoding and decoding steps. Note also that we will only consider compressed point encoding (in contrast to , which supports both compressed and uncompressed point encoding). In this section we will use the following notation,

For an octet string x, x[0] will denote the first octet (i.e., 8 most significant bits) of x.
On input an element y of GF(p) or GF(p^2), sqrt(y) will return the square root of that element in the respective group, i.e., an element a such that a^2 = y, or INVALID.
For clarity, we will use Identity_E1, Identity_E2 to denote the identity points of E1 and E2 correspondingly (note that Identity_E1 is the same point as Identity_G1 and Identity_E2 is the same point as Identity_G2).

We first have to define the following utility operations. The following procedure returns one bit corresponding to the sign of an element of GF(p). (p - 1) / 2, return 1 2. return 0 ]]> The following procedure returns one bit corresponding to the sign of an element in GF(p^2). (p - 1) / 2, return 1 4. return 0 ]]>

Point Serialization Let P = (x, y) the point to be serialized. Compute three metadata bits C_bit, I_bit, and S_bit, as follows,

C_bit is set to 1 (indicating that point compression is used).
I_bit is 1 if P is either the Identity_E1 or Identity_E2 points, otherwise it is 0.
S_bit is 0 if I_bit is 1 (again note that the ciphersuites described in this document always use point compression). Otherwise (i.e., when point compression is used and P is not the identity point of its respective curve), if P is a point on E1, set S_bit = sign_GF_p(y), else if P is a point on E2, S_bit = sign_GF_p^2(y).

Let m = (C_bit * 2^7) + (I_bit * 2^6) + (S_bit * 2^5) and set m_byte = I2OSP(m, 1). Define x_string as follows,

If P = Identity_E1, set x_string = I2OSP(0, 48).
If P is a point on E1 and P != Identity_E1, set x_string = I2OSP(x, 48).
If P = Identity_E2, set x_string = I2OSP(0, 96).
If P is a point on E2 and P != Identity_E2, then let x_0 and x_1 elements of GF(p) such that x = (x_0, x_1) and set x_string = I2OSP(x_1, 48) || I2OSP(x_0, 48).

Let s_string = x_string. Set s_string[0] = x_string[0] OR m_byte, where OR is computed for each bit. Output s_string as the serialization result of the point P.

Point De-serialization Let m_byte = s_string[0] AND 0xE0, where AND is computed bitwise. If m_byte equals 0x20 or 0x60 or 0xE0, output INVALID and abort the operation. Otherwise, let C_bit equal the most significant bit of m_byte, I_bit equal the second most significant bit of m_byte, and S_bit equal the third most significant bit of m_byte. If C_bit is 0 return INVALID and abort the operation (note again that we only consider compressed encoding).

Determine the curve of the encoded point as follows,
- If s_string has length 48 octets, the encoded point is on the curve E1.
- If s_string has length 96 octets, the encoded point is on the curve E2.
- If s_string has any other length, output INVALID and abort the operation.
Let s_string[0] = s_string[0] AND 0x1F, where AND is computed bitwise (this will set the three most significant bits of s_string[0] to 0).
If I_bit is 1, then the encoded point must be the Identity point of the curve determined on step 1. If s_string is not the all zeros string, output INVALID and abort the operation. Otherwise, output the Identity point of the curve that was determined in step 1 (i.e., either Identity_E1 or Identity_E2).
Let x = OS2IP(s_string).
If the curve that was determined in step 1 is E1,
- Let y2 = x^3 + 4 in GF(p).
- If y2 is not square in GF(p), output INVALID and abort the operation. Otherwise, let y = sqrt(y2) in GF(p) and set Y_bit = sign_GF_p(y).
If the curve that was determined in step 1 is E2,
- Let y2 = x^3 + 4 * (I + 1) in GF(p^2).
- If y2 is not square in GF(p^2), output INVALID and abort the operation. Otherwise, let y = sqrt(y2) in GF(p^2) and set Y_bit = sign_GF_p^2(y).
If S_bit equals Y_bit, output P = (x, y). Otherwise, output P = (x, -y).

Use Cases

Non-correlating Security Token In the most general sense BBS signatures can be used in any application where a cryptographically secured token is required but correlation caused by usage of the token is un-desirable. For example in protocols like OAuth2.0 the most commonly used form of the access token leverages the JWT format alongside conventional cryptographic primitives such as traditional digital signatures or HMACs. These access tokens are then used by a relying party to prove authority to a resource server during a request. However, because the access token is most commonly sent by value as it was issued by the authorization server (e.g., in a bearer style scheme), the access token can act as a source of strong correlation for the relying party. Relevant prior art can be found here. BBS Signatures due to their unique properties removes this source of correlation but maintains the same set of guarantees required by a resource server to validate an access token back to its relevant authority (note that an approach to signing JSON tokens with BBS that may be of relevance is the JSON Web Proofs (JWP) format and serialization described in ). In the context of a protocol like OAuth2.0 the access token issued by the authorization server would feature a BBS Signature, however instead of the relying party providing this access token as issued, in their request to a resource server, they generate a unique proof from the original access token and include that in the request instead, thus removing this vector of correlation.

Improved Bearer Security Token Bearer based security tokens such as JWT based access tokens used in the OAuth2.0 protocol are a highly popular format for expressing authorization grants. However their usage has several security limitations. Notably a bearer based authorization scheme often has to rely on a secure transport between the authorized party (client) and the resource server to mitigate the potential for a MITM attack or a malicious interception of the access token. The scheme also has to assume a degree of trust in the resource server it is presenting an access token to, particularly when the access token grants more than just access to the target resource server, because in a bearer based authorization scheme, anyone who possesses the access token has authority to what it grants. Bearer based access tokens also suffer from the threat of replay attacks. Improved schemes around authorization protocols often involve adding a layer of proof of cryptographic key possession to the presentation of an access token, which mitigates the deficiencies highlighted above as well as providing a way to detect a replay attack. However, approaches that involve proof of cryptographic key possession such as DPoP (), suffer from an increase in protocol complexity. A party requesting authorization must pre-generate appropriate key material, share the public portion of this with the authorization server alongside proving possession of the private portion of the key material. The authorization server must also be-able to accommodate receiving this information and validating it. BBS Signatures offer an alternative model that solves the same problems that proof of cryptographic key possession schemes do for bearer based schemes, but in a way that doesn't introduce new up-front protocol complexity. In the context of a protocol like OAuth2.0 the access token issued by the authorization server would feature a BBS Signature, however instead of the client providing this access token as issued, in their request to a resource server, they generate a unique proof from the original access token and include that in the request instead. Because the access token is not shared in a request to a resource server, attacks such as MITM are mitigated. A resource server also obtains the ability to detect a replay attack by ensuring the proof presented is unique.

Selectively Disclosure Enabled Identity Credentials BBS signatures when applied to the problem space of identity credentials can help to enhance user privacy. For example a digital drivers license that is cryptographically signed with a BBS signature, allows the holder or subject of the license (acting as the Prover of the BBS scheme) to disclose different claims from their drivers license to different parties. Furthermore, the unlinkable presentations property of proofs generated by the scheme remove an important possible source of correlation for the holder across multiple presentations.

Additional Test Vectors

BLS12-381-SHAKE-256 Ciphersuite

Signature Test Vectors

No Header Valid Signature

Modified Message Signature The following fixture should fail signature validation due to the message value being different from what was signed.

Extra Unsigned Message Signature The following fixture should fail signature validation due to an additional message being supplied that was not signed.

Missing Message Signature The following fixture should fail signature validation due to missing messages that were originally present during the signing (the presented signature was generated with all the messages in as input).

Reordered Message Signature The following fixture should fail signature validation due to messages being re-ordered from the order in which they were signed.

Wrong Public Key Signature The following fixture should fail signature validation due to public key used to verify is in-correct.

Wrong Header Signature The following fixture should fail signature validation due to header value being modified from what was originally signed.

Proof Test Vectors

No Header Valid Proof

No Presentation Header Valid Proof

Hash to Scalar Test Vectors Using the following input message, And following dst value, We get the following scalar output from hash_to_scalar (), encoded with I2OSP and represented in big endian order,

BLS12-381-SHA-256 Ciphersuite

Signature Test Vectors

No Header Valid Signature

Modified Message Signature The following fixture should fail signature validation due to the message value being different from what was signed.

Extra Unsigned Message Signature The following fixture should fail signature validation due to an additional message being supplied that was not signed.

Reordered Message Signature The following fixture should fail signature validation due to messages being re-ordered from the order in which they were signed.

Wrong Public Key Signature The following fixture should fail signature validation due to public key used to verify is in-correct.

Wrong Header Signature The following fixture should fail signature validation due to header value being modified from what was originally signed.

Proof Test Vectors

No Header Valid Proof

No Presentation Header Valid Proof

Proof Generation and Verification Algorithmic Explanation The following section provides a high-level explanation of how the CoreProofGen and CoreProofVerify operations work, as presented in Appendix B of and used by this document. The CoreProofGen procedure uses a generic non-interactive zero-knowledge proof-of-knowledge (NIZK) protocol, executed between a Prover and a Verifier. A NIZK works as follows; Assume the group points J_0, J_1, ..., J_n and the exponents e_0, e_1, ..., e_n. Assume also that all the group points are publicly known, while only the exponent e_0 is known to the Verifier of the NIZK and the exponents e_1, ..., e_n are known only by the Prover of the protocol. The NIZK can be used to prove a relationship of the form, While revealing nothing about the secret exponents (i.e., e_1, ..., e_n), other than the fact that the Prover knows them. For BBS, let the Prover be in possession of a BBS signature (A, e) on messages msg_1, ..., msg_L and a domain value (see CoreSign defined in ). Let A = B * (1/(e + SK)) where SK the Signer's secret key and, Let (i1, ..., iR) be the indexes of the messages the Prover wants to disclose and (j1, ..., jU) be the indexes corresponding to undisclosed messages (i.e., (j1, ..., jU) = (1, 2, ..., L) \ (i1, ..., iR)). To prove knowledge of a signature on the disclosed messages, work as follows;

Prove possession of a valid signature. As defined above, a signature (A, e), on messages msg_1, ..., msg_L is valid if A = B * 1/(e + SK), where B as in [1]. However, the Prover cannot reveal neither A, e nor B to the Verifier (signature is uniquely identifiable and B will reveal information about the signed messages, even the undisclosed ones). To get around this, the Prover needs to hide the signature (A, e) and the value of B, in a way that will allow proving knowledge of such elements with the aforementioned relationship (i.e., that A = B * 1/(e + SK)), without revealing their value. The Prover will do this by randomizing them. To do that, they take uniformly random r1, r2 in [1, r-1], and calculate, The values (Abar, D, Bbar) will be part of the proof and are used to prove possession of a BBS signature, without revealing the signature itself. Note that; if Abar and Bbar are constructed using a valid BBS signature as above, then Abar * SK = Bbar which is equivalent to h(Abar, PK) = h(Bbar, BP2), where SK, PK the Signer's secret and public key and BP2 the base generator of G2 (used to create the Signer’s PK, see ). This last equation is something that the Verifier can check using the Signer's PK.
Prove that the disclosed messages are signed as part of that signature. The Prover will start by setting the following, If the Abar, D and Bbar values are constructed using a valid BBS signature as in [2], [3] and [4], then the following will hold,

Note that the Verifier will know the elements in the left side of [6] (i.e., P1, Q_1, H_i1, ..., H_iR and the disclosed messages: msg_i1, ..., msg_iR) as well as the base points of the right side (i.e., the points D and H_j1, ..., H_jU). They will not however know the exponents on the right side of [6] (i.e., r2' and the undisclosed messages: msg_j1, ..., msg_jU). The same holds for equation [4] where the Verifier will know the left side of the equation (i.e., Bbar) and the base points of the right side (i.e., D and Abar) but not the exponents (i.e., r1 and -e). To convince the Verifier that both [4] and [6] hold, the Prover can use a NIZK, to prove that they know the exponents that satisfy those equations, without disclosing them. Note that if the value D is constructed correctly (as in [3]), then B = D * r2'. Proving knowledge of [6] corresponds to proving knowledge of r2', which means that the Prover does actually know a value B = D * r2'. If [6] holds, then that B value that the Prover knows (i.e., D * r2') will also have the "correct form" for B (as in [1]), including all (the disclosed and "some" undisclosed) messages. All that remains is proving that this B value the Prover knows, is also "signed" by the Signer i.e., that the Prover also knows values A and e, such that A = B * 1/(e + SK) or, equivalently, that h(A, PK + BP2 * e) = h(B, BP2), which is what CoreVerify checks to validate a signature (see ). Note that, the Prover will use a NIZK to showcase (among other things), knowledge of values r1 and e so that [4] holds (Bbar, D and Abar will be part of the proof and hence known to the Verifier). Setting r1' = (1 / r1) mod r (note that proving knowledge of r1 indirectly proves knowledge of r1' as well), using [4] and the fact that h(Abar, PK) = h(Bbar, BP2) we can get that, Note that the above is what CoreVerify checks, for A = Abar * r1' * r2'. Since the Prover showcased knowledge of r1' and r2' and revealed Abar as part of the proof, the Verifier can be assured that the Prover knows the value A = Abar * r1' * r2'. So setting A = Abar * r1' * r2', the values A, e, B that the Prover showed knowledge of, will form a valid BBS signature. Note that the Verifier doesn't know A (since they don't know r1' and r2'), e or B (since they don't know r2' or the undisclosed messages). However, they know that the prover knows them and as we saw above, these values form a valid signature on (among others) the disclosed messages. To sum up; in order to validate the proof, a Verifier checks that h(Abar, PK) = h(Bbar, BP2) and verifies the NIZK. Validating the proof will guarantee the authenticity and integrity of the disclosed messages, as well as knowledge of the undisclosed messages and of the signature.

Document History -00

Initial version

-01

Populated fixtures
Added SHA-256 based ciphersuite
Fixed typo in ProofVerify
Clarify ASCII string usage in DST
Added MapMessageToScalar test vectors
Fix typo in ciphersuite name

-02

Variety of editiorial clarifications
Clarified integer endianness
Revised the encode for hash operation
Shifted to using CSPRNG instead of PRF
Removed total number of messages from proof verify operation
Added deterministic proof fixtures
Shifted to multiple CSPRNG calls to calculate random elements, instead of expand_message
Updated hash_to_scalar to a single output

-03

Updated core operation based on new academic paper
Variety of editorial updates
Updated exception and error handling
Added extension point for the operation with which the generators are created, allowing ciphersuites to define different operations for creating the generator points.
Added extension point for the operation with which the input messages are mapped to scalar values, allowing ciphersuites to define different message-to-scalar mapping operations
Added signature/proof fixtures with an empty header or an empty presentation header input
Updated the fixtures to use variable length messages (one of which is now the empty message "")

-04

Restructure Proof Generation and Verification operation to different subroutines.
Separate high-level (Interface) operations from low-level (Core) operations.
Update the ciphersuite ID to remove from it the create_generators and map_message_to_scalar IDs, since those are defined as part of the high-level interface instead of the ciphersuite.
Add a commitment optional value to the CoreSign operation. The commitment value is added to allow using BBS as part of other protocols but is ignored in this document.
Update test-vectors display.

-05

Proof Generation and Verification operations updated based on Appendix B of .
Test vectors updated based on the new proof generation procedure.
Removed the optional commitment value from the CoreSign operation, as the intended use case (blind signatures) will be addressed differently and in another document.
Changed the reference to from Normative to Informative, by re-defining the relevant functionality to this document.
Various editorial updates.

-06

To support bounded memory implementations, the order of the inputs to the digest operation for the calculation of the e value during CoreSign and the challenge value during CoreProofGen and CoreProofVerify was updated.
Updated the test vectores to match the above update.
Renamed the pairing function from e to h, to avoid naming collisions with the scalar component of the signature.
Renamed signature_dst, challenge_dst and domain_dst to hash_to_scalar_dst.

-07

Editorial fixes (nizk -> NIZK, clarified scalar multiplication in Notation Section).
Removed "subject to change" warning on additional test vectors.
Fixed proof deserialization error.
Fixed order of inputs in CoreSign call.
Fixed wrong inputs in calculate_domain call in CoreSign and CoreVerify.