%%% title = "The BBS Signature Scheme" abbrev = "The BBS Signature Scheme" ipr= "trust200902" area = "Internet" workgroup = "CFRG"
[seriesInfo] name = "Internet-Draft" value = "draft-irtf-cfrg-bbs-signatures-latest" status = "informational"
[[author]] initials = "T." surname = "Looker" fullname = "Tobias Looker" #role = "editor" organization = "MATTR" [author.address] email = "[email protected]"
[[author]] initials = "V." surname = "Kalos" fullname = "Vasilis Kalos" #role = "editor" organization = "MATTR" [author.address] email = "[email protected]"
[[author]] initials = "A." surname = "Whitehead" fullname = "Andrew Whitehead" #role = "editor" organization = "Portage" [author.address] email = "[email protected]"
[[author]] initials = "M." surname = "Lodder" fullname = "Mike Lodder" #role = "editor" organization = "CryptID" [author.address] email = "[email protected]"
%%%
.# Abstract
This document describes the BBS Signature scheme, a secure, multi-message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs-of-knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature it self, while at the same time, guarantying the authenticity and integrity of the disclosed messages.
{mainmatter}
A digital signature scheme is a fundamental cryptographic primitive that is used to provide data integrity and verifiable authenticity in various protocols. The core premise of digital signature technology is built upon asymmetric cryptography where-by the possessor of a private key is able to sign a message, where anyone in possession of the corresponding public key matching that of the private key is able to verify the signature.
Beyond the core properties of a digital signature scheme, the BBS signatures and proofs provide multiple additional unique properties. Three key ones are:
Selective Disclosure - The scheme allows a Signer to sign multiple messages and produce a single -constant size- output signature. A Prover then possessing the messages and the signature can generate a proof whereby they can choose which messages to disclose, while revealing no-information about the undisclosed messages. The proof itself guarantees the integrity and authenticity of the disclosed messages (e.g. that they were originally signed by the Signer).
Unlinkable Proofs - The proofs generated by the scheme are zero-knowledge, proofs-of-knowledge of the signature, meaning a verifying party in receipt of a proof is unable to determine which signature was used to generate the proof, removing a common source of correlation. In general, each BBS proof is indistinguishable from random even if generated from the same signature.
Proof of Possession - The proofs generated by the scheme prove to a Verifier that the party who generated the proof (Prover) was in possession of a signature without revealing it. The scheme also supports binding a presentation header to the generated proof. The presentation header can include arbitrary information such as a cryptographic nonce, an audience/domain identifier and or time based validity information (for more details on the presentation header, see (#header-and-presentation-header-usage)).
Refer to the (#use-cases) for an elaboration on situations where these properties are useful.
Below is a basic diagram describing the main entities involved in the scheme
!---
(1) sign (3) ProofGen
+----- +-----
| | | |
| | | |
| \ / | \ /
+----------+ +-----------+
| | | |
| | | |
| | | |
| Signer |---(2)* Send signature + msgs----->| Holder/ |
| | | Prover |
| | | |
| | | |
+----------+ +-----------+
|
|
|
(4)* Send proof + disclosed msgs
|
|
\ /
+-----------+
| |
| |
| |
| Verifier |
| |
| |
| |
+-----------+
| / \
| |
| |
+-----
(5) ProofVerify
!--- Figure: Basic diagram capturing the main entities involved in using the scheme
Note The protocols implied by the items annotated by an asterisk are out of scope for this specification
The name BBS is derived from the authors of the original academic work by Dan Boneh, Xavier Boyen, and Hovav Shacham [@BBS04], where the scheme was first described as part of a group signatures protocol. Soon after, the scheme was described by Camenisch and Lysyanskaya as a stand-alone signatures scheme in [@CL04], for anonymous credentials applications. Later, Au, Susilo an Mu presented the first, provably secure version of BBS Signatures in [@ASM06]. Following, works by Camenisch, Drijvers and Lehmann [@CDL16] and by Barki, Brunet, Desmoulins and Traore [@BBDT16], proved the security of the scheme in settings where more efficient computations are possible, thereby improving performance. Finally, in 2023, Tessaro and Zhu, presented in [@TZ23] further performance improvements, shrinking the BBS signature. This document is mainly based on that work.
Note that the BBS Signatures scheme is based on the discrete logarithm problem. This means that it is not "post-quantum secure". However, the privacy and hiding properties of BBS proofs are resilient even against an attacker utilizing a Cryptographically Relevant Quantum Computer ([@I-D.ietf-pquip-pqc-engineers]). See (#post-quantum-security) for an elaboration on the security properties of BBS Signatures against such a computer.
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 (#notation)).
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]. Note, 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]. Note, 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.
The following notation and primitives are used:
a || b : Denotes the concatenation of octet strings a and b.
I \ J : For sets I and J, denotes the difference of the two sets i.e., all the elements of I that do not appear in J, in the same order as they were in I.
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).
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.
This document is organized as follows:
-
Scheme Definition ((#scheme-definition)), defines the core operations and parameters for the BBS signature scheme.
-
Utility Operations ((#utility-operations)), defines utilities used by the BBS signature scheme.
-
Security Considerations ((#security-considerations)), describes a set of security considerations associated to the signature scheme.
-
Ciphersuites ((#ciphersuites)), defines the format of a ciphersuite, alongside a concrete ciphersuite based on the BLS12-381 curve.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [@!RFC2119].
This section defines the BBS signature scheme, including the parameters required to define a concrete instantiation of the protocol.
The schemes operations defined in this section depend on the following parameters:
-
A pairing-friendly elliptic curve, plus associated functionality given in (#notation).
-
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.
-
subgroup_check_G1(P) and subgroup_check_G2(P): operations that return VALID if the point P is in the subgroup G1 or G2 correspondingly, and INVALID otherwise, as defined in (#notation).
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.
Each of the core operations (see (#core-operations)), expect a list of points (called the generators, see (#generators)) and a list of messages represented as scalar values (see (#messages)). It is the job of the Interface to:
- Create the necessary generators.
- Map the inputted messages to scalars.
This allows for extensibility of the core scheme without exposing the resulting complexity to all applications. To ensure proper separation between BBS Interfaces with distinct functionality, each Interface is parametrized by a unique identifier (called api_id) that will be used as a domain separation tag (dst) by the core ((#core-operations)) and utility ((#interface-utilities)) 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 (#defining-new-interfaces).
In definition of this signature scheme there are two possible variations based upon the sub-group selection, namely where public keys are defined in G2 and signatures in G1 OR the opposite where public keys are defined in G1 and signatures in G2. Some pairing cryptography based digital signature schemes such as [@I-D.irtf-cfrg-bls-signature] elect to allow for both variations, because they optimize for different use cases. However, in the case of this scheme, due to the operations involved in both signature and proof generation being computational in-efficient when performed in G2 and in the pursuit of simplicity, the scheme is limited to a construction where public keys are in G2 and signatures in G1.
Throughout the operations of this signature scheme, each message that is signed is paired with a specific point of G1, called a generator. Specifically, if a generator H_1 is multiplied with msg_1 during signing, then H_1 MUST be multiplied with msg_1 in all other operations (signature verification, proof generation and proof verification). As a result, the messages must be passed to the operations of the BBS scheme in the same order.
Aside from the message generators, the scheme uses one additional generator Q_1 to sign the signature's domain, which binds both the signature and generated proofs to a specific context and cryptographically protects any potential application-specific information (for example, messages that must always be disclosed etc.). This document uses the procedures defined in [@!I-D.irtf-cfrg-hash-to-curve] to create the generators. See (#generators-calculation) on more details.
In this document, the messages to be signed are defined as octet-strings. Each message must be mapped to a scalar value before passed to one of the core BBS operations ((#core-operations)). There are various ways to map a message to a scalar value. The BBS Signatures Interface defined in this document (see (#bbs-signatures-interface)), makes use of a hash function (see (#messages-to-scalars)). See (#messages-to-scalars) on further details on how the each message is mapped to a scalar value and (#mapping-messages-to-scalars) for more details and guidance on using alternative mapping methods.
Note that arrays in this document use the zero-based numbering common in many programming languages, meaning that element indexing starts from 0 (see (#notation)). This is distinct from naming used during deserialization of arrays, where natural (one-based) numbering might be used as part of the names of the array's elements for clarity in that context.
For example, if X is an array of n elements, we may write,
[a_1, a_2, ..., a_n] = X
The above would indicate that
X[0] = a_1
X[1] = a_2
// ... and so on, up to
X[n-1] = a_n
When serializing one or more values to produce an octet string, each element will be encoded using a specific operation determined by its type. More concretely,
- Points in
E*will be serialized using thepoint_to_octets_E*implementation for a particular ciphersuite. - Non-negative integers will be serialized using
I2OSPwith an output length of 8 bytes. - Scalars will be serialized using
I2OSPwith a constant output length defined by a particular ciphersuite.
We also use strings in double quotes to represent ASCII-encoded literals. For example "BBS" will be used to refer to the octet string, 010000100100001001010011.
Those rules will be used explicitly on every operation. See also serialize defined in (#serialize).
There are two special values defined by the BBS Scheme; the header and the presentation_header. The header value is chosen by the Signer and is bound to both a BBS signature and the BBS proofs, which was generated using that signature. Specifically, the Prover is required to reveal the header to the proof Verifier, during every BBS proof presentation. As a result, the Signer SHOULD NOT include in the header any identifying information, that may have the potential of compromising the Prover's privacy (see (#privacy-considerations)). Suitable use cases taking advantage of the header value include binding a BBS signature (and subsequent BBS proofs) to a specific application, deployment or domain, (in general, binding the signature to specific sets of metadata).
Similarly, the Prover can choose a presentation_header value to be bound to the BBS proof (in contrast to the header value that is chosen by the Signer and is bound to both BBS proof and signature). Verifying a BBS proof will guarantee the authenticity and integrity of the presentation_header value. This makes it suitable for ensuring the freshness of a BBS proof, for example, by including in it a (possibly supplied by the Verifier) random value. Other use cases include binding the BBS proof to a certain domain/audience or validity period. The presentation_header can also be used by the Prover to sign a message. In this case, the Prover will add to the presentation_header the message they want to sign. A valid BBS proof guarantees that the message contained in the presentation_header was signed by the same Prover that generated that proof (similar to how group signatures work [@BBS04], where the group in this case will be all the Provers having received valid signatures under a specific public key).
This operation generates a secret key (SK) deterministically from a secret octet string (key_material). This operation is the RECOMMENDED way of generating a secret key, but its use is not required for compatibility, and implementations MAY use a different key generation procedure. For security, such an alternative MUST output a secret key that is statistically close to uniformly random in the range from 1 to r - 1. An example of an HKDF-based alternative is the KeyGen operation defined in Section 2.3 of [@I-D.irtf-cfrg-bls-signature] (with an appropriate, BBS specific, salt value, like "BBS_SIG_KEYGEN_SALT_").
For security, key_material MUST be random and infeasible to guess, e.g. generated by a trusted source of randomness and with enough entropy. See [@!RFC4086] for suggestions on generating randomness. key_material MUST be at least 32 bytes long, but it MAY be longer.
KeyGen takes an optional input, key_info. This parameter MAY be used to derive distinct keys from the same key material.
Because KeyGen is deterministic, implementations MAY choose either to store the resulting SK or to store key_material and key_info and call KeyGen to derive SK when necessary.
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
This operation takes a secret key (SK) and outputs a corresponding public key (PK).
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)
This section defines a BBS Signatures Interface (see (#interfaces)), that makes use of the core operations defined in (#core-operations), to perform the functions of signing and verifying the signature, as well as generating and validating the BBS proof. To create the generators (see (#generators)) it uses the create_generators operation defined in (#generators-calculation). Each inputted message is an octet string (see (#messages)). To map the messages to scalars, it uses the messages_to_scalars operation defined in (#messages-to-scalars). 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 (#header-and-presentation-header-usage) 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 and "H2G_HM2S_"is an ASCII string comprised of 9 bytes, wherein "H2G_" refers to the identifier of the create_generators operation used (see (#generators-calculation)) and "HM2S_" is the identifier of the used messages_to_scalars mapping (see (#messages-to-scalars)).
The Sign operation returns a BBS signature from a secret key (SK), over a header and a set of messages.
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
The Verify operation validates a BBS signature, given a public key (PK), a header and a set of messages.
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
The ProofGen operation creates BBS proof, which is a zero-knowledge, proof-of-knowledge of a BBS signature, while optionally disclosing any subset of the signed messages. Validating the proof (see ProofVerify defined in (#proof-verification-proofverify)) guarantees authenticity and integrity of the header and disclosed messages, as well as knowledge of a valid BBS signature.
Other than the Signer's public key (PK), the BBS signature and the signed header and messages, the operation also accepts a presentation header value, that will be bound the the resulting proof (see (#header-and-presentation-header-usage)). To indicate which of the messages should be disclosed, the operation accepts a list of integers in ascending order, representing the indexes of those messages.
proof = 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
The ProofVerify operation validates a BBS proof, given the Signer's public key (PK), a header and presentation header values, the disclosed messages and the indexes those messages had in the original vector of signed messages.
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
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 (#defining-new-interfaces).
The operations of this section make use of functions and sub-routines defined in Utility Operations. More specifically,
hash_to_scalaris defined in (#hash-to-scalar)calculate_domainis defined in (#domain-calculation).serialize,signature_to_octets,octets_to_signature,proof_to_octets,octets_to_proofandoctets_to_pubkeyare defined in (#serialization).his the pairing operation used (see (#notation)), 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 (#defining-new-generators) for more details. Each message is represented as a scalar value. See (#messages-to-scalars) 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.
This operation computes a deterministic signature from a secret key (SK), a set of generators (points of G1) and optionally a header and a vector of messages.
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))
Note When computing step 4 of the above procedure there is an extremely small probability (around 2^(-r)) that the condition (SK + e) = 0 mod r will be met. How implementations evaluate the inverse of the scalar value 0 may vary, with some returning an error and others returning 0 as a result. If the returned value from the inverse operation 1/(SK + e) does evaluate to 0 the value of A will equal Identity_G1 thus an invalid signature. Implementations MAY elect to check (SK + e) = 0 mod r prior to step 4, and or A != Identity_G1 after step 4 to prevent the production of invalid signatures.
This operation checks that a signature is valid for a given set of generators, header and vector of messages, against a supplied public key (PK). The set of messages MUST be supplied in this operation in the same order they were supplied to CoreSign ((#coresign)) when creating the signature.
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 + BP2 * e) * h(B, -BP2) != Identity_GT, return INVALID
4. return VALID
This operation computes a zero-knowledge proof-of-knowledge of a signature, while optionally selectively disclosing from the original set of signed messages. The Prover may also supply a presentation header (ph). See (#header-and-presentation-header-usage) for more details. Validating the resulting proof (using the CoreProofVerify algorithm defined in (#coreproofverify)), guarantees the integrity and authenticity of the revealed messages, as well as the possession of a valid signature (for the public key PK) by the Prover. See (#proof-generation-and-verification-algorithmic-explanation) for a high level explanation on the inner-workings of the algorithm.
The CoreProofGen operation will accept that signature as an input. It is RECOMMENDED to validate that signature, using the inputted public key PK and generators set, against the supplied messages and header, with the CoreVerify operation defined in (#coreverify).
The messages supplied in this operation MUST be in the same order as when supplied to CoreSign ((#coresign)). To specify which of those messages will be disclosed, the Prover can supply the list of indexes (disclosed_indexes) that the disclosed messages have in the array of signed messages. Each element in disclosed_indexes MUST be a non-negative integer, in the range from 0 to length(messages) - 1.
The operation works by first calculating a set of random scalars using the calculate_random_scalars operation defined in (#random-scalars), utilized to blind the signature and the undisclosed messages (see (#randomness-requirements) for considerations and requirements on random scalars generation). It then initializes the proof using the ProofInit subroutine defined in (#proof-initialization). The result will be passed to the challenge calculation operation (ProofChallengeCalculate, defined in (#challenge-calculation)). The outputted challenge, together with the initialization result, will be used by the ProofFinalize subroutine defined in (#proof-finalization), which will return the proof value.
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_indexes,
disclosed_messages, ph)
5. if challenge is INVALID, return INVALID
6. proof = ProofFinalize(init_res, challenge, e, random_scalars,
undisclosed_messages)
7. return proof
This operation checks that a proof is valid for a header, vector of disclosed messages (disclosed_messages) along side their index corresponding to their original position when signed (disclosed_indexes) and presentation header (ph) against a public key (PK).
The inputted disclosed messages (disclosed_messages) MUST be supplied to this operation in the same order as they had as part of the messages input of the CoreSign operation defined in (#coresign). Similarly, the indexes of the disclosed messages (disclosed_indexes) MUST be the same and in the same order as the disclosed_indexes input of CoreProofGen ((#coreproofgen)). Failure to comply with these requirements will result to the proof verification procedure returning INVALID.
The operation works by first initializing the proof verification procedure using the ProofVerifyInit subroutine defined in (#proof-verification-initialization). The result will be inputted to the challenge calculation operation (ProofChallengeCalculate, defined in (#challenge-calculation)). The resulting challenge and the two first components of the received proof (points of G1) will be checked for correctness (steps 5 and 6 in the following procedure), to verify the proof.
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,
messages, disclosed_indexes, api_id)
2. if init_res is INVALID, return INVALID
3. challenge = ProofChallengeCalculate(init_res, disclosed_indexes,
messages, 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
This section describes the subroutines used by the CoreProofGen ((#coreproofgen)) and CoreProofVerify ((#coreproofverify)) operations. See (#proof-generation-and-verification-algorithmic-explanation), for a high-level intuitive overview of the procedure used to generate and verify a BBS proof.
This operation initializes the proof and returns one of the inputs passed to the challenge calculation operation (i.e., ProofChallengeCalculate, (#challenge-calculation)), during the CoreProofGen operation defined in (#coreproofgen).
The inputted messages MUST be supplied to this operation in the same order they had when inputted to the CoreSign operation ((#coresign)).
The defined procedure needs the messages the Prover decided to not disclose. For this purpose, along the list of signed messages, the operation also accepts a set of integers in the range from 0 to length(messages) - 1 (inclusive) in ascending order, representing the indexes of the undisclosed messages (undisclosed_indexes). To blind the inputted signature and the undisclosed messages, the operation will also accept a set of uniformly random scalars (random_scalars). This set must have exactly 5 more items than the list of undisclosed indexes (i.e., it must hold that length(random_scalars) = length(undisclosed_indexes) + 5).
This operation makes use of the calculate_domain function defined in (#domain-calculation).
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)
This operation finalizes the proof calculation during the CoreProofGen operation defined in (#coreproofgen) and returns the serialized proof value.
As inputs, this operation accepts the proof initialization result as returned by the ProofInit operation defined in (#proof-initialization) (init_res) as well as a scalar value representing the proof's challenge as calculated by the ProofChallengeCalculate operation defined in (#challenge-calculation). It also requires the scalar part of the BBS signature (e_value), the random scalars used to generate the proof (random_scalars, as inputted to the ProofInit operation) and a set of scalars, representing the messages the Prover decided to not disclose (undisclosed_messages). Those messages MUST be supplied to this operation in the same order as they had as part of the messages input of the CoreSign operation ((#coresign)).
This operation makes use of the proof_to_octets function defined in (#proof-to-octets).
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)
This operation initializes the proof verification operation and returns part of the input that will be passed to the challenge calculation operation (i.e., ProofChallengeCalculate, (#challenge-calculation)), during the CoreProofVerify operation defined in (#coreproofverify).
Note that, the scalars representing the disclosed messages (disclosed_messages) MUST be supplied to this operation in the same order as they had as part of the messages input of the CoreSign operation defined in (#coresign) (otherwise, proof verification will fail). Similarly, the indexes of the disclosed messages in the set of signed messages MUST be supplied to this operation as a set of integers in accenting order (disclosed_indexes).
This operation makes use of the calculate_domain function defined in (#domain-calculation).
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 3 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)
This operation calculates the challenge scalar value, used during the CoreProofGen ((#coreproofgen)) and CoreProofVerify ((#coreproofverify)), as part of the Fiat-Shamir heuristic, for making the proof protocol non-interactive (in a interactive setting, the challenge would be a random value supplied by the Verifier).
As inputs, this operation will accept the proof generation or verification initialization result, as outputted by the ProofInit ((#proof-initialization)) or ProofVerifyInit ((#proof-verification-initialization)) operations (init_res). It will additionally accept the set of scalars representing the messages the Prover disclosed (disclosed_messages) as well as the list of indexes those messages had in the vector of signed messages (disclosed_indexes), together with the presentation header (ph).
At a high level, the challenge will be calculated as the digest (using hash_to_scalar defined in (#hash-to-scalar), to map it to a scalar value) of the following values:
- The total number of disclosed messages
R. - Each index in the
disclosed_indexeslist, followed by the corresponding disclosed message (i.e., ifdisclosed_indexes = [i1, i2]anddisclosed_messages = [msg_i1, msg_i2], the input to the challenge digest, afterR, will includei1 || msg_i1 || i2 || msg_i2). - The points
Abar, Bbar, D, T1, T2and thedomainscalar, calculated during the proof initialization phase ofCoreProofGen(see (#coreproofgen)). - The inputted presentation header (
ph) values.
This operation makes use of the serialize function, defined in (#serialize).
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 (REQUIRED), 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)
Note: If the presentation header (ph) is not supplied in ProofChallengeCalculate, 8 bytes representing a length of 0 (i.e., 0x0000000000000000), must still be appended after the serialize(c_arr) value, during the concatenation step of the above procedure (step 2).
This document defines a BBS Interface to be a set of operations that use the core functions defined in (#core-operations), 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 (#defining-new-generators). If a set of messages is supplied, the mapping to scalars procedure MUST follow the requirements listed in (#define-a-new-map-to-scalar).
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 (#interface-utilities)). 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 ((#ciphersuites)), in the sense that applications should avoid creating their own, proprietary Interfaces.
This section defines utility operations that are used by either the BBS Interface or the BBS Core Operations.
This section defines the create_generators and messages_to_scalars operations that are used by the BBS Signatures Interface defined in (#bbs-signatures-interface). 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 (#defining-new-interfaces)).
The create_generators procedure defines how to create a set of randomly sampled points from the G1 subgroup, called the generators. It makes use of the primitives defined in [@!RFC9380] (more specifically of hash_to_curve and expand_message) to hash a seed to a set of generators. Those primitives are implicitly defined by the ciphersuite, through the choice of a hash-to-curve suite (see the hash_to_curve_suite parameter in (#ciphersuite-format)).
Since create_generators generates constant points, as an optimization, implementations MAY cache its result for a specific count (which can be arbitrarily large, depending on the application). Care must be taken, to guarantee that the generators will be fetched from the cache in the same order they had when they where created (i.e., an application should not sort or in any way rearrange the cached generators).
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)
The value of v MAY also be cached in order to efficiently extend an existing list of cached generator points.
The CREATE_GENERATORS_ID of the above operation is define as,
CREATE_GENERATORS_ID = "H2G_"
When defining a new create_generators procedure, the most important property is that the points are pseudo-randomly chosen from the G1 group, with no known relationship to each other, given reasonable assumptions and cryptographic primitives. More specifically, the required properties are
- The generators should be indistinguishable from uniformly radom points of G1 (even given the knowledge of the system's public parameters, like the
generator_seedvalue in (#generators-calculation)). This means that given only the pointsH_1, ..., H_iit should be infeasible to guessH_(i+1)(or anyH_jwithj > i), for anyi. This also means that it should be infeasible to represent any of the generators as multi-exponentiation product (i.e., of the formH_i1 * a_1 + H_i2 * a_2 + ... + H_in * a_n) of any of the other generators. - The returned points must be unique with very high probability, that would not lessen the targeted security level of the ciphersuite. Specifically, for a security level
k, the probability of a collision should be at most1/2^k. - The returned points must be different from the Identity point of G1 as well as the constant point
P1defined by the ciphersuite.
Every operation that is used to return generator points for use with the core BBS operations ((#core-operations)), MUST return points that conform to the aforementioned rules. Such operation must also follow the rules outlined bellow,
- It MUST be deterministic and constant time for a specific number of generators.
- It MUST use proper domain separation for both the
create_generatorsprocedure, as well as all of the internally-called procedures.
The messages_to_scalars operation is used to map a list of messages to their respective scalar values, which are required by the core BBS operations defined in (#core-operations).
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)
The MAP_TO_SCALAR_ID of the above operation is defines as,
MAP_TO_SCALAR_ID = "HM2S_"
The most important property that a new operation that will map a set of messages to a set of scalars must have, is that each message should be mapped to a scalar independently from all the other messages. More specifically, the following MUST hold,
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.
Note that the above property ensures that if a message is mapped to a scalar on its own or as part of a set of messages, it will not affect the resulting scalar value.
Additionally, the new operation MUST conform to the following requirements:
- The returned scalars MUST be independent. More specifically, knowledge of any subset of the returned scalars MUST NOT reveal any information about the scalars not in that subset.
- Unique inputs MUST result in unique outputs.
- If the inputted vector of messages does not include any duplicates, the outputted scalars MUST NOT include any duplicates either.
- It MUST be deterministic and constant time on the length of the inputted vector of messages.
This section defines utility procedures that are used by the Core operations defined in (#core-operations).
This operation returns the requested number of pseudo-random scalars, using the get_random operation (see (#parameters)). The operation makes multiple calls to get_random. It is REQUIRED that each call will be independent from each other, as to ensure independence of the returned pseudo-random scalars.
Note: The security of the proof generation algorithm (ProofGen defined in (#proof-generation-proofgen)) is highly dependant on the quality of the get_random function. Care must be taken to ensure that a cryptographically secure pseudo-random generator is chosen, and that its outputs are not leaked to an adversary. See also (#randomness-requirements) for more details and guidance.
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)
This operation describes how to hash an arbitrary octet string to a scalar value in the multiplicative group of integers mod r (i.e., values in the range from 1 to r - 1). This procedure acts as a helper function, used internally in various places within the operations described in the spec.
The operation takes as input an octet string representing the octet string to hash (msg) and a domain separation tag (dst). The length of the dst MUST be less than 255 octets. See section 5.3.3 of [@!RFC9380] for guidance on using larger dst values.
Note This operation makes use of expand_message defined in [@!RFC9380]. The operation expand_message may fail (abort). In that case, hash_to_scalar MUST also ABORT.
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
This operation calculates the domain value, a scalar representing the distillation of all essential contextual information for a signature. The same domain value must be calculated by all parties (the Signer, the Prover and the Verifier) for both the signature and proofs to be validated.
The input to the domain value includes the header value chosen by the Signer to encode any information that is required to be revealed by the Prover (such as an expiration date, or an identifier for the target audience). This is in contrast to the signed message values, which may be withheld during a proof.
When a signature is calculated, the domain value is combined with a specific generator point (Q_1, see CoreSign defined in (#coresign)) to protect the integrity of the public parameters and the header.
This operation makes use of the serialize function, defined in (#serialize).
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)
Note: If the header is not supplied in calculate_domain, it defaults to the empty octet string (""). This means that in the concatenation step of the above procedure (step 3), 8 bytes representing a length of 0 (i.e., 0x0000000000000000), will still need to be appended at the end, even though a header value is not provided.
This operation describes how to transform multiple elements of different types (i.e., elements that are not already in a octet string format) to a single octet string (see (#serializing-to-octets)). The inputted elements can be points, scalars (see (#terminology)) or integers between 0 and 2^64-1. The resulting octet string will then either be used as an input to a hash function (i.e., in CoreSign (#coresign), CoreProofGen (#coreproofgen) etc.), or to serialize a signature or proof (see signature_to_octets (#signature-to-octets) and proof_to_octets (#proof-to-octets)).
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
This operation describes how to encode a signature to an octet string.
Note this operation deliberately does not perform the relevant checks on the inputs A and e because its assumed these are done prior to its invocation, e.g., as is the case with the CoreSign (#coresign) operation.
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))
This operation describes how to decode an octet string, validate it and return the underlying components that make up the signature.
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)
This operation describes how to encode as an octet string, a proof as computed by CoreProofGen in (#coreproofgen) (or, more precisely, by step 5 of the ProofFinalize operation defined in (#proof-finalization)).
The inputted proof value must consist of the following components, in that order:
- Three (3) valid points of the G1 subgroup, different from the identity point of G1 (i.e.,
Abar, Bbar, D, in ProofGen) - Three (3) integers representing scalars in the range of 1 to r - 1 inclusive (i.e.,
e^, r1^, r3^, in ProofGen). - A number of integers representing scalars in the range of 1 to r - 1 inclusive, corresponding to the undisclosed from the proof messages (i.e.,
m^_j1, ..., m^_jU, in ProofGen, where U the number of undisclosed messages). - One (1) integer representing a scalar in the range 1 to r-1 inclusive (i.e.,
cin ProofGen).
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))
This operation describes how to decode an octet string representing a proof, validate it and return the underlying components that make up the proof value.
The proof value outputted by this operation consists of the following components, in that order:
- Three (3) valid points of the G1 subgroup, each of which must not equal the identity point.
- Three (3) integers representing scalars in the range of 1 to r - 1 inclusive.
- A set of integers representing scalars in the range of 1 to r - 1 inclusive, corresponding to the undisclosed from the proof message commitments. This set can be empty (i.e., "()").
- One (1) integer representing a scalar in the range of 1 to r - 1 inclusive, corresponding to the proof's challenge (
c).
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))
This operation describes how to decode an octet string representing a public key, validates it and returns the corresponding point in G2. Steps 2 to 5 check if the public key is valid. As an optimization, implementations MAY cache the result of those steps, to avoid unnecessarily repeating validation for known public keys.
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
This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Signer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Signer. The following sections will describe possible threats, resulting from side channel information or identifying disclosed messages, that could compromise the unlinkability property of the BBS proof. Such threats, if exploited, could lead to correlation of the Prover's interactions with different Verifiers, resulting to fingerprinting attacks on the Prover's activity.
Note that, the following sections describe ways to minimize possible identifying information revealed during a BBS proof presentation. To minimize the privacy threats of an entire system, other protections may also need to be employed, for example, using an IP hiding proxy network like TOR ([@DMS04]).
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 (#proof-generation-proofgen)). 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.
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 (#total-number-and-index-of-signed-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 government IDs, email addresses, phone numbers etc. 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 (#mapping-messages-to-scalars)), 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.
Note that all core operations as defined in (#core-operations) 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 (#octets-to-public-key), 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 is the CoreSign ((#coresign)) and CoreProofGen ((#coreproofgen)) operations. An explicit invocation to the octets_to_pubkey operation is already defined and therefore required in the CoreVerify ((#coreverify)) and CoreProofVerify ((#coreproofverify)) operations.
The subgroup check subgroup_check_G* invocation during either signature deserialization (octets_to_signature, defined in (#octets-to-signature)), proof deserialization (octets_to_proof, defined in (#octets-to-proof)) or public key deserialization (octets_to_pubkey, define in (#octets-to-public-key)) 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 (#notation) 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.
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.
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.
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 (#ciphersuites).
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 (#ciphersuites) which as a curve achieves around 117 bits of security [@ZCASH-REVIEW].
The key_material input to the KeyGen operation defined in (#secret-key) 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 (#proof-generation-proofgen) 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 ((#parameters)) 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.
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], Base-64 decoding [@RFC4648] etc.,) should 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 (#defining-new-interfaces)) or unique header values (see (#signature-generation-sign)) with different pre-processing methodologies.
Note that the BBS Interface defined in this document (see (#bbs-signatures-interface)) 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 etc.,) 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 (#define-a-new-map-to-scalar) 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 (#signature-generation-sign)). 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 (#privacy-considerations) 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].
BBS Signatures compine 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 refered 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 optaining a valid BBS signature on those messages (in academic works, this is refered to as the BBS proof being a proof-of-knowledge of a BBS signature [@CDL16] [@TZ23]).
Data confidenciality 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 refered 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 Signatures. As a result, an adversary with access to such a quantum computer, will not be able to reveal neither the messages undisclosed by a BBS proof, nor the hidden signature value. 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).
This section defines the format for a BBS ciphersuite. It also gives concrete ciphersuites based on the BLS12-381 pairing-friendly elliptic curve [@I-D.irtf-cfrg-pairing-friendly-curves].
The following section defines the format of the unique identifier for the ciphersuite denoted ciphersuite_id, which will be represented as an ASCII encoded octet string. The REQUIRED format for this string is
"BBS_" || H2C_SUITE_ID || ADD_INFO
-
H2C_SUITE_ID is the suite ID of the hash-to-curve suite used to define the hash_to_curve function.
-
ADD_INFO is an optional octet string indicating any additional information used to uniquely qualify the ciphersuite. When present this value MUST only contain ASCII encoded characters with codes between 0x21 and 0x7e (inclusive) and MUST end with an underscore (ASCII code: 0x5f). The last character MUST be the only underscore.
The parameters that each ciphersuite needs to define are generally divided into three main categories; the basic parameters (a hash function etc.,), the serialization operations (point_to_octets_E1 etc.,) and the generator parameters. See below for more details.
Basic parameters:
-
hash: a cryptographic hash function.
-
octet_scalar_length: Number of bytes to represent a scalar value, in the multiplicative group of integers mod r, encoded as an octet string. It is RECOMMENDED this value be set to
ceil(log2(r)/8). -
octet_point_length: Number of bytes to represent a point encoded as an octet string outputted by the
point_to_octets_E*function. -
hash_to_curve_suite: The hash-to-curve ciphersuite id, in the form defined in [@!RFC9380]. This defines the hash_to_curve_g1 (the hash_to_curve operation for the G1 subgroup, see the Notation defined in (#notation)) and the expand_message (either expand_message_xmd or expand_message_xof) operations used in this document.
-
expand_len: Must be defined to be at least
ceil((ceil(log2(r))+k)/8), wherelog2(r)andkare defined by each ciphersuite (see Section 5 in [@!RFC9380] for a more detailed explanation of this definition). -
P1: A fixed point in the G1 subgroup, different from the point BP1 (i.e., the base point of G1, see (#terminology)). This leaves the base point "free", to be used with other protocols, like key commitment and proof of possession schemes (for example, like the one described in Section 3.3 of [@I-D.irtf-cfrg-bls-signature]).
-
h: The pairing operation used.
Serialization functions:
-
point_to_octets_E1: a function that returns the canonical representation of the point P of the E1 elliptic curve as an octet string.
-
point_to_octets_E2: a function that returns the canonical representation of the point P of the E2 elliptic curve as an octet string.
-
octets_to_point_E1: a function that returns the point P in the elliptic curve E1 corresponding to the canonical representation ostr, or INVALID if ostr is not a valid output of
point_to_octets_E1. -
octets_to_point_E2: a function that returns the point P in the elliptic curve E2 corresponding to the canonical representation ostr, or INVALID if ostr is not a valid output of
point_to_octets_E2.
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 leven 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 (#the-bls12-381-curve).
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 (#generators-calculation) 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 (#bbs-signatures-interface), 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.
Basic parameters:
-
ciphersuite_id: "BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_"
-
octet_scalar_length: 32, based on the RECOMMENDED approach of
ceil(log2(r)/8). -
octet_point_length: 48, based on the RECOMMENDED approach of
ceil(log2(p)/8). -
hash_to_curve_suite: "BLS12381G1_XOF:SHAKE-256_SSWU_RO_" as defined in Appendix A.1 for the G1 subgroup.
-
expand_len: 48 (
= ceil((ceil(log2(r))+k)/8)) -
P1: the following point of G1, serialized using the point_to_octets_E1 procedure defined by this ciphersuite and hex encoded
P1 = {{ $generatorFixtures.bls12-381-shake-256.generators.P1 }} -
h: the optimal Ate pairing (Appendix A.2 of [@I-D.irtf-cfrg-pairing-friendly-curves]), defined in (#optimal-ate-pairing).
Serialization functions:
-
point_to_octets_E1: as defined in (#point-serialization) for points of the curve
E1(which follows the format documented in Appendix C.1 of [@I-D.irtf-cfrg-pairing-friendly-curves] for theE1elliptic curve, using compression). -
point_to_octets_E2: as defined in (#point-serialization) for points of the curve
E2(which follows the format documented in Appendix C.1 of [@I-D.irtf-cfrg-pairing-friendly-curves] for theE2elliptic curve, using compression). -
octets_to_point_E1: as defined in (#point-de-serialization) (which follows the format documented in Appendix C.2 of [@I-D.irtf-cfrg-pairing-friendly-curves]), returning INVALID if the resulting point is not in
E1. -
octets_to_point_E2: as defined in (#point-de-serialization) (which follows the format documented in Appendix C.2 of [@I-D.irtf-cfrg-pairing-friendly-curves]), returning INVALID if the resulting point is not in
E2.
Basic parameters:
-
Ciphersuite_ID: "BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_"
-
octet_scalar_length: 32, based on the RECOMMENDED approach of
ceil(log2(r)/8). -
octet_point_length: 48, based on the RECOMMENDED approach of
ceil(log2(p)/8). -
hash_to_curve_suite: "BLS12381G1_XMD:SHA-256_SSWU_RO_" as defined in Section 8.8.1 of the [@!RFC9380] for the G1 subgroup.
-
expand_len: 48 (
= ceil((ceil(log2(r))+k)/8)) -
P1: the following point of G1, serialized using the point_to_octets_E1 procedure defined by this ciphersuite and hex encoded
P1 = {{ $generatorFixtures.bls12-381-sha-256.generators.P1 }} -
h: the optimal Ate pairing (Appendix A.2 of [@I-D.irtf-cfrg-pairing-friendly-curves]), defined in (#optimal-ate-pairing).
Serialization functions:
-
point_to_octets_E1: as defined in (#point-serialization) for points of the curve
E1(which follows the format documented in Appendix C.1 of [@I-D.irtf-cfrg-pairing-friendly-curves] for theE1elliptic curve, using compression). -
point_to_octets_E2: as defined in (#point-serialization) for points of the curve
E2(which follows the format documented in Appendix C.1 of [@I-D.irtf-cfrg-pairing-friendly-curves] for theE2elliptic curve, using compression). -
octets_to_point_E1: as defined in (#point-de-serialization) (which follows the format documented in Appendix C.2 of [@I-D.irtf-cfrg-pairing-friendly-curves]), returning INVALID if the resulting point is not in
E1. -
octets_to_point_E2: as defined in (#point-de-serialization) (which follows the format documented in Appendix C.2 of [@I-D.irtf-cfrg-pairing-friendly-curves]), returning INVALID if the resulting point is not in
E2.
The following section details a basic set of test vectors that can be used to confirm an implementation's correctness.
NOTE All binary data below is represented as octet strings in big endian order, encoded in hexadecimal format.
NOTE These fixtures are a work in progress and subject to change.
For the purpose of presenting fixtures for the ProofGen operation ((#proof-generation-proofgen)), we describe here a way to mock the calculate_random_scalars operation ((#random-scalars)), used by CoreProofGen ((#coreproofgen)) to create all the necessary random scalars.
To that end, the seeded_random_scalars operation is defined, which will deterministically calculate count random-looking scalars from a single SEED, given a domain separation tag (DST). The proof test vector will then define a SEED (as a nothing-up-my-sleeve value) and a DST and then set
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 ((#bls12-381-sha-256)), if more than 170 mocked random scalars are required, the operation will return INVALID. Similarly, for the BLS12-381-SHAKE-256 ciphersuite ((#bls12-381-shake-256)), if more than 1365 mocked random scalars are required, the operation will return INVALID. For the purpose of describing ProofGen ((#proof-generation-proofgen)) 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)
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 = {{ $messages[0] }}
m_2 = {{ $messages[1] }}
m_3 = {{ $messages[2] }}
m_4 = {{ $messages[3] }}
m_5 = {{ $messages[4] }}
m_6 = {{ $messages[5] }}
m_7 = {{ $messages[6] }}
m_8 = {{ $messages[7] }}
m_9 = {{ $messages[8] }}
m_10 = {{ $messages[9] }}
Test vectors of the BLS12-381-SHAKE-256 ciphersuite defined in (#bls12-381-shake-256-ciphersuite) ciphersuite. Further fixtures are available in (#bls12-381-shake-256-ciphersuite).
Following the procedure defined in (#secret-key) with an input key_material value as follows
key_material = {{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyMaterial }}
the following key_info value
key_info = {{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyInfo }}
and the following key_dst value, defined by api_id || KEYGEN_DST_, where api_id the identifier of the BBS Interface defined in (#bbs-signatures-interface), using the BLS12-381-SHAKE-256 ciphersuite defined in (#bls12-381-shake-256),
key_dst = {{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyDst }}
Outputs the following SK value
SK = {{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyPair.secretKey }}
Following the procedure defined in (#public-key) with an input SK value as above produces the following PK value
PK = {{ $KeyPairFixtures.bls12-381-shake-256.keypair.keyPair.publicKey }}
The messages in (#messages) are mapped to scalars during the Sign, Verify, ProofGen and ProofVerify operations. Presented below, are the output scalar values of the messages_to_scalars operation ((#messages-to-scalars)), on input the messages defined in (#messages). Each output scalar value is encoded to octets using I2OSP and represented in big endian order,
msg_scalar_1 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[0].scalar }}
msg_scalar_2 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[1].scalar }}
msg_scalar_3 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[2].scalar }}
msg_scalar_4 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[3].scalar }}
msg_scalar_5 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[4].scalar }}
msg_scalar_6 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[5].scalar }}
msg_scalar_7 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[6].scalar }}
msg_scalar_8 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[7].scalar }}
msg_scalar_9 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[8].scalar }}
msg_scalar_10 = {{ $MapMessageToScalarFixtures.bls12-381-shake-256.MapMessageToScalarAsHash.cases[9].scalar }}
Following the procedure defined in (#generators-calculation) with an input count value of 11, for the BLS12-381-SHAKE-256 suite, outputs the following values (note that the first one corresponds to Q_1, while the next 10, to the message generators H_1, ..., H_10).
Q_1 = {{ $generatorFixtures.bls12-381-shake-256.generators.Q1 }}
H_1 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[0] }}
H_2 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[1] }}
H_3 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[2] }}
H_4 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[3] }}
H_5 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[4] }}
H_6 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[5] }}
H_7 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[6] }}
H_8 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[7] }}
H_9 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[8] }}
H_10 = {{ $generatorFixtures.bls12-381-shake-256.generators.MsgGenerators[9] }}
This section presents test vectors for the Sign operation, as defined in (#signature-generation-sign), for the BLS12-381-SHAKE-256 ciphersuite ((#bls12-381-shake-256)).
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature001.messages[0] }}
SK = {{ $signatureFixtures.bls12-381-shake-256.signature001.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature001.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature001.header }}
B = {{ $signatureFixtures.bls12-381-shake-256.signature001.trace.B }}
domain = {{ $signatureFixtures.bls12-381-shake-256.signature001.trace.domain }}
signature = {{ $signatureFixtures.bls12-381-shake-256.signature001.signature }}
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-shake-256.signature004.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-shake-256.signature004.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature004.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature004.header }}
B = {{ $signatureFixtures.bls12-381-shake-256.signature004.trace.B }}
domain = {{ $signatureFixtures.bls12-381-shake-256.signature004.trace.domain }}
signature = {{ $signatureFixtures.bls12-381-shake-256.signature004.signature }}
This section presents test vectors for the ProofGen operation, as defined in (#proof-generation-proofgen), for the BLS12-381-SHAKE-256 ciphersuite ((#bls12-381-shake-256)).
For the generation of the following test vectors, the mocked_calculate_random_scalars defined in (#mocked-random-scalars) is used, in place of the calculate_random_scalars operation, with the following SEED value (hex encoding of the ASCII-encoded 30 first digits of pi)
SEED =
"332e313431353932363533353839373933323338343632363433333833323739"
and the domain separation tag DST = api_id || "MOCK_RANDOM_SCALARS_DST_", where api_id is the identifier of the BBS Interface defined in (#bbs-signatures-interface), i.e., api_id = ciphersuite_id || H2G_HM2S_, where ciphersuite_id is the unique identifier of the BLS12-381-SHAKE-256 ciphersuite as defined in (#bls12-381-shake-256) and "MOCK_RANDOM_SCALARS_DST_" is an ASCII string composed of 24 bytes. More specifically,
DST =
"BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_H2G_HM2S_MOCK_RANDOM_SCALARS_DST_"
Given the above SEED and DST values, the first 10 scalars (i.e., with count = 10) returned by the mocked_calculate_random_scalars operation will be,
random_scalar_1 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[0] }}
random_scalar_2 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[1] }}
random_scalar_3 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[2] }}
random_scalar_4 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[3] }}
random_scalar_5 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[4] }}
random_scalar_6 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[5] }}
random_scalar_7 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[6] }}
random_scalar_8 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[7] }}
random_scalar_9 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[8] }}
random_scalar_10 = {{ $MockRngFixtures.bls12-381-shake-256.mockedRng.mockedScalars[9] }}
m_0 = {{ $proofFixtures.bls12-381-shake-256.proof001.messages[0] }}
public_key = {{ $proofFixtures.bls12-381-shake-256.proof001.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-shake-256.proof001.signature }}
header = {{ $proofFixtures.bls12-381-shake-256.proof001.header }}
presentation_header = {{ $proofFixtures.bls12-381-shake-256.proof001.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof001.disclosedIndexes }}
random scalars:
r1 = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r1 }}
r2 = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r2 }}
e_tilde = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.e_tilde }}
r1_tilde = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.random_scalars.r1_tilde }}
r3_tilde = {{ $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 = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-shake-256.proof001.trace.domain }}
proof = {{ $proofFixtures.bls12-381-shake-256.proof001.proof }}
m_1 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-shake-256.proof002.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-shake-256.proof002.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-shake-256.proof002.signature }}
header = {{ $proofFixtures.bls12-381-shake-256.proof002.header }}
presentation_header = {{ $proofFixtures.bls12-381-shake-256.proof002.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof002.disclosedIndexes }}
random scalars:
r1 = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r1 }}
r2 = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r2 }}
e_tilde = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.e_tilde }}
r1_tilde = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.random_scalars.r1_tilde }}
r3_tilde = {{ $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 = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-shake-256.proof002.trace.domain }}
proof = {{ $proofFixtures.bls12-381-shake-256.proof002.proof }}
m_1 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-shake-256.proof003.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-shake-256.proof003.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-shake-256.proof003.signature }}
header = {{ $proofFixtures.bls12-381-shake-256.proof003.header }}
presentation_header = {{ $proofFixtures.bls12-381-shake-256.proof003.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof003.disclosedIndexes }}
random scalars:
r1 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r1 }}
r2 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r2 }}
e_tilde = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.e_tilde }}
r1_tilde = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r1_tilde }}
r3_tilde = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.r3_tilde }}
m_tilde_scalars:
m~_1 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[0] }}
m~_3 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[1] }}
m~_5 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[2] }}
m~_7 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[3] }}
m~_8 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[4] }}
m~_9 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.random_scalars.m_tilde_scalars[5] }}
T1 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-shake-256.proof003.trace.domain }}
proof = {{ $proofFixtures.bls12-381-shake-256.proof003.proof }}
Test vectors of the BLS12-381-SHA-256 ciphersuite. Further fixtures are available in (#bls12-381-sha-256-ciphersuite).
Following the procedure defined in (#secret-key) with an input key_material value as follows
key_material = {{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyMaterial }}
the following key_info value
key_info = {{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyInfo }}
and the following key_dst value, defined by api_id || KEYGEN_DST_, where api_id the identifier of the BBS Interface defined in (#bbs-signatures-interface), using the BLS12-381-SHA-256 ciphersuite defined in (#bls12-381-sha-256),
key_dst = {{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyDst }}
Outputs the following SK value
SK = {{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyPair.secretKey }}
Following the procedure defined in (#public-key) with an input SK value as above produces the following PK value
PK = {{ $KeyPairFixtures.bls12-381-sha-256.keypair.keyPair.publicKey }}
The messages in (#messages) are mapped to scalars during the Sign, Verify, ProofGen and ProofVerify operations. Presented below, are the output scalar values of the messages_to_scalars operation ((#messages-to-scalars)). Each output scalar value is encoded to octets using I2OSP and represented in big endian order,
dst = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.dst }}
The output scalars, encoded to octets using I2OSP and represented in big endian order, are the following,
msg_scalar_1 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[0].scalar }}
msg_scalar_2 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[1].scalar }}
msg_scalar_3 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[2].scalar }}
msg_scalar_4 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[3].scalar }}
msg_scalar_5 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[4].scalar }}
msg_scalar_6 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[5].scalar }}
msg_scalar_7 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[6].scalar }}
msg_scalar_8 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[7].scalar }}
msg_scalar_9 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[8].scalar }}
msg_scalar_10 = {{ $MapMessageToScalarFixtures.bls12-381-sha-256.MapMessageToScalarAsHash.cases[9].scalar }}
Following the procedure defined in (#generators-calculation) with an input count value of 11, for the BLS12-381-SHA-256 suite, outputs the following values (note that the first one corresponds to Q_1, while the next 10, to the message generators H_1, ..., H_10).
Q_1 = {{ $generatorFixtures.bls12-381-sha-256.generators.Q1 }}
H_1 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[0] }}
H_2 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[1] }}
H_3 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[2] }}
H_4 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[3] }}
H_5 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[4] }}
H_6 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[5] }}
H_7 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[6] }}
H_8 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[7] }}
H_9 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[8] }}
H_10 = {{ $generatorFixtures.bls12-381-sha-256.generators.MsgGenerators[9] }}
This section presents test vectors for the Sign operation, as defined in (#signature-generation-sign), for the BLS12-381-SHA-256 ciphersuite ((#bls12-381-sha-256)).
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature001.messages[0] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature001.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature001.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature001.header }}
B = {{ $signatureFixtures.bls12-381-sha-256.signature001.trace.B }}
domain = {{ $signatureFixtures.bls12-381-sha-256.signature001.trace.domain }}
signature = {{ $signatureFixtures.bls12-381-sha-256.signature001.signature }}
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-sha-256.signature004.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature004.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature004.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature004.header }}
B = {{ $signatureFixtures.bls12-381-sha-256.signature004.trace.B }}
domain = {{ $signatureFixtures.bls12-381-sha-256.signature004.trace.domain }}
signature = {{ $signatureFixtures.bls12-381-sha-256.signature004.signature }}
This section presents test vectors for the ProofGen operation, as defined in (#proof-generation-proofgen), for the BLS12-381-SHA-256 ciphersuite ((#bls12-381-shake-256)).
For the generation of the following test vectors, the mocked_calculate_random_scalars defined in (#mocked-random-scalars) is used, in place of the calculate_random_scalars operation, with the following SEED value (hex encoding of the ASCII-encoded 30 first digits of pi)
SEED =
"332e313431353932363533353839373933323338343632363433333833323739"
and the domain separation tag DST = api_id || "MOCK_RANDOM_SCALARS_DST_", where api_id is the identifier of the BBS Interface defined in (#bbs-signatures-interface), i.e., api_id = ciphersuite_id || H2G_HM2S_, where ciphersuite_id is the unique identifier of the BLS12-381-SHA-256 ciphersuite as defined in (#bls12-381-sha-256) and "MOCK_RANDOM_SCALARS_DST_" is an ASCII string composed of 24 bytes. More specifically,
DST =
"BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_H2G_HM2S_MOCK_RANDOM_SCALARS_DST_"
Given the above SEED and DST values, the first 10 scalars (i.e., with count = 10) returned by the mocked_calculate_random_scalars operation will be,
random_scalar_1 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[0] }}
random_scalar_2 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[1] }}
random_scalar_3 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[2] }}
random_scalar_4 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[3] }}
random_scalar_5 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[4] }}
random_scalar_6 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[5] }}
random_scalar_7 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[6] }}
random_scalar_8 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[7] }}
random_scalar_9 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[8] }}
random_scalar_10 = {{ $MockRngFixtures.bls12-381-sha-256.mockedRng.mockedScalars[9] }}
Note that the returned scalars will be unique for different count values, i.e., for different output lengths.
m_0 = {{ $proofFixtures.bls12-381-sha-256.proof001.messages[0] }}
public_key = {{ $proofFixtures.bls12-381-sha-256.proof001.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-sha-256.proof001.signature }}
header = {{ $proofFixtures.bls12-381-sha-256.proof001.header }}
presentation_header = {{ $proofFixtures.bls12-381-sha-256.proof001.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof001.disclosedIndexes }}
random scalars:
r1 = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r1 }}
r2 = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r2 }}
e_tilde = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.e_tilde }}
r1_tilde = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.random_scalars.r1_tilde }}
r3_tilde = {{ $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 = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-sha-256.proof001.trace.domain }}
proof = {{ $proofFixtures.bls12-381-sha-256.proof001.proof }}
m_1 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-sha-256.proof002.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-sha-256.proof002.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-sha-256.proof002.signature }}
header = {{ $proofFixtures.bls12-381-sha-256.proof002.header }}
presentation_header = {{ $proofFixtures.bls12-381-sha-256.proof002.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof002.disclosedIndexes }}
random scalars:
r1 = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r1 }}
r2 = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r2 }}
e_tilde = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.e_tilde }}
r1_tilde = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.random_scalars.r1_tilde }}
r3_tilde = {{ $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 = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-sha-256.proof002.trace.domain }}
proof = {{ $proofFixtures.bls12-381-sha-256.proof002.proof }}
m_1 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-sha-256.proof003.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-sha-256.proof003.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-sha-256.proof003.signature }}
header = {{ $proofFixtures.bls12-381-sha-256.proof003.header }}
presentation_header = {{ $proofFixtures.bls12-381-sha-256.proof003.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof003.disclosedIndexes }}
random scalars:
r1 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r1 }}
r2 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r2 }}
e_tilde = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.e_tilde }}
r1_tilde = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r1_tilde }}
r3_tilde = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.r3_tilde }}
m_tilde_scalars:
m~_1 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[0] }}
m~_3 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[1] }}
m~_5 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[2] }}
m~_7 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[3] }}
m~_8 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[4] }}
m~_9 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.random_scalars.m_tilde_scalars[5] }}
T1 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-sha-256.proof003.trace.domain }}
proof = {{ $proofFixtures.bls12-381-sha-256.proof003.proof }}
This document does not make any requests of IANA.
The authors would like to acknowledge the significant amount of academic work that preceeded the development of this document. In particular the original work of [@BBS04] which was subsequently developed in [@ASM06] [@CL04] [@BBDT16] [@CDL16] and in [@TZ23]. This last academic work is the one mostly used by this document.
The current state of this document is the product of the work of the Decentralized Identity Foundation Applied Cryptography Working group, which includes numerous active participants. In particular, the following individuals contributed ideas, feedback and wording that influenced this specification:
Orie Steele, Christian Paquin, Alessandro Guggino, Tomislav Markovski and Greg Bernstein.
Additionally, the authors would like to acknoledge Jacques Traore and Antoine Dumanois, for their crucial contributions to this document.
{backmatter}
The following defines a hash_to_curve suite [@!RFC9380] for the BLS12-381 curve for both the G1 and G2 subgroups using the extendable output function (xof) of SHAKE-256 as per the guidance defined in section 8.9 of [@!RFC9380].
Note the notation used in the below definitions is sourced from [@!RFC9380].
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].
This section defines BLS12-381. The definitions of this section have been originally described in [@I-D.irtf-cfrg-pairing-friendly-curves], where they are discussed in greater detail.
BLS12-381 are Barreto-Lynn-Scott curves, defined by two elliptic curves E1 and E2, parameterized by an integer t. In the case of BLS12-381, t is defined as,
t = -2^63 - 2^62 - 2^60 - 2^57 - 2^48 - 2^16
The curves E1 and E2 are defined over the finite fields GF(p) and GF(p^2) correspondingly, where p is defined as,
p = (t - 1)^2 * (t^4 - t^2 + 1) / 3 + t
Let (1, I) be the bases of the finite field GF(p^2), where I ^ 2 + 1 = 0 in GF(p^2). We will denote an element y of GF(p^2) as a tuple y = (y_0, y_1), where y_0 and y_1 elements of GF(p) for which it holds y = y_0 * 1 + y_1 * I. The two elliptic curves are defined by the following equations,
E1: y ^ 2 = x ^ 3 + 4
E2: y ^ 2 = x ^ 3 + 4 * (I + 1)
The group G1 and G2 are defined as the the order r subgroup of E1 defined over GF(p) and E2 defined over GF(p^2) correspondingly, where r is defined as,
r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
Note that r is a prime factor of p. The target group G_T is defined as the finite group GF(p^12) minus the element 0.
The base points of BLS12-381, encoded to octets using the procedure defined in (#point-serialization) and then represented in hexadecimal format, are defined as,
BP1 = "97f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586
c55e83ff97a1aeffb3af00adb22c6bb"
BP2 = "93e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f50493
34cf11213945d57e5ac7d055d042b7e024aa2b2f08f0a91260805272dc51051c6
e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb8"
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 ((#the-bls12-381-curve)) 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
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 (#bls12-381-ciphersuites), 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) ofx. - On input an element
yofGF(p)orGF(p^2),sqrt(y)will return the square root of that element in the respective group, i.e., an elementasuch thata^2 = y, or INVALID. - For clarity, we will use
Identity_E1,Identity_E2to denote the identity points ofE1andE2correspondingly (note thatIdentity_E1is the same point asIdentity_G1andIdentity_E2is the same point asIdentity_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
Let P = (x, y) the point to be serialized.
Compute three metadata bits C_bit, I_bit, and S_bit, as follows,
C_bitis set to 1 (indicating that point compression is used).I_bitis 1 ifPis either theIdentity_E1orIdentity_E2points, otherwise it is 0.S_bitis 0 ifI_bitis 1 (again note that the ciphersuites described in this document always use point compression). Otherwise (i.e., when point compression is used andPis not the identity point of its respective curve), ifPis a point onE1, setS_bit = sign_GF_p(y), else ifPis a point onE2,S_bit = sign_GF_p^2(y).
Let m = (C_bit * 2^7) + (I_bit * 2^6) + (S_bit * 2^5) and set m_byte = I2OSP(m, 1). Define x_string as follows,
- If
P = Identity_E1, setx_string = I2OSP(0, 48). - If
Pis a point onE1andP != Identity_E1, setx_string = I2OSP(x, 48). - If
P = Identity_E2, setx_string = I2OSP(0, 96). - If
Pis a point onE2andP != Identity_E2, then letx_0andx_1elements ofGF(p)such thatx = (x_0, x_1)and setx_string = I2OSP(x_1, 48) || I2OSP(x_0, 48).
Let s_string = x_string. Set s_string[0] = x_string[0] OR m_byte, where OR is computed for each bit. Output s_string as the serialization result of the point P.
Let m_byte = s_string[0] AND 0xE0, where AND is computed bitwise. If m_byte equals 0x20 or 0x60 or 0xE0, output INVALID and abort the operation. Otherwise, let C_bit equal the most significant bit of m_byte, I_bit equal the second most significant bit of m_byte, and S_bit equal the third most significant bit of m_byte. If C_bit is 0 return INVALID and abort the operation (note again that we only consider compressed encoding).
-
Determine the curve of the encoded point as follows,
- If
s_stringhas length 48 octets, the encoded point is on the curveE1. - If
s_stringhas length 96 octets, the encoded point is on the curveE2. - If
s_stringhas any other length, output INVALID and abort the operation.
- If
-
Let
s_string[0] = s_string[0] AND 0x1F, whereANDis computed bitwise (this will set the three most significant bits ofs_string[0]to 0). -
If
I_bitis 1, then the encoded point must be the Identity point of the curve determined on step 1. Ifs_stringis not the all zeros string, output INVALID and abort the operation. Otherwise, output the Identity point of the curve that was determined in step 1 (i.e., eitherIdentity_E1orIdentity_E2). -
Let
x = OS2IP(s_string). -
If the curve that was determined in step 1 is
E1,- Let
y2 = x^3 + 4inGF(p). - If
y2is not square inGF(p), output INVALID and abort the operation. Otherwise, lety = sqrt(y2)inGF(p)and setY_bit = sign_GF_p(y).
- Let
-
If the curve that was determined in step 1 is
E2,- Let
y2 = x^3 + 4 * (I + 1)inGF(p^2). - If
y2is not square inGF(p^2), output INVALID and abort the operation. Otherwise, lety = sqrt(y2)inGF(p^2)and setY_bit = sign_GF_p^2(y).
- Let
-
If
S_bitequalsY_bit, outputP = (x, y). Otherwise, outputP = (x, -y).
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.
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 ofter 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.
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.
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-shake-256.signature010.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-shake-256.signature010.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature010.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature010.header }}
B = {{ $signatureFixtures.bls12-381-shake-256.signature010.trace.B }}
domain = {{ $signatureFixtures.bls12-381-shake-256.signature010.trace.domain }}
signature = {{ $signatureFixtures.bls12-381-shake-256.signature010.signature }}
The following fixture should fail signature validation due to the message value being different from what was signed.
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature002.messages[0] }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature002.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature002.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to an additional message being supplied that was not signed.
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature003.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature003.messages[1] }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature003.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature003.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to missing messages that were originally present during the signing (the presented signature was generated with all the messages in (#messages) as input).
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature005.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature005.messages[1] }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature005.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature005.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to messages being re-ordered from the order in which they were signed.
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-shake-256.signature006.messages[9] }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature006.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature006.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to public key used to verify is in-correct.
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-shake-256.signature007.messages[9] }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature007.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature007.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to header value being modified from what was originally signed.
m_1 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-shake-256.signature008.messages[9] }}
PK = {{ $signatureFixtures.bls12-381-shake-256.signature008.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-shake-256.signature008.header }}
signature = {{ $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 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-shake-256.proof014.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-shake-256.proof014.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-shake-256.proof014.signature }}
header = {{ $proofFixtures.bls12-381-shake-256.proof014.header }}
presentation_header = {{ $proofFixtures.bls12-381-shake-256.proof014.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof014.disclosedIndexes }}
T1 = {{ $proofFixtures.bls12-381-shake-256.proof014.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-shake-256.proof014.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-shake-256.proof014.trace.domain }}
proof = {{ $proofFixtures.bls12-381-shake-256.proof014.proof }}
m_1 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-shake-256.proof015.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-shake-256.proof015.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-shake-256.proof015.signature }}
header = {{ $proofFixtures.bls12-381-shake-256.proof015.header }}
presentation_header = {{ $proofFixtures.bls12-381-shake-256.proof015.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-shake-256.proof015.disclosedIndexes }}
T1 = {{ $proofFixtures.bls12-381-shake-256.proof015.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-shake-256.proof015.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-shake-256.proof015.trace.domain }}
proof = {{ $proofFixtures.bls12-381-shake-256.proof015.proof }}
Using the following input message,
msg = {{ $H2sFixture.bls12-381-shake-256.h2s.message }}
And following dst value,
dst = {{ $H2sFixture.bls12-381-shake-256.h2s.dst }}
We get the following scalar output from hash_to_scalar ((#hash-to-scalar)), encoded with I2OSP and represented in big endian order,
scalar = {{ $H2sFixture.bls12-381-shake-256.h2s.scalar }}
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-sha-256.signature010.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature010.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature010.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature010.header }}
B = {{ $signatureFixtures.bls12-381-sha-256.signature010.trace.B }}
domain = {{ $signatureFixtures.bls12-381-sha-256.signature010.trace.domain }}
signature = {{ $signatureFixtures.bls12-381-sha-256.signature010.signature }}
The following fixture should fail signature validation due to the message value being different from what was signed.
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature002.messages[0] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature002.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature002.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature002.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to an additional message being supplied that was not signed.
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature003.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature003.messages[1] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature003.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature003.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature003.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to missing messages that were originally present during the signing (the presented signature was generated with all the messages in (#messages) as input).
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature005.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature005.messages[1] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature005.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature005.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature005.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to messages being re-ordered from the order in which they were signed.
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-sha-256.signature006.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature006.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature006.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature006.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to public key used to verify is in-correct.
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-sha-256.signature007.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature007.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature007.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature007.header }}
signature = {{ $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 }}
The following fixture should fail signature validation due to header value being modified from what was originally signed.
m_1 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[0] }}
m_2 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[1] }}
m_3 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[2] }}
m_4 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[3] }}
m_5 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[4] }}
m_6 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[5] }}
m_7 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[6] }}
m_8 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[7] }}
m_9 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[8] }}
m_10 = {{ $signatureFixtures.bls12-381-sha-256.signature008.messages[9] }}
SK = {{ $signatureFixtures.bls12-381-sha-256.signature008.signerKeyPair.secretKey }}
PK = {{ $signatureFixtures.bls12-381-sha-256.signature008.signerKeyPair.publicKey }}
header = {{ $signatureFixtures.bls12-381-sha-256.signature008.header }}
signature = {{ $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 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-sha-256.proof014.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-sha-256.proof014.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-sha-256.proof014.signature }}
header = {{ $proofFixtures.bls12-381-sha-256.proof014.header }}
presentation_header = {{ $proofFixtures.bls12-381-sha-256.proof014.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof014.disclosedIndexes }}
T = {{ $proofFixtures.bls12-381-sha-256.proof014.trace.T }}
domain = {{ $proofFixtures.bls12-381-sha-256.proof014.trace.domain }}
challenge = {{ $proofFixtures.bls12-381-sha-256.proof014.trace.challenge }}
proof = {{ $proofFixtures.bls12-381-sha-256.proof014.proof }}
m_1 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[0] }}
m_2 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[1] }}
m_3 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[2] }}
m_4 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[3] }}
m_5 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[4] }}
m_6 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[5] }}
m_7 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[6] }}
m_8 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[7] }}
m_9 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[8] }}
m_10 = {{ $proofFixtures.bls12-381-sha-256.proof015.messages[9] }}
public_key = {{ $proofFixtures.bls12-381-sha-256.proof015.signerPublicKey }}
signature = {{ $proofFixtures.bls12-381-sha-256.proof015.signature }}
header = {{ $proofFixtures.bls12-381-sha-256.proof015.header }}
presentation_header = {{ $proofFixtures.bls12-381-sha-256.proof015.presentationHeader }}
revealed_indexes = {{ $proofFixtures.bls12-381-sha-256.proof015.disclosedIndexes }}
T1 = {{ $proofFixtures.bls12-381-sha-256.proof015.trace.T1 }}
T2 = {{ $proofFixtures.bls12-381-sha-256.proof015.trace.T2 }}
domain = {{ $proofFixtures.bls12-381-sha-256.proof015.trace.domain }}
proof = {{ $proofFixtures.bls12-381-sha-256.proof015.proof }}
Using the following input message,
msg = {{ $H2sFixture.bls12-381-sha-256.h2s.message }}
And following dst value,
dst = {{ $H2sFixture.bls12-381-sha-256.h2s.dst }}
We get the following scalar output from hash_to_scalar ((#hash-to-scalar)), encoded with I2OSP and represented in big endian order,
scalar = {{ $H2sFixture.bls12-381-sha-256.h2s.scalar }}
The following section provides a high-level explanation of how the CoreProofGen and CoreProofVerify operations work, as presented in Appendix B of [@TZ23] and used by this document. The CoreProofGen procedure uses a generic non-interactive zero-knowledge proof-of-knowledge (NIZK) protocol, executed between a Prover and a Verifier. A NIZK works as follows; Assume the group points J_0, J_1, ..., J_n and the exponents e_0, e_1, ..., e_n. Assume also that all the group points are publicly known, while only the exponent e_0 is known to the Verifier of the NIZK and the exponents e_1, ..., e_n are known only by the Prover of the protocol. The NIZK can be used to prove a relationship of the form,
J_O * e_0 = J_1 * e_1 + J_2 * e_2 + ... + J_n * e_n
While revealing nothing about the secret exponents (i.e., e_1, ..., e_n), other than the fact that the Prover knows them.
For BBS, let the Prover be in possession of a BBS signature (A, e) on messages msg_1, ..., msg_L and a domain value (see CoreSign defined in (#coresign)). Let A = B * (1/(e + SK)) where SK the Signer's secret key and,
[1] B = P1 + Q_1 * domain + H_1 * msg_1 + ... + H_L * msg_L
Let (i1, ..., iR) be the indexes of the messages the Prover wants to disclose and (j1, ..., jU) be the indexes corresponding to undisclosed messages (i.e., (j1, ..., jU) = (1, 2, ..., L) \ (i1, ..., iR)). To prove knowledge of a signature on the disclosed messages, work as follows;
-
Prove possession of a valid signature. As defined above, a signature
(A, e), on messagesmsg_1, ..., msg_Lis valid ifA = B * 1/(e + SK), whereBas in [1]. However, the Prover cannot reveal neitherA,enorBto the Verifier (signature is uniquely identifiable andBwill reveal information about the signed messages, even the undisclosed ones). To get around this, the Prover needs to hide the signature(A, e)and the value ofB, in a way that will allow proving knowledge of such elements with the aforementioned relationship (i.e., thatA = B * 1/(e + SK)), without revealing their value. The Prover will do this by randomizing them. To do that, they take uniformly randomr1, r2in[1, r-1], and calculate,[2] Abar = A * (r1 * r2) [3] D = B * r2 [4] Bbar = D * r1 + Abar * (-e)The values
(Abar, D, Bbar)will be part of the proof and are used to prove possession of a BBS signature, without revealing the signature itself. Note that; ifAbarandBbarare constructed using a valid BBS signature as above, thenAbar * SK = Bbarwhich is equivalent toh(Abar, PK) = h(Bbar, BP2), whereSK,PKthe Signer's secret and public key andBP2the base generator ofG2(used to create the Signer’sPK, see (#public-key)). This last equation is something that the Verifier can check using the Signer'sPK. -
Prove that the disclosed messages are signed as part of that signature. The Prover will start by setting the following,
[5] r2' = (1 / r2) mod rIf the
Abar,DandBbarvalues are constructed using a valid BBS signature as in [2], [3] and [4], then the following will hold,[6] P1 + Q_1 * domain + H_i1 * msg_i1 + ... + H_iR * msg_iR = D * r2' - H_ji * msg_j1 - ... - H_jU * msg_jU
Note that the Verifier will know the elements in the left side of [6] (i.e., P1, Q_1, H_i1, ..., H_iR and the disclosed messages: msg_i1, ..., msg_iR) as well as the base points of the right side (i.e., the points D and H_j1, ..., H_jU). They will not however know the exponents on the right side of [6] (i.e., r2' and the undisclosed messages: msg_j1, ..., msg_jU). The same holds for equation [4] where the Verifier will know the left side of the equation (i.e., Bbar) and the base points of the right side (i.e., D and Abar) but not the exponents (i.e., r1 and -e).
To convince the Verifier that both [4] and [6] hold, the Prover can use a NIZK, to prove that they know the exponents that satisfy those equations, without disclosing them.
Note that if the value D is constructed correctly (as in [3]), then B = D * r2'. Proving knowledge of [6] corresponds to proving knowledge of r2', which means that the Prover does actually know a value B = D * r2'. If [6] holds, then that B value that the Prover knows (i.e., D * r2') will also have the "correct form" for B (as in [1]), including all (the disclosed and "some" undisclosed) messages.
All that remains is proving that this B value the Prover knows, is also "signed" by the Signer i.e., that the Prover also knows values A and e, such that A = B * 1/(e + SK) or, equivalently, that h(A, PK + BP2 * e) = h(B, BP2), which is what CoreVerify checks to validate a signature (see (#coreverify)).
Note that, the Prover will use a NIZK to showcase (among other things), knowledge of values r1 and e so that [4] holds (Bbar, D and Abar will be part of the proof and hence known to the Verifier). Setting r1' = (1 / r1) mod r (note that proving knowledge of r1 indirectly proves knowledge of r1' as well), using [4] and the fact that h(Abar, PK) = h(Bbar, BP2) we can get that,
h(Abar * r1' * r2', PK + BP2 * e) = h(D * r2', BP2) = h(B, BP2)
Note that the above is what CoreVerify checks, for A = Abar * r1' * r2'. Since the Prover showcased knowledge of r1' and r2' and revealed Abar as part of the proof, the Verifier can be assured that the Prover knows the value A = Abar * r1' * r2'. So setting A = Abar * r1' * r2', the values A, e, B that the Prover showed knowledge of, will form a valid BBS signature. Note that the Verifier doesn't know A (since they don't know r1' and r2'), e or B (since they don't know r2' or the undisclosed messages). However, they know that the prover knows them and as we saw above, these values form a valid signature on (among others) the disclosed messages.
To sum up; in order to validate the proof, a Verifier checks that h(Abar, PK) = h(Bbar, BP2) and verifies the NIZK. Validating the proof will guarantee the authenticity and integrity of the disclosed messages, as well as knowledge of the undisclosed messages and of the signature.
-00
- Initial version
-01
- Populated fixtures
- Added SHA-256 based ciphersuite
- Fixed typo in ProofVerify
- Clarify ASCII string usage in DST
- Added MapMessageToScalar test vectors
- Fix typo in ciphersuite name
-02
- Variety of editiorial clarifications
- Clarified integer endianness
- Revised the encode for hash operation
- Shifted to using CSPRNG instead of PRF
- Removed total number of messages from proof verify operation
- Added deterministic proof fixtures
- Shifted to multiple CSPRNG calls to calculate random elements, instead of expand_message
- Updated hash_to_scalar to a single output
-03
- Updated core operation based on new academic paper
- Variety of editorial updates
- Updated exception and error handling
- Added extension point for the operation with which the generators are created, allowing ciphersuites to define different operations for creating the generator points.
- Added extension point for the operation with which the input messages are mapped to scalar values, allowing ciphersuites to define different message-to-scalar mapping operations
- Added signature/proof fixtures with an empty header or an empty presentation header input
- Updated the fixtures to use variable length messages (one of which is now the empty message "")
-04
- Restructure Proof Generation and Verification operation to different subroutines.
- Separate high-level (Interface) operations from low-level (Core) operations.
- Update the ciphersuite ID to remove from it the
create_generatorsandmap_message_to_scalarIDs, since those are defined as part of the high-level interface instead of the ciphersuite. - Add a
commitmentoptional value to theCoreSignoperation. Thecommitmentvalue is added to allow using BBS as part of other protocols but is ignored in this document. - Update test-vectors display.
-05
- Proof Generation and Verification operations updated based on Appendix B of [@TZ23].
- Test vectors updated based on the new proof generation procedure.
- Removed the optional
commitmentvalue from theCoreSignoperation, as the intended use case (blind signatures) will be addressed differently and in another document. - Changed the reference to [@I-D.irtf-cfrg-pairing-friendly-curves] from Normative to Informative, by re-defining the relevant functionality to this document.
- Various editorial updates.
-06
- To support bounded memory implementations, the order of the inputs to the digest operation for the calculation of the
evalue duringCoreSignand thechallengevalue duringCoreProofGenandCoreProofVerifywas updated. - Updated the test vectores to match the above update.
- Renamed the pairing function from
etoh, to avoid naming collisions with the scalar component of the signature. - Renamed
signature_dst,challenge_dstanddomain_dsttohash_to_scalar_dst.
-07
- Editorial fixes (nizk -> NIZK, clarified scalar multiplication in Notation Section).
- Removed "subject to change" warning on additional test vectors.
- Fixed proof deserialization error.
- Fixed order of inputs in
CoreSigncall. - Fixed wrong inputs in
calculate_domaincall inCoreSignandCoreVerify.