The BBS Signature Scheme

1.1. 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 Section 1.2).¶

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 [RFC8017]. 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 [RFC8017]. 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.¶

1.2. 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 [I-D.irtf-cfrg-pairing-friendly-curves].¶

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 [RFC9380] 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., [Bowe19]. Note that these functions should always return VALID, on input the Identity point of the corresponding subgroup.¶

1.3. Document Organization

This document is organized as follows:¶

• Scheme Definition (Section 3), defines the core operations and parameters for the BBS signature scheme.¶

• Utility Operations (Section 4), defines utilities used by the BBS signature scheme.¶

• Security Considerations (Section 6), describes a set of security considerations associated to the signature scheme.¶

• Ciphersuites (Section 7), defines the format of a ciphersuite, alongside a concrete ciphersuite based on the BLS12-381 curve.¶

3.1. Parameters

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

• A pairing-friendly elliptic curve, plus associated functionality given in Section 1.2.¶

• A hash-to-curve suite as defined in [RFC9380], 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 [RFC4086] for recommendations and requirements on the generation of random numbers.¶

3.2. 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 Section 3.6) expects a list of points (called the generators, see Section 3.3.2) and a list of messages represented as scalar values (see Section 3.3.3). It is the job of the Interface to:¶

1. Create the necessary generators.¶
2. 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 (Section 3.6) and utility (Section 4.1) 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 Section 3.8.¶

3.3. Considerations

[a_1, a_2, ..., a_n] = X

X[0] = a_1
X[1] = a_2
// ... and so on, up to
X[n-1] = a_n

3.4. Key Generation Operations

SK = KeyGen(key_material, key_info, key_dst)

Inputs:

- key_material (REQUIRED), a secret octet string. See requirements
                           above.
- key_info (OPTIONAL), an octet string. Defaults to an empty string if
                       not supplied.
- key_dst (OPTIONAL), an octet string representing the domain separation
                      tag. Defaults to the octet string
                      ciphersuite_id || "KEYGEN_DST_" if not supplied.

Outputs:

- SK, a uniformly random integer such that 0 < SK < r.

Procedure:

1. if length(key_material) < 32, return INVALID
2. if length(key_info) > 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

PK = SkToPk(SK)

Inputs:

- SK (REQUIRED), a secret integer such that 0 < SK < r.

Outputs:

- PK, a public key encoded as an octet string.

Procedure:

1. W = SK * BP2
2. return point_to_octets_E2(W)

3.5. BBS Signatures Interface

This section defines a BBS Signatures Interface (see Section 3.2), that makes use of the core operations defined in Section 3.6, to perform the functions of signing and verifying the signature, as well as generating and validating the BBS proof. To create the generators (see Section 3.3.2) it uses the create_generators operation defined in Section 4.1.1. Each input message is an octet string (see Section 3.3.3). To map the messages to scalars, it uses the messages_to_scalars operation defined in Section 4.1.2. 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 Section 3.3.6 for more details on the header and presentation_header usage.¶

The api_id parameter for this Interface is defined as,¶

api_id = ciphersuite_id || "H2G_HM2S_"

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 Section 4.1.1) and "HM2S_" is the identifier of the used messages_to_scalars mapping (see Section 4.1.2).¶

signature = Sign(SK, PK, header, messages)

Inputs:

- SK (REQUIRED), a secret key in the form outputted by the KeyGen
                 operation.
- PK (REQUIRED), an octet string of the form outputted by SkToPk
                 provided the above SK as input.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to the empty octet string ("").
- messages (OPTIONAL), a vector of octet strings. If not supplied, it
                       defaults to the empty array ("()").

Parameters:

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

Outputs:

- signature, a signature encoded as an octet string; or INVALID.

Procedure:

1. message_scalars = messages_to_scalars(messages, api_id)
2. generators = create_generators(length(messages)+1, api_id)

3. signature = CoreSign(SK, PK, generators, header, message_scalars,
                                                                 api_id)
4. if signature is INVALID, return INVALID
5. return signature

result = Verify(PK, signature, header, messages)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), an octet string of the form outputted by the
                        Sign operation.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to the empty octet string ("").
- messages (OPTIONAL), a vector of octet strings. If not supplied, it
                       defaults to the empty array ("()").

Parameters:

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

Outputs:

- result, either VALID or INVALID.

Procedure:

1. message_scalars = messages_to_scalars(messages, api_id)
2. generators = create_generators(length(messages)+1, api_id)

3. result = CoreVerify(PK, signature, generators, header,
                                         message_scalars, api_id)
4. return result

proof = ProofGen(PK, signature, header, ph, messages, disclosed_indexes)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), an octet string of the form outputted by the
                        Sign operation.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to the empty octet string ("").
- ph (OPTIONAL), an octet string containing the presentation_header. If
                 not supplied, it defaults to the empty octet
                 string ("").
- messages (OPTIONAL), a vector of octet strings. If not supplied, it
                       defaults to the empty array ("()").
- disclosed_indexes (OPTIONAL), vector of unsigned integers in ascending
                                order. Indexes of disclosed messages. If
                                not supplied, it defaults to the empty
                                array ("()").

Parameters:

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

Outputs:

- proof, an octet string; or INVALID.

Procedure:

1. message_scalars = messages_to_scalars(messages, api_id)
2. generators = create_generators(length(messages) + 1, api_id)

3. proof = CoreProofGen(PK, signature, generators, header, ph,
                             message_scalars, disclosed_indexes, api_id)
4. if proof is INVALID, return INVALID
5. return proof

result = ProofVerify(PK, proof, header, ph,
                     disclosed_messages,
                     disclosed_indexes)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- proof (REQUIRED), an octet string of the form outputted by the
                    ProofGen operation.
- header (OPTIONAL), an optional octet string containing context and
                     application specific information. If not supplied,
                     it defaults to the empty octet string ("").
- ph (OPTIONAL), an octet string containing the presentation_header. If
                 not supplied, it defaults to the empty octet
                 string ("").
- disclosed_messages (OPTIONAL), a vector of octet strings. If not
                                 supplied, it defaults to the empty
                                 array ("()").
- disclosed_indexes (OPTIONAL), vector of unsigned integers in ascending
                                order. Indexes of disclosed messages. If
                                not supplied, it defaults to the empty
                                array ("()").

Parameters:

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

Outputs:

- result, either VALID or INVALID.

Deserialization:

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

Procedure:

1. message_scalars = messages_to_scalars(disclosed_messages, api_id)
2. generators = create_generators(U + R + 1, api_id)

3. result = CoreProofVerify(PK, proof, generators, header, ph,
                             message_scalars, disclosed_indexes, api_id)
4. return result

3.6. 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 Section 3.8.¶

The operations of this section make use of functions and sub-routines defined in Utility Operations. More specifically,¶

• hash_to_scalar is defined in Section 4.2.2¶
• calculate_domain is defined in Section 4.2.3.¶
• serialize, signature_to_octets, octets_to_signature, proof_to_octets, octets_to_proof and octets_to_pubkey are defined in Section 4.2.4.¶
• h is the pairing operation used (see Section 1.2), 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 Section 4.1.1.1 for more details. Each message is represented as a scalar value. See Section 4.1.2 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.¶

signature = CoreSign(SK, PK, generators, header, messages, api_id)

Inputs:

- SK (REQUIRED), a secret key in the form outputted by the KeyGen
                 operation.
- PK (REQUIRED), an octet string of the form outputted by SkToPk
                 provided the above SK as input.
- generators (REQUIRED), vector of pseudo-random points in G1.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to the empty octet string ("").
- messages (OPTIONAL), a vector of scalars representing the messages.
                       If not supplied, it defaults to the empty
                       array ("()").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

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

Outputs:

- signature, a vector comprised of a point of G1 and a scalar.

Definitions:

1. hash_to_scalar_dst, an octet string representing the domain
                       separation tag: api_id || "H2S_" where "H2S_" is
                       an ASCII string comprised of 4 bytes.

Deserialization:

1. L = length(messages)
2. if length(generators) != L + 1, return INVALID
3. (msg_1, ..., msg_L) = messages
4. (Q_1, H_1, ..., H_L) = generators

Procedure:

1. domain = calculate_domain(PK, Q_1, (H_1, ..., H_L), header, api_id)

2. e = hash_to_scalar(serialize((SK, msg_1, ..., msg_L, domain)),
                                                     hash_to_scalar_dst)
3. B = P1 + Q_1 * domain + H_1 * msg_1 + ... + H_L * msg_L
4. A = B * (1 / (SK + e))
5. return signature_to_octets((A, e))

result = CoreVerify(PK, signature, generators, header, messages, api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), an octet string of the form outputted by the
                        Sign operation.
- generators (REQUIRED), vector of pseudo-random points in G1.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to the empty octet string ("").
- messages (OPTIONAL), a vector of scalars representing the messages.
                       If not supplied, it defaults to the empty
                       array ("()").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

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

Outputs:

- result, either VALID or INVALID.

Deserialization:

1. signature_result = octets_to_signature(signature)
2. if signature_result is INVALID, return INVALID
3. (A, e) = signature_result
4. W = octets_to_pubkey(PK)
5. if W is INVALID, return INVALID
6. L = length(messages)
7. if length(generators) != L + 1, return INVALID
8. (msg_1, ..., msg_L) = messages
9. (Q_1, H_1, ..., H_L) = generators

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. if h(A, W) * h(A * e - B, BP2) != Identity_GT, return INVALID
4. return VALID

proof = CoreProofGen(PK, signature, generators, header, ph, messages,
                                              disclosed_indexes, api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), an octet string of the form outputted by the
                        Sign operation.
- generators (REQUIRED), vector of pseudo-random points in G1.
- header (OPTIONAL), an octet string containing context and application
                     specific information. If not supplied, it defaults
                     to the empty octet string ("").
- ph (OPTIONAL), an octet string containing the presentation_header. If
                 not supplied, it defaults to the empty octet
                 string ("").
- messages (OPTIONAL), a vector of scalars representing the messages.
                       If not supplied, it defaults to the empty
                       array ("()").
- disclosed_indexes (OPTIONAL), vector of non-negative integers in
                                ascending order. Indexes of disclosed
                                messages. If not supplied, it defaults
                                to the empty array ("()").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Outputs:

- proof, an octet string; or INVALID.

Deserialization:

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

4.  L = length(messages)
5.  R = length(disclosed_indexes)
6.  if R > 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

result = CoreProofVerify(PK, proof, generators, header, ph,
                          disclosed_messages, disclosed_indexes, api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- proof (REQUIRED), an octet string of the form outputted by the
                    ProofGen operation.
- generators (REQUIRED), vector of pseudo-random points in G1.
- header (OPTIONAL), an optional octet string containing context and
                     application specific information. If not supplied,
                     it defaults to the empty octet string ("").
- ph (OPTIONAL), an octet string containing the presentation_header. If
                 not supplied, it defaults to the empty octet
                 string ("").
- disclosed_messages (OPTIONAL), a vector of scalars representing the
                                 messages. If not supplied, it defaults
                                 to the empty array ("()").
- disclosed_indexes (OPTIONAL), vector of non-negative integers in
                                ascending order. Indexes of disclosed
                                messages. If not supplied, it defaults
                                to the empty array ("()").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

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

Outputs:

- result, either VALID or INVALID.

Deserialization:

1. proof_result = octets_to_proof(proof)
2. if proof_result is INVALID, return INVALID
3. (Abar, Bbar, D, e^, r1^, r3^, commitments, cp) = proof_result
4. W = octets_to_pubkey(PK)
5. if W is INVALID, return INVALID

Procedure:

1. init_res = ProofVerifyInit(PK, proof_result, generators, header,
                                                disclosed_messages,
                                                disclosed_indexes,
                                                api_id)
2. if init_res is INVALID, return INVALID
3. challenge = ProofChallengeCalculate(init_res, disclosed_messages,
                                       disclosed_indexes, ph, api_id)
4. if challenge is INVALID, return INVALID
5. if cp != challenge, return INVALID
6. if h(Abar, W) * h(Bbar, -BP2) != Identity_GT, return INVALID
7. return VALID

3.7. Proof Protocol Subroutines

This section describes the subroutines used by the CoreProofGen (Section 3.6.3) and CoreProofVerify (Section 3.6.4) operations. See Appendix E, for a high-level intuitive overview of the procedure used to generate and verify a BBS proof.¶

init_res = ProofInit(PK, signature, generators, random_scalars,
                          header, messages, undisclosed_indexes, api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- signature (REQUIRED), vector representing a BBS signature, consisting
                        of a point of G1 and a scalar, in that order.
- generators (REQUIRED), vector of points in G1.
- random_scalars (REQUIRED), vector of scalar values.
- header (OPTIONAL), octet string. If not supplied it defaults to the
                     empty octet string ("").
- messages (OPTIONAL), vector of scalar values. If not supplied, it
                       defaults to the empty array ("()").
- undisclosed_indexes (OPTIONAL), vector of non-negative integers in
                                  ascending order. If not supplied, it
                                  defaults to the empty array ("()").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

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

Outputs:

- init_res, vector consisting of 5 points of G1 and a scalar, in that
            order; or INVALID.

Deserialization:

1.  (A, e) = signature
2.  L = length(messages)
3.  U = length(undisclosed_indexes)
4.  (j1, ..., jU) = undisclosed_indexes
5.  if length(random_scalars) != U + 5, return INVALID
6.  (r1, r2, e~, r1~, r3~, m~_j1, ..., m~_jU) = random_scalars
7.  (msg_1, ..., msg_L) = messages

8.  if length(generators) != L + 1, return INVALID
9.  (Q_1, MsgGenerators) = generators
10. (H_1, ..., H_L) = MsgGenerators
11. (H_j1, ..., H_jU) = (MsgGenerators[j1], ..., MsgGenerators[jU])

ABORT if:

1. for i in undisclosed_indexes, i < 0 or i > 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 = ProofFinalize(init_res, challenge, e_value, random_scalars,
                                                   undisclosed_messages)

Inputs:

- init_res (REQUIRED), vector representing the value returned after
                       initializing the proof generation or verification
                       operations, consisting of 5 points of G1 and a
                       scalar value, in that order.
- challenge (REQUIRED), scalar value.
- e_value (REQUIRED), scalar value.
- random_scalars (REQUIRED), vector of scalar values.
- undisclosed_messages (OPTIONAL), vector of scalar values. If not
                                   supplied, it defaults to the empty
                                   array ("()").

Outputs:

- proof, an octet string; or INVALID.

Deserialization:

1. U = length(undisclosed_messages)
2. if length(random_scalars) != U + 5, return INVALID
3. (r1, r2, e~, r1~, r3~, m~_j1, ..., m~_jU) = random_scalars
4. (undisclosed_1, ..., undisclosed_U) = undisclosed_messages
5. (Abar, Bbar, D) = (init_res[0], init_res[1], init_res[2])

Procedure:

1. r3 = r2^-1 (mod r)

2. e^ = e~ + e_value * challenge
3. r1^ = r1~ - r1 * challenge
4. r3^ = r3~ - r3 * challenge
5. for j in (1, ..., U): m^_j = m~_j + undisclosed_j * challenge (mod r)

6. proof = (Abar, Bbar, D, e^, r1^, r3^, (m^_j1, ..., m^_jU), challenge)
7. return proof_to_octets(proof)

init_res = ProofVerifyInit(PK,
                           proof,
                           generators,
                           header,
                           disclosed_messages,
                           disclosed_indexes,
                           api_id)

Inputs:

- PK (REQUIRED), an octet string of the form outputted by the SkToPk
                 operation.
- proof (REQUIRED), vector representing a BBS proof, consisting of 3
                    points of G1, 3 scalars, another nested but possibly
                    empty vector of scalars and another scalar, in that
                    order.
- generators (REQUIRED), vector of points in G1.
- header (OPTIONAL), octet string. If not supplied it defaults to the
                     empty octet string ("").
- disclosed_messages (OPTIONAL), vector of scalar values. If not
                                 supplied, it defaults to the empty
                                 array ("()").
- disclosed_indexes (OPTIONAL), vector of non-negative integers in
                                ascending order. If not supplied, it
                                defaults to the empty array ("()").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

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

Outputs:

- init_res, vector consisting of 5 points of G1 and a scalar, in that
            order.

Deserialization:

1.  (Abar, Bbar, D, e^, r1^, r3^, commitments, c) = proof
2.  U = length(commitments)
3.  R = length(disclosed_indexes)
4.  L = R + U
5.  (i1, ..., iR) = disclosed_indexes
6.  for i in disclosed_indexes, if i < 0 or i > 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 = ProofChallengeCalculate(init_res, disclosed_messages,
                                          disclosed_indexes, ph, api_id)

Inputs:
- init_res (REQUIRED), vector representing the value returned after
                       initializing the proof generation or verification
                       operations, consisting of 5 points of G1 and a
                       scalar value, in that order.
- disclosed_messages (OPTIONAL), vector of scalar values. If not
                                 supplied, it defaults to the empty
                                 array ("()").
- disclosed_indexes (OPTIONAL), vector of non-negative integers in
                                ascending order. If not supplied, it
                                defaults to the empty array ("()").
- ph (OPTIONAL), an octet string. If not supplied, it must default to
                 the empty octet string ("").
- api_id (OPTIONAL), an octet string. If not supplied it defaults to the
                     empty octet string ("").

Outputs:

- challenge, a scalar.

Definitions:

1. hash_to_scalar_dst, an octet string representing the domain
                       separation tag: api_id || "H2S_" where "H2S_" is
                       an ASCII string comprised of 4 bytes.

Deserialization:

1. R = length(disclosed_indexes)
2. (i1, ..., iR) = disclosed_indexes
3. if length(disclosed_messages) != R, return INVALID
3. (msg_i1, ..., msg_iR) = disclosed_messages
4. (Abar, Bbar, D, T1, T2, domain) = init_res

ABORT if:

1. R > 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)

3.8. Defining New Interfaces

This document defines a BBS Interface to be a set of operations that use the core functions defined in Section 3.6, 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 Section 4.1.1.1. If a set of messages is supplied, the mapping to scalars procedure MUST follow the requirements listed in Section 4.1.2.1.¶

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 Section 4.1). 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:¶

ciphersuite_id || CREATE_GENERATORS_ID || MAP_TO_SCALAR_ID || ADD_INFO

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 [CDL16]). 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 (Section 7), in the sense that applications should avoid creating their own, proprietary Interfaces.¶

4.1. Interface Utilities

This section defines the create_generators and messages_to_scalars operations that are used by the BBS Signatures Interface defined in Section 3.5. 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 Section 3.8).¶

generators = create_generators(count, api_id)

Inputs:

- count (REQUIRED), unsigned integer. Number of generators to create.
- api_id (OPTIONAL), octet string. If not supplied it defaults to the
                     empty octet string ("").

Parameters:

- hash_to_curve_g1, the hash_to_curve operation for the G1 subgroup,
                    defined by the suite specified by the
                    hash_to_curve_suite parameter of the ciphersuite.
- expand_message, the expand_message operation defined by the suite
                  specified by the hash_to_curve_suite parameter of the
                  ciphersuite.
- expand_len, defined by the ciphersuite.

Outputs:

- generators, an array of generators.

Definitions:

1. seed_dst, an octet string representing the domain separation tag:
             api_id || "SIG_GENERATOR_SEED_" where "SIG_GENERATOR_SEED_"
             is an ASCII string comprised of 19 bytes.
2. generator_dst, an octet string representing the domain separation
                  tag: api_id || "SIG_GENERATOR_DST_", where
                  "SIG_GENERATOR_DST_" is an ASCII string comprised of
                  18 bytes.
3. generator_seed, an octet string representing the domain separation
                   tag: api_id || "MESSAGE_GENERATOR_SEED", where
                   "MESSAGE_GENERATOR_SEED" is an ASCII string comprised
                   of 22 bytes.

ABORT if:

1. count > 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)

CREATE_GENERATORS_ID = "H2G_"

msg_scalar = messages_to_scalars(messages, api_id)

Inputs:

- messages (REQUIRED), a vector of octet strings.
- api_id (OPTIONAL), octet string. If not supplied it defaults to the
                     empty octet string ("").

Outputs:

- msg_scalars, a list of scalars.

Definitions:

1. map_dst, an octet string representing the domain separation tag:
            api_id || "MAP_MSG_TO_SCALAR_AS_HASH_" where
            "MAP_MSG_TO_SCALAR_AS_HASH_" is an ASCII string comprised of
            26 bytes.

ABORT if:

1. length(messages) > 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)

MAP_TO_SCALAR_ID = "HM2S_"

For every set of messages and every message msg',
let messages' be the list of messages with msg' appended at the end and
C1 = messages_to_scalars(messages').

Let also msg_prime_scalar = messages_to_scalars((msg')),
and C2 = messages_to_scalars(messages).

If we append msg_prime_scalar at the end of C2, it must always hold that
C1 == C2.

4.2. Core Utilities

This section defines utility procedures that are used by the Core operations defined in Section 3.6.¶

random_scalars = calculate_random_scalars(count)

Inputs:

- count (REQUIRED), non negative integer. The number of pseudo random
                    scalars to return.

Parameters:

- get_random, a pseudo random function with extendable output, returning
              uniformly distributed pseudo random bytes.
- expand_len, defined by the ciphersuite.

Outputs:

- random_scalars, a list of pseudo random scalars,

Procedure:

1. for i in (1, 2, ..., count):
2.     r_i = OS2IP(get_random(expand_len)) mod r
3. return (r_1, r_2, ..., r_count)

hashed_scalar = hash_to_scalar(msg_octets, dst)

Inputs:

- msg_octets (REQUIRED), an octet string. The message to be hashed.
- dst (REQUIRED), an octet string representing a domain separation tag.

Parameters:

- hash_to_curve_suite, the hash to curve suite id defined by the
                       ciphersuite.
- expand_message, the expand_message operation defined by the suite
                  specified by the hash_to_curve_suite parameter.
- expand_len, defined by the ciphersuite.

Outputs:

- hashed_scalar, a scalar.

ABORT if:

- length(dst) > 255

Procedure:

1. uniform_bytes = expand_message(msg_octets, dst, expand_len)
2. return OS2IP(uniform_bytes) mod r

domain = calculate_domain(PK, Q_1, H_Points, header, api_id)

Inputs:

- PK (REQUIRED), an octet string, representing the public key of the
                 Signer of the form outputted by the SkToPk operation.
- Q_1 (REQUIRED), point of G1 (the first point returned from
                  create_generators).
- H_Points (REQUIRED), array of points of G1.
- header (OPTIONAL), an octet string. If not supplied, it must default
                     to the empty octet string ("").
- api_id (OPTIONAL), octet string. If not supplied it defaults to the
                     empty octet string ("").

Outputs:

- domain, a scalar.

Definitions:

1. hash_to_scalar_dst, an octet string representing the domain
                       separation tag: api_id || "H2S_" where "H2S_" is
                       an ASCII string comprised of 4 bytes.

Deserialization:

1. L = length(H_Points)
2. (H_1, ..., H_L) = H_Points

ABORT if:

1. length(header) > 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)

octets_result = serialize(input_array)

Inputs:

- input_array (REQUIRED), an array of elements to be serialized. Each
                          element must be either a point of G1 or G2, a
                          scalar, an ASCII string or an integer value
                          between 0 and 2^64 - 1.

Parameters:

- octet_scalar_length, non-negative integer. The length of a scalar
                       octet representation, defined by the ciphersuite.
- r, the prime order of the subgroups G1 and G2, defined by the
     ciphersuite.
- point_to_octets_E*, operations that serialize a point of E1 or E2 to
                      an octet string of fixed length, defined by the
                      ciphersuite.

Outputs:

- octets_result, a scalar value or INVALID.

Procedure:

1.  let octets_result be an empty octet string.
2.  for el in input_array:
3.      if el is a point of G1: el_octs = point_to_octets_E1(el)
4.      else if el is a point of G2: el_octs = point_to_octets_E2(el)
5.      else if el is a scalar: el_octs = I2OSP(el, octet_scalar_length)
6.      else if el is an integer between 0 and 2^64 - 1:
7.          el_octs = I2OSP(el, 8)
8.      else: return INVALID
9.      octets_result = octets_result || el_octs
10. return octets_result

signature_octets = signature_to_octets(signature)

Inputs:

- signature (REQUIRED), a valid signature, in the form (A, e), where
                        A is a point in G1 and e is a non-zero
                        scalar mod r.

Outputs:

- signature_octets, an octet string or INVALID.

Procedure:

1. (A, e) = signature
2. return serialize((A, e))

signature = octets_to_signature(signature_octets)

Inputs:

- signature_octets (REQUIRED), an octet string of the form output from
                               signature_to_octets operation.

Parameters:

- octets_to_point_E1, operations that deserializes an octet string to a
                      a point of the elliptic curve E1, or INVALID,
                      defined by the ciphersuite.
- subgroup_check_G1, operation that on input a point P returns VALID if
                     P is a valid point of the G1 subgroup, otherwise it
                     returns INVALID (see (#notation)).

Outputs:

signature, a signature in the form (A, e), where A is a point in G1
           and e is a non-zero scalar mod r; or INVALID.

Procedure:

1.  expected_len = octet_point_length + octet_scalar_length
2.  if length(signature_octets) != expected_len, return INVALID
3.  A_octets = signature_octets[0..(octet_point_length - 1)]
4.  A = octets_to_point_E1(A_octets)
5.  if A is INVALID, return INVALID
6.  if A == Identity_G1, return INVALID
7.  if subgroup_check_G1(A) returns INVALID, return INVALID

8.  index = octet_point_length
9.  end_index = index + octet_scalar_length - 1
10. e = OS2IP(signature_octets[index..end_index])
11. if e = 0 or e >= r, return INVALID
12. return (A, e)

proof_octets = proof_to_octets(proof)

Inputs:

- proof (REQUIRED), a BBS proof in the form calculated by ProofGen in
                    step 27 (see above).

Outputs:

- proof_octets, an octet string or INVALID.

Procedure:

1. (Abar, Bbar, D, e^, r1^, r3^, (m^_1, ..., m^_U), c) = proof
2. return serialize((Abar, Bbar, D, e^, r1^, r3^, m^_1, ..., m^_U, c))

proof = octets_to_proof(proof_octets)

Inputs:

- proof_octets (REQUIRED), an octet string of the form outputted from
                           the proof_to_octets operation.

Parameters:

- r, non-negative integer. The prime order of the G1 and G2 groups,
      defined by the ciphersuite.
- octet_scalar_length, non-negative integer. The length of a scalar
                       octet representation, defined by the ciphersuite.
- octet_point_length, non-negative integer. The length of a point in G1
                      octet representation, defined by the ciphersuite.
- subgroup_check_G1, operation that on input a point P returns VALID if
                     P is a valid point of the G1 subgroup, otherwise it
                     returns INVALID (see (#notation)).

Outputs:

- proof, a proof value in the form described above or INVALID

Procedure:

1.  proof_len_floor = 3 * octet_point_length + 4 * octet_scalar_length
2.  if length(proof_octets) < proof_len_floor, return INVALID

// Points (i.e., (Abar, Bbar, D) in ProofGen) de-serialization.
3.  index = 0
4.  for i in (0, 2):
5.      end_index = index + octet_point_length - 1
6.      A_i = octets_to_point_E1(proof_octets[index..end_index])
7.      if A_i is INVALID or Identity_G1, return INVALID
8.      if subgroup_check_G1(A_i) returns INVALID, return INVALID
9.      index += octet_point_length

// Scalars (i.e., (e^, r1^, r3^, m^_j1, ..., m^_jU, c) in
// ProofGen) de-serialization.
10. j = 0
11. while index < length(proof_octets):
12.     end_index = index + octet_scalar_length - 1
13.     s_j = OS2IP(proof_octets[index..end_index])
14.     if s_j = 0 or if s_j >= 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))

W = octets_to_pubkey(PK)

Inputs:

- PK, an octet string. A public key in the form outputted by the SkToPK
      operation

Parameters:

- subgroup_check_G2, operation that on input a point P returns VALID if
                     P is a valid point of the G2 subgroup, otherwise it
                     returns INVALID (see (#notation)).

Outputs:

- W, a valid point in G2 or INVALID

Procedure:

1. W = octets_to_point_E2(PK)
2. if W is INVALID, return INVALID
3. if subgroup_check_G2(W) is INVALID, return INVALID
4. if W == Identity_G2, return INVALID
5. return W

5.1. Header and Presentation Header

As mentioned in Section Section 5.1, 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.¶

5.2. 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 Section 3.5.3). 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 [I-D.ietf-privacypass-key-consistency], to validate that those values are not used to correlate them.¶

5.3. 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., [I-D.ietf-privacypass-key-consistency], see Section 5.2).¶

5.4. 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, [VB22]) or range proofs (for example, [BBB17]) 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 Section 6.8), 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.¶

6.1. Validating Public Keys

Note that all core operations as defined in Section 3.6 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 Section 4.2.4.6, 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 (Section 3.6.1) and CoreProofGen (Section 3.6.3) operations. An explicit invocation to the octets_to_pubkey operation is already defined and therefore required in the CoreVerify (Section 3.6.2) and CoreProofVerify (Section 3.6.4) 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).¶

6.2. Skipping Membership Checks

The subgroup check subgroup_check_G* invocation during either signature deserialization (octets_to_signature, defined in Section 4.2.4.3), proof deserialization (octets_to_proof, defined in Section 4.2.4.5) or public key deserialization (octets_to_pubkey, define in Section 4.2.4.6) 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 ([ADR02]). Furthermore, the pairing operation Section 1.2 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.¶

6.3. 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.¶

6.4. 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.¶

6.5. 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 [RFC9380].¶

In addition, ciphersuites MUST specify unique domain separation tags for hash_to_curve. Some guidance around defining this can be found in Section 7.¶

6.6. 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 Section 7 which as a curve achieves around 117 bits of security [ZCASH-REVIEW].¶

6.7. Randomness Requirements

The key_material input to the KeyGen operation defined in Section 3.4.1 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 [RFC4086]. 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 Section 3.5.3 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 [HDWH12]). 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 (Section 3.1) 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 [DRBG]. 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 [RFC4086] for guidance on implementing such functionality. See also [RFC8937], for recommendations on generating good randomness in cases where the Prover has direct or in-direct access to a secret key.¶

6.8. 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 [RFC3629] or Base-64 decoding [RFC4648]) 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 Section 3.8) or unique header values (see Section 3.5.1) with different pre-processing methodologies.¶

Note that the BBS Interface defined in this document (see Section 3.5) only accepts messages that are represented as octet strings. However, in some more advanced applications, like the ones using range proofs ([BBB17]) 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 [ISO8601] 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 Section 4.1.2.1 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 [UPROVE]). 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 Section 3.5.1). 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 Section 5 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 [I-D.ietf-privacypass-key-consistency].¶

6.9. 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 [TZ23]). 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 [CDL16] [TZ23]).¶

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 [BBDT16] [CDL16] [TZ23]).¶

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 [I-D.ietf-pquip-pqc-engineers]), 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.¶

7.1. Ciphersuite Format

  "BBS_" || H2C_SUITE_ID || ADD_INFO

7.2. BLS12-381 Ciphersuites

The following two ciphersuites are based on the BLS12-381 elliptic curves defined in Section 4.2.1 of [I-D.irtf-cfrg-pairing-friendly-curves]. 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 [I-D.irtf-cfrg-pairing-friendly-curves]. 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 Appendix B.¶

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 [SHA3].¶

The second ciphersuite uses the hash-to-curve suite BLS12381G1_XMD:SHA-256_SSWU_RO_, defined in Section 8.8.1 of the [RFC9380] document, which is based on the SHA-256, as defined in Section 6.2 of [SHA2] .¶

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 Section 4.1.1 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;¶

- seed_dst: ciphersuite_id || "H2G_HM2S_SIG_GENERATOR_SEED_" where
            "H2G_HM2S_SIG_GENERATOR_SEED_" is an ASCII string comprised
            of 28 bytes.
- generator_dst: ciphersuite_id || "H2G_HM2S_SIG_GENERATOR_DST_", where
                 "H2G_HM2S_SIG_GENERATOR_DST_" is an ASCII string
                 comprised of 27 bytes.
- generator_seed: ciphersuite_id || "H2G_HM2S_BP_MESSAGE_GENERATOR_SEED"
                  where "H2G_HM2S_BP_MESSAGE_GENERATOR_SEED" is an ASCII
                  string comprised of 34 bytes.

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 Section 3.5, 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.¶

8.1. Mocked Random Scalars

For the purpose of presenting fixtures for the ProofGen operation (Section 3.5.3), we describe here a way to mock the calculate_random_scalars operation (Section 4.2.1), used by CoreProofGen (Section 3.6.3) 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¶

mocked_calculate_random_scalars(count) :=
                             seeded_random_scalars(SEED, DST, count)

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 (Section 7.2.2), if more than 170 mocked random scalars are required, the operation will return INVALID. Similarly, for the BLS12-381-SHAKE-256 ciphersuite (Section 7.2.1), if more than 1365 mocked random scalars are required, the operation will return INVALID. For the purpose of describing ProofGen (Section 3.5.3) test vectors, those limits are inconsequential.¶

seeded_scalars = seeded_random_scalars(SEED, DST, count)

Inputs:

- SEED (REQUIRED), an octet string. The random seed from which to
                   generate the scalars.
- DST (REQUIRED), octet string representing a domain separation tag.
- count (REQUIRED), non negative integer. The number of scalars to
                    return.

Parameters:

- expand_message, the expand_message operation defined by the
                  ciphersuite.
- expand_len, defined by the ciphersuite.

Outputs:

- mocked_random_scalars, a list of "count" pseudo random scalars

ABORT if:

1. count * expand_len > 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)

8.2. 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.¶

m_1 = h'{{ $messages[0] }}'
m_2 = h'{{ $messages[1] }}'
m_3 = h'{{ $messages[2] }}'
m_4 = h'{{ $messages[3] }}'
m_5 = h'{{ $messages[4] }}'
m_6 = h'{{ $messages[5] }}'
m_7 = h'{{ $messages[6] }}'
m_8 = h'{{ $messages[7] }}'
m_9 = h'{{ $messages[8] }}'
m_10 = h'{{ $messages[9] }}'

8.3. BLS12-381-SHAKE-256 Test Vectors

Test vectors of the BLS12-381-SHAKE-256 ciphersuite defined in Appendix D.1 ciphersuite. Further fixtures are available in Appendix D.1.¶

key_material = h'{{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyMaterial }}'

key_info = h'{{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyInfo }}'

key_dst = h'{{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyDst }}'

SK = 0x'{{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyPair.secretKey }}'

PK = h'{{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyPair.publicKey }}'

msg_scalar_1 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[0].scalar }}'
msg_scalar_2 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[1].scalar }}'
msg_scalar_3 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[2].scalar }}'
msg_scalar_4 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[3].scalar }}'
msg_scalar_5 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[4].scalar }}'
msg_scalar_6 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[5].scalar }}'
msg_scalar_7 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[6].scalar }}'
msg_scalar_8 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[7].scalar }}'
msg_scalar_9 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[8].scalar }}'
msg_scalar_10 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[9].scalar }}'

Q_1 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.Q1 }}'
H_1 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[0] }}'
H_2 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[1] }}'
H_3 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[2] }}'
H_4 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[3] }}'
H_5 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[4] }}'
H_6 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[5] }}'
H_7 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[6] }}'
H_8 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[7] }}'
H_9 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[8] }}'
H_10 = h'{{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[9] }}'

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature001.messages[0] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-shake-256.signature001.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature001.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature001.header }}'

B = h'{{ $signatureFixtures.bls12-381-shake-256.signature001.trace.B }}'
domain = 0x'{{ $signatureFixtures.bls12-381-shake-256.signature001.trace.domain }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature001.signature }}'

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-shake-256.signature004.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.header }}'

B = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.trace.B }}'
domain = 0x'{{ $signatureFixtures.bls12-381-shake-256.signature004.trace.domain }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature004.signature }}'

SEED =
     h'332e313431353932363533353839373933323338343632363433333833323739'

DST =
"BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_H2G_HM2S_MOCK_RANDOM_SCALARS_DST_"

random_scalar_1 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[0] }}'
random_scalar_2 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[1] }}'
random_scalar_3 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[2] }}'
random_scalar_4 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[3] }}'
random_scalar_5 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[4] }}'
random_scalar_6 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[5] }}'
random_scalar_7 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[6] }}'
random_scalar_8 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[7] }}'
random_scalar_9 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[8] }}'
random_scalar_10 = 0x'{{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[9] }}'

m_0 = h'{{ $proofFixtures.bls12-381-shake-256.proof001.messages[0] }}'

public_key = h'{{ $proofFixtures.bls12-381-shake-256.proof001.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-shake-256.proof001.signature }}'
header = h'{{ $proofFixtures.bls12-381-shake-256.proof001.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-shake-256.proof001.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof001.disclosedIndexes }}

random scalars:
    r1 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r1 }}'
    r2 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r2 }}'
    e_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.e_tilde }}'
    r1_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r1_tilde }}'
    r3_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r3_tilde }}'
    m_tilde_scalars: {{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.m_tilde_scalars }}

T1 = h'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-shake-256.proof001.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-shake-256.proof001.proof }}'

m_1 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-shake-256.proof002.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-shake-256.proof002.signature }}'
header = h'{{ $proofFixtures.bls12-381-shake-256.proof002.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-shake-256.proof002.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof002.disclosedIndexes }}

random scalars:
    r1 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r1 }}'
    r2 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r2 }}'
    e_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.e_tilde }}'
    r1_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r1_tilde }}'
    r3_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r3_tilde }}'
    m_tilde_scalars: {{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.m_tilde_scalars }}

T1 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-shake-256.proof002.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-shake-256.proof002.proof }}'

m_1 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-shake-256.proof003.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-shake-256.proof003.signature }}'
header = h'{{ $proofFixtures.bls12-381-shake-256.proof003.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-shake-256.proof003.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof003.disclosedIndexes }}

random scalars:
    r1 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r1 }}'
    r2 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r2 }}'
    e_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.e_tilde }}'
    r1_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r1_tilde }}'
    r3_tilde = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r3_tilde }}'
    m_tilde_scalars:
        m~_1 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[0] }}'
        m~_3 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[1] }}'
        m~_5 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[2] }}'
        m~_7 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[3] }}'
        m~_8 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[4] }}'
        m~_9 = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[5] }}'

T1 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-shake-256.proof003.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-shake-256.proof003.proof }}'

8.4. BLS12381-SHA-256 Test Vectors

Test vectors of the BLS12-381-SHA-256 ciphersuite. Further fixtures are available in Appendix D.2.¶

key_material = h'{{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyMaterial }}'

key_info = h'{{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyInfo }}'

key_dst = h'{{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyDst }}'

SK = 0x'{{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyPair.secretKey }}'

PK = h'{{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyPair.publicKey }}'

dst = h'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.dst }}'

msg_scalar_1 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[0].scalar }}'
msg_scalar_2 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[1].scalar }}'
msg_scalar_3 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[2].scalar }}'
msg_scalar_4 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[3].scalar }}'
msg_scalar_5 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[4].scalar }}'
msg_scalar_6 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[5].scalar }}'
msg_scalar_7 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[6].scalar }}'
msg_scalar_8 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[7].scalar }}'
msg_scalar_9 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[8].scalar }}'
msg_scalar_10 = 0x'{{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[9].scalar }}'

Q_1 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.Q1 }}'
H_1 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[0] }}'
H_2 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[1] }}'
H_3 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[2] }}'
H_4 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[3] }}'
H_5 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[4] }}'
H_6 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[5] }}'
H_7 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[6] }}'
H_8 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[7] }}'
H_9 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[8] }}'
H_10 = h'{{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[9] }}'

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature001.messages[0] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature001.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature001.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature001.header }}'

B = h'{{ $signatureFixtures.bls12-381-sha-256.signature001.trace.B }}'
domain = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature001.trace.domain }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature001.signature }}'

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature004.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.header }}'

B = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.trace.B }}'
domain = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature004.trace.domain }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature004.signature }}'

SEED =
     h'332e313431353932363533353839373933323338343632363433333833323739'

DST =
  "BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_H2G_HM2S_MOCK_RANDOM_SCALARS_DST_"

random_scalar_1 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[0] }}'
random_scalar_2 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[1] }}'
random_scalar_3 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[2] }}'
random_scalar_4 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[3] }}'
random_scalar_5 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[4] }}'
random_scalar_6 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[5] }}'
random_scalar_7 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[6] }}'
random_scalar_8 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[7] }}'
random_scalar_9 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[8] }}'
random_scalar_10 = 0x'{{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[9] }}'

m_0 = h'{{ $proofFixtures.bls12-381-sha-256.proof001.messages[0] }}'

public_key = h'{{ $proofFixtures.bls12-381-sha-256.proof001.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-sha-256.proof001.signature }}'
header = h'{{ $proofFixtures.bls12-381-sha-256.proof001.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-sha-256.proof001.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof001.disclosedIndexes }}

random scalars:
    r1 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r1 }}'
    r2 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r2 }}'
    e_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.e_tilde }}'
    r1_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r1_tilde }}'
    r3_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r3_tilde }}'
    m_tilde_scalars: {{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.m_tilde_scalars }}

T1 = h'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-sha-256.proof001.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-sha-256.proof001.proof }}'

m_1 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-sha-256.proof002.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-sha-256.proof002.signature }}'
header = h'{{ $proofFixtures.bls12-381-sha-256.proof002.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-sha-256.proof002.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof002.disclosedIndexes }}

random scalars:
    r1 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r1 }}'
    r2 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r2 }}'
    e_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.e_tilde }}'
    r1_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r1_tilde }}'
    r3_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r3_tilde }}'
    m_tilde_scalars: {{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.m_tilde_scalars }}

T1 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-sha-256.proof002.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-sha-256.proof002.proof }}'

m_1 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-sha-256.proof003.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-sha-256.proof003.signature }}'
header = h'{{ $proofFixtures.bls12-381-sha-256.proof003.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-sha-256.proof003.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof003.disclosedIndexes }}

random scalars:
    r1 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r1 }}'
    r2 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r2 }}'
    e_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.e_tilde }}'
    r1_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r1_tilde }}'
    r3_tilde = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r3_tilde }}'
    m_tilde_scalars:
        m~_1 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[0] }}'
        m~_3 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[1] }}'
        m~_5 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[2] }}'
        m~_7 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[3] }}'
        m~_8 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[4] }}'
        m~_9 = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[5] }}'

T1 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-sha-256.proof003.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-sha-256.proof003.proof }}'

A.1. BLS12-381 G1

The suite of BLS12381G1_XOF:SHAKE-256_SSWU_RO_ is defined as follows:¶

* encoding type: hash_to_curve (Section 3 of
                 [@!RFC9380])

* E: y^2 = x^3 + 4

* p: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f624
     1eabfffeb153ffffb9feffffffffaaab

* r: 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001

* m: 1

* k: 128

* expand_message: expand_message_xof (Section 5.3.2 of
                  [@!RFC9380])

* hash: SHAKE-256

* L: 64

* f: Simplified SWU for AB == 0 (Section 6.6.3 of
     [@!RFC9380])

* Z: 11

*  E': y'^2 = x'^3 + A' * x' + B', where

      -  A' = 0x144698a3b8e9433d693a02c96d4982b0ea985383ee66a8d8e8981aef
                d881ac98936f8da0e0f97f5cf428082d584c1d

      -  B' = 0x12e2908d11688030018b12e8753eee3b2016c1f0f24f4070a0b9c14f
                cef35ef55a23215a316ceaa5d1cc48e98e172be0

*  iso_map: the 11-isogeny map from E' to E given in Appendix E.2 of
            [@!RFC9380]

*  h_eff: 0xd201000000010001

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 [RFC9380].¶

An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to BLS12-381 G1 is given in Appendix F.2 [RFC9380].¶

B.1. Optimal Ate pairing

This section describes the optimal Ate pairing for BLS12-381. The pairing computation uses the following utility function.¶

res = Line_function(Q1, Q2, P)

Inputs:

- Q1 (REQUIRED), point of G2.
- Q2 (REQUIRED), point of G2.
- P (REQUIRED), point of G1.

Outputs:

- res: an element on the target group G_T.

Procedure:

1. (x_1, y_1) = Q1
2. (x_2, y_2) = Q2
3. (x, y) = P
4. if Q1 = Q2, set l = (3 * x_1^2) / (2 * y_1)
5. else if Q1 = - Q2, return x - x_1
6. else set l = (y_2 - y_1) / (x_2 - x_1)
7. return (l * (x - x_1) + y_1 - y)

Let c = t for t as defined above (Appendix B) 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,¶

1.  set f = 1 and T = Q
2.  if c_L = -1, set T = -T
3.  for i in (L-1, L-2, ..., 1, 0)
4.      f = f^2 * Line_function(T, T, P)
5.      T = T + T
6.      if c_i = 1,
7.          f = f * Line_function(T, Q, P)
8.          T = T + Q
9.      else if c_i = -1,
10.         f = f * Line_function(T, -Q, P)
11.         T = T - Q
12. f = f ^ ((p ^ 12 - 1) / r)
13. return f

B.2. Point Encoding

This section defines point encoding and decoding procedures for BLS12-381. Although more flexible point encoding procedures may exist (for example [I-D.ietf-lwig-curve-representations]), the vast majority of current libraries implementing BLS12-381 use (most of them explicitly) the encoding method defined in Appendix C of [I-D.irtf-cfrg-pairing-friendly-curves]. For this reason, the ciphersuites defined in Section 7.2, use those encoding and decoding procedures. For completeness, those operations are defined in this section as well. See [I-D.irtf-cfrg-pairing-friendly-curves] for a more detailed explanation of the encoding and decoding steps. Note also that we will only consider compressed point encoding (in contrast to [I-D.irtf-cfrg-pairing-friendly-curves], 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).¶

res = sign_GF_p(y)

Inputs:

- y (REQUIRED), point of the GF(p) group

Outputs:

- res, either 0 or 1

Procedure:

1. if y > (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).¶

res = sign_GF_p^2(y)

Inputs:

- y (REQUIRED), point of the GF(p^2) group

Outputs:

- res, either 0 or 1

Procedure:

1. (y_0, y_1) = y
2. if y_1 is 0, return sign_GF_p(y_0)
3. if y_1 > (p - 1) / 2, return 1
4. return 0

C.1. 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 [I-D.ietf-jose-json-web-proof]). 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.¶

C.2. 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 ([RFC9449]), 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.¶

C.3. 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.¶

D.1. BLS12-381-SHAKE-256 Ciphersuite

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-shake-256.signature010.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.header }}'

B = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.trace.B }}'
domain = 0x'{{ $signatureFixtures.bls12-381-shake-256.signature010.trace.domain }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature010.signature }}'

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature002.messages[0] }}'

PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature002.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature002.header }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature002.signature }}'

valid: {{ $signatureFixtures.bls12-381-shake-256.signature002.result.valid }}
reason: {{ $signatureFixtures.bls12-381-shake-256.signature002.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature003.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature003.messages[1] }}'

PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature003.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature003.header }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature003.signature }}'

valid: {{ $signatureFixtures.bls12-381-shake-256.signature003.result.valid }}
reason: {{ $signatureFixtures.bls12-381-shake-256.signature003.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature005.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature005.messages[1] }}'

PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature005.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature005.header }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature005.signature }}'

valid: {{ $signatureFixtures.bls12-381-shake-256.signature005.result.valid }}
reason: {{ $signatureFixtures.bls12-381-shake-256.signature005.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.messages[9] }}'

PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.header }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature006.signature }}'

valid: {{ $signatureFixtures.bls12-381-shake-256.signature006.result.valid }}
reason: {{ $signatureFixtures.bls12-381-shake-256.signature006.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.messages[9] }}'

PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.header }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature007.signature }}'

valid: {{ $signatureFixtures.bls12-381-shake-256.signature007.result.valid }}
reason: {{ $signatureFixtures.bls12-381-shake-256.signature007.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.messages[9] }}'

PK = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.header }}'

signature = h'{{ $signatureFixtures.bls12-381-shake-256.signature008.signature }}'

valid: {{ $signatureFixtures.bls12-381-shake-256.signature008.result.valid }}
reason: {{ $signatureFixtures.bls12-381-shake-256.signature008.result.reason }}

m_1 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-shake-256.proof014.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-shake-256.proof014.signature }}'
header = h'{{ $proofFixtures.bls12-381-shake-256.proof014.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-shake-256.proof014.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof014.disclosedIndexes }}

T1 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-shake-256.proof014.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-shake-256.proof014.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-shake-256.proof014.proof }}'

m_1 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-shake-256.proof015.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-shake-256.proof015.signature }}'
header = h'{{ $proofFixtures.bls12-381-shake-256.proof015.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-shake-256.proof015.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof015.disclosedIndexes }}

T1 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-shake-256.proof015.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-shake-256.proof015.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-shake-256.proof015.proof }}'

msg = h'{{ $H2sFixture.bls12-381-shake-256.h2s.message }}'

dst = h'{{ $H2sFixture.bls12-381-shake-256.h2s.dst }}'

scalar = 0x'{{ $H2sFixture.bls12-381-shake-256.h2s.scalar }}

D.2. BLS12-381-SHA-256 Ciphersuite

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature010.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.header }}'

B = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.trace.B }}'
domain = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature010.trace.domain }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature010.signature }}'

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature002.messages[0] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature002.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature002.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature002.header }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature002.signature }}'

valid: {{ $signatureFixtures.bls12-381-sha-256.signature002.result.valid }}
reason: {{ $signatureFixtures.bls12-381-sha-256.signature002.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature003.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature003.messages[1] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature003.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature003.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature003.header }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature003.signature }}'

valid: {{ $signatureFixtures.bls12-381-sha-256.signature003.result.valid }}
reason: {{ $signatureFixtures.bls12-381-sha-256.signature003.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature005.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature005.messages[1] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature005.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature005.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature005.header }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature005.signature }}'

valid: {{ $signatureFixtures.bls12-381-sha-256.signature005.result.valid }}
reason: {{ $signatureFixtures.bls12-381-sha-256.signature005.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature006.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.header }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature006.signature }}'

valid: {{ $signatureFixtures.bls12-381-sha-256.signature006.result.valid }}
reason: {{ $signatureFixtures.bls12-381-sha-256.signature006.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature007.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.header }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature007.signature }}'

valid: {{ $signatureFixtures.bls12-381-sha-256.signature007.result.valid }}
reason: {{ $signatureFixtures.bls12-381-sha-256.signature007.result.reason }}

m_1 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[0] }}'
m_2 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[1] }}'
m_3 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[2] }}'
m_4 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[3] }}'
m_5 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[4] }}'
m_6 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[5] }}'
m_7 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[6] }}'
m_8 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[7] }}'
m_9 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[8] }}'
m_10 = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.messages[9] }}'

SK = 0x'{{ $signatureFixtures.bls12-381-sha-256.signature008.signerKeyPair.secretKey }}'
PK = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.signerKeyPair.publicKey }}'
header = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.header }}'

signature = h'{{ $signatureFixtures.bls12-381-sha-256.signature008.signature }}'

valid: {{ $signatureFixtures.bls12-381-sha-256.signature008.result.valid }}
reason: {{ $signatureFixtures.bls12-381-sha-256.signature008.result.reason }}

m_1 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-sha-256.proof014.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-sha-256.proof014.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-sha-256.proof014.signature }}'
header = h'{{ $proofFixtures.bls12-381-sha-256.proof014.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-sha-256.proof014.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof014.disclosedIndexes }}

T = h'{{ $proofFixtures.bls12-381-sha-256.proof014.trace.T }}'
domain = 0x'{{ $proofFixtures.bls12-381-sha-256.proof014.trace.domain }}'
challenge = 0x'{{ $proofFixtures.bls12-381-sha-256.proof014.trace.challenge }}'

proof = h'{{ $proofFixtures.bls12-381-sha-256.proof014.proof }}'

m_1 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[0] }}'
m_2 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[1] }}'
m_3 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[2] }}'
m_4 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[3] }}'
m_5 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[4] }}'
m_6 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[5] }}'
m_7 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[6] }}'
m_8 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[7] }}'
m_9 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[8] }}'
m_10 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.messages[9] }}'

public_key = h'{{ $proofFixtures.bls12-381-sha-256.proof015.signerPublicKey }}'
signature = h'{{ $proofFixtures.bls12-381-sha-256.proof015.signature }}'
header = h'{{ $proofFixtures.bls12-381-sha-256.proof015.header }}'
presentation_header = h'{{ $proofFixtures.bls12-381-sha-256.proof015.presentationHeader }}'
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof015.disclosedIndexes }}

T1 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.trace.T1 }}'
T2 = h'{{ $proofFixtures.bls12-381-sha-256.proof015.trace.T2 }}'
domain = 0x'{{ $proofFixtures.bls12-381-sha-256.proof015.trace.domain }}'

proof = h'{{ $proofFixtures.bls12-381-sha-256.proof015.proof }}'

msg = h'{{ $H2sFixture.bls12-381-sha-256.h2s.message }}'

dst = h'{{ $H2sFixture.bls12-381-sha-256.h2s.dst }}'

scalar = 0x'{{ $H2sFixture.bls12-381-sha-256.h2s.scalar }}'