From 9f1efa12fa1b378cf9661133b06f87f6a8869e85 Mon Sep 17 00:00:00 2001 From: Vasilis Kalos Date: Mon, 16 Dec 2024 17:31:02 +0200 Subject: [PATCH] Address crypto panel review comments --- draft-irtf-cfrg-bbs-signatures.md | 101 +++++++++++++++++------------- 1 file changed, 57 insertions(+), 44 deletions(-) diff --git a/draft-irtf-cfrg-bbs-signatures.md b/draft-irtf-cfrg-bbs-signatures.md index a9447764..a882b4dc 100644 --- a/draft-irtf-cfrg-bbs-signatures.md +++ b/draft-irtf-cfrg-bbs-signatures.md @@ -50,7 +50,7 @@ organization = "CryptID" .# 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. +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} @@ -60,11 +60,11 @@ A digital signature scheme is a fundamental cryptographic primitive that is used 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). +**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. +**Unlinkable Proofs** - The proofs generated by the scheme are zero-knowledge, proofs of knowledge of the signature, meaning a verifying party in receipt of a proof is unable to determine which signature was used to generate the proof, removing a common source of correlation. In general, the value of 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)). +**Proof of Possession** - The proofs generated by the scheme prove to a Verifier that the party who generated the proof (Prover) was in possession of a signature without revealing it. The scheme also supports binding a `presentation_header` to the generated proof, which acts as a message signed by the Prover. The `presentation_header` can include arbitrary information such as a cryptographic nonce, an audience/domain identifier and or time based validity information (for more details on the `presentation_header`, see (#header-and-presentation-header-usage)). Refer to the (#use-cases) for an elaboration on situations where these properties are useful. @@ -160,10 +160,10 @@ 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. +: An operation that transforms a non-negative integer into an octet string, defined in Section 4 of [@!RFC8017]. The output of this operation is in big-endian order. OS2IP -: An operation that transforms a octet string into an non-negative integer, defined in Section 4 of [@!RFC8017]. Note, the input of this operation must be in big-endian order. +: An operation that transforms a octet string into an non-negative integer, defined in Section 4 of [@!RFC8017]. The input of this operation must be in big-endian order. INVALID, ABORT : Error indicators. INVALID refers to an error encountered during the Deserialization or Procedure steps of an operation. An INVALID value can be returned by a subroutine and handled by the calling operation. ABORT indicates that one or more of the initial constraints defined by the operation are not met. In that case, the operation will stop execution. An operation calling a subroutine that aborted must also immediately abort. @@ -176,7 +176,7 @@ 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. +: Denotes the difference of the two sets I and J, i.e., all the elements of I that do not appear in J, in the same order as they were in I. X\[a..b\] : Denotes a slice of the array `X` containing all elements from and including the value at index `a` until and including the value at index `b`. Note when this syntax is applied to an octet string, each element in the array `X` is assumed to be a single byte. @@ -213,6 +213,9 @@ Identity\_G1, Identity\_G2, Identity\_GT hash\_to\_curve\_g1(ostr, dst) -> P : A cryptographic hash function that takes an arbitrary octet string as input and returns a point in G1, using the hash\_to\_curve operation defined in [@!RFC9380] and the inputted dst as the domain separation tag for that operation (more specifically, the inputted dst will become the DST parameter for the hash\_to\_field operation, called by hash\_to\_curve). +expand_message(msg, dst, len) -> ostr +: returns a uniformly random octet string of `len` octets, deterministically on input a message `msg` to be hashed as an octet string, another octet string representing a domain separation tag `dst` and the number of octets to be returned (`len`). + point\_to\_octets\_E1(P) -> ostr, point\_to\_octets\_E2(P) -> ostr : returns the canonical representation of the point P of the elliptic curve E1 or E2 as an octet string. This operation is also known as serialization. Note that we assume that when the point is valid, all the serialization operations will always succeed to return the octet string representation of the point. @@ -255,8 +258,6 @@ The schemes operations defined in this section depend on the following parameter * 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). - ## Interfaces The BBS signature scheme is organized as follows: @@ -264,7 +265,9 @@ 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: +Together with a set of utility procedures, defining functionality that is common between different interface procedures or core operations, a full BBS Signatures deployment can be defined. + +Each of the core operations (see (#core-operations)) expects 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: 1. Create the necessary generators. 2. Map the inputted messages to scalars. @@ -275,7 +278,7 @@ This allows for extensibility of the core scheme without exposing the resulting ### Subgroup Selection -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. +For defining BBS signatures there are two possible variations regarding the subgroup selection, namely where public keys are defined in G2 and signatures in G1 OR the opposite where public keys are defined in G1 and signatures in G2. Some pairing-based digital signature schemes such as [@I-D.irtf-cfrg-bls-signature] elect to allow for both variations, because they optimize for different use cases. However, in case of BBS Signatures, due to the operations involved in both signature and proof generation being computational inefficient when performed in G2 and in the pursuit of simplicity, the BBS Signatures scheme as defined in this document is limited to a construction where public keys are in G2 and signatures in G1. ### Generators @@ -285,7 +288,7 @@ Aside from the message generators, the scheme uses one additional generator `Q_1 ### Messages -In this document, the messages to be signed are defined as octet-strings. Each message must be mapped to a scalar value before passed to one of the core BBS operations ((#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. +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. ### Indexing of Arrays @@ -321,10 +324,14 @@ Those rules will be used explicitly on every operation. See also `serialize` def ### Header and Presentation Header Usage -There are two special values defined by the BBS Scheme; the `header` and the `presentation_header`. The `header` value is chosen by the Signer and is bound to both a BBS signature and 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). +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 were 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). +### Unlinkability + +As mentioned in the Introduction, a BBS proof is unlinkable. In this section we will define the term in more detail. Formally, we use unlinkability to refer to the fact that a BBS proof is zero-knowledge (TODO: ADD REFERENCE). In practice, this guarantees that an adversary (a Verifier, the Issuer or coalitions between one or more Verifiers and the Issuer) will not be able to infer any information from the BBS proof value, other than what the Prover decided to provide, even with access to multiple proof values. Consequently, the Verifier will not be able to corelate multiple proofs generated by the same signature or Prover. Note however, that this holds only for the value of the BBS proof. In other words, other values that the Prover may decide to disclose during their interaction with a prover Verifier, may still be used to corelate their activity and compromise their privacy. Such values include the disclosed messages (if the same message of high enough entropy is revealed between multiple proofs), the `header` or `presentation_header` values (see Section (#header-and-presentation-header-usage)) etc.. See Section (#privacy-considerations) for privacy considerations and recommendations on minimizing these sources of correlation. + ## Key Generation Operations ### Secret Key @@ -387,7 +394,7 @@ Procedure: ## BBS Signatures Interface -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. +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, @@ -395,11 +402,11 @@ 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)). +where `ciphersuite_id` is defined by the ciphersuite and "H2G_HM2S_" is an ASCII string comprised of 9 bytes, wherein "H2G_" refers to the identifier of the `create_generators` operation used (see (#generators-calculation)) and "HM2S_" is the identifier of the used `messages_to_scalars` mapping (see (#messages-to-scalars)). ### Signature Generation (Sign) -The Sign operation returns a BBS signature from a secret key (SK), over a header and a set of messages. +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) @@ -419,7 +426,7 @@ Inputs: Parameters: - api_id, the octet string ciphersuite_id || "H2G_HM2S_", where - ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_"is + ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_" is an ASCII string comprised of 9 bytes. Outputs: @@ -439,7 +446,7 @@ Procedure: ### Signature Verification (Verify) -The Verify operation validates a BBS signature, given a public key (PK), a header and a set of messages. +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) @@ -459,7 +466,7 @@ Inputs: Parameters: - api_id, the octet string ciphersuite_id || "H2G_HM2S_", where - ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_"is + ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_" is an ASCII string comprised of 9 bytes. Outputs: @@ -478,9 +485,9 @@ Procedure: ### Proof Generation (ProofGen) -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. +The ProofGen operation creates a BBS proof, which is a zero-knowledge, proof-of-knowledge of a BBS signature, while optionally disclosing any subset of the signed messages. Validating the proof (see ProofVerify defined in (#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. +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) @@ -494,7 +501,7 @@ Inputs: - 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 +- 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 @@ -507,7 +514,7 @@ Inputs: Parameters: - api_id, the octet string ciphersuite_id || "H2G_HM2S_", where - ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_"is + ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_" is an ASCII string comprised of 9 bytes. Outputs: @@ -527,7 +534,7 @@ Procedure: ### Proof Verification (ProofVerify) -The ProofVerify operation validates a BBS proof, given the Signer's public key (PK), a header and presentation header values, the disclosed messages and the indexes those messages had in the original vector of signed messages. +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, @@ -543,7 +550,7 @@ Inputs: - 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 +- 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 @@ -557,7 +564,7 @@ Inputs: Parameters: - api_id, the octet string ciphersuite_id || "H2G_HM2S_", where - ciphersuite_id is defined by the ciphersuite and "H2G_HM2S_"is + 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. @@ -601,7 +608,7 @@ Furthermore, all core operations accept the Signer's public key (`PK`) as well a ### CoreSign -This operation computes a deterministic signature from a secret key (`SK`), a set of `generators` (points of G1) and optionally a `header` and a vector of `messages`. +This operation computes a deterministic signature from a secret key (`SK`), a set of `generators` (points of G1) and optionally a `header` and a vector of `messages`. Note that signature generation is deterministic, in contrast to the academic literature, where signature generation, and more specifically the calculation of the e value (Procedure step 2 bellow), is randomized (i.e., the `e` value is drawn at random, instead of been deterministically calculated by hashing the Signer's secret key and the list of messages). This alteration not only protects the scheme (at least the signature generation part) from vulnerabilities related to bad entropy sources, it also makes testing of the `CoreSign` operation easier. ``` signature = CoreSign(SK, PK, generators, header, messages, api_id) @@ -709,7 +716,7 @@ Procedure: ### CoreProofGen -This operation computes a zero-knowledge proof-of-knowledge of a signature, while optionally selectively disclosing from the original set of signed messages. The Prover may also supply a presentation header (`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. +This operation computes a zero-knowledge proof-of-knowledge of a signature, while optionally selectively disclosing from the original set of signed messages. The Prover may also supply a `presentation_header` (denoted as `ph` on the input definitions of the `CoreProofGen` operation). See (#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). @@ -731,7 +738,7 @@ Inputs: - 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 +- 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. @@ -788,7 +795,7 @@ Procedure: ### CoreProofVerify -This operation checks that a `proof` is valid for a `header`, vector of disclosed messages (`disclosed_messages`) along side their index corresponding to their original position when signed (`disclosed_indexes`) and presentation header (`ph`) against a public key (`PK`). +This operation checks that a `proof` is valid for a `header`, vector of disclosed messages (`disclosed_messages`) along side their index corresponding to their original position when signed (`disclosed_indexes`) and `presentation_header` (denoted as `ph` on the input definitions of the `CoreProofVerify` operation) against a public key (`PK`). The inputted disclosed messages (`disclosed_messages`) MUST be supplied to this operation in the same order as they had as part of the `messages` input of the `CoreSign` operation defined in (#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. @@ -808,7 +815,7 @@ Inputs: - 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 +- 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 @@ -1061,14 +1068,14 @@ Procedure: 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`). +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` (denoted as `ph` on the inputs of the `ProofChallengeCalculate` operation). At a high level, the challenge will be calculated as the digest (using `hash_to_scalar` defined in (#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_indexes` list, followed by the corresponding disclosed message (i.e., if `disclosed_indexes = [i1, i2]` and `disclosed_messages = [msg_i1, msg_i2]`, the input to the challenge digest, after `R`, will include `i1 || msg_i1 || i2 || msg_i2`). - The points `Abar, Bbar, D, T1, T2` and the `domain` scalar, calculated during the proof initialization phase of `CoreProofGen` (see (#coreproofgen)). -- The inputted presentation header (`ph`) values. +- The inputted `presentation_header` (`ph`) values. This operation makes use of the `serialize` function, defined in (#serialize). @@ -1123,7 +1130,7 @@ Procedure: 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). +**Note**: If the `presentation_header` (`ph`) is not supplied in `ProofChallengeCalculate`, 8 bytes representing a length of 0 (i.e., `0x0000000000000000`), must still be appended after the `serialize(c_arr)` value, during the concatenation step of the above procedure (step 2). ## Defining New Interfaces @@ -1375,7 +1382,7 @@ This operation calculates the domain value, a scalar representing the distillati 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. +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). @@ -1421,7 +1428,7 @@ Procedure: 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. +**Note**: If the `header` is not supplied in `calculate_domain`, it defaults to the empty octet string (""). This means that in the concatenation step of the above procedure (step 3), 8 bytes representing a length of 0 (i.e., `0x0000000000000000`), will still need to be appended at the end, even though a header value is not provided. ### Serialization @@ -1662,9 +1669,15 @@ Procedure: # Privacy Considerations -This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Signer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Signer. 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. +This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Signer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Signer. Bear in mind that, those gurantees consearn only the proof value, as outputed by the `CoreProofGen` (Section (#coreproofgen)) and ofcourse the `ProofGen` (Section (#proof-generation-proofgen)) operations. Correspondingly, the unlinkability property does not include other values that a Prover could either knowngly or unkowngly provide to a Verifier. Those values can include some of the disclsed messages, the `header` and `presentation_header` values, their network address etc.. Such threats, if exploited, could lead to correlation of the Prover's interactions with different Verifiers, resulting to fingerprinting attacks against the Prover's activity. + +The following sections will describe possible privacy threats, resulting from such values and side chanells, that could compromise the unlinkability property of the BBS proof. Note that, the following sections describe ways to minimize possible identifying information revealed during a BBS proof presentation, related to the BBS Signatures scheme. To minimize the privacy threats of an entire system, other protections may also need to be employed, for example, using an IP hiding proxy network like TOR ([@DMS04]). + +## Header and Presentation Header + +As mentioned in Section (#header-and-presentation-header), the `header` value is chosen by the Signer and bound to a BBS Signature and proof. Consequently, it must be revealed to the Verifier, together with a BBS proof. If that `header` value is chosen to have high entropy (i.e., unique per credentiak, Prover or small group of Provers), it can be used as a corelation vector to trace and link together all BBS proofs made by a signature bound to that `header` value. This will result to significantly worst privacy gurantees, by allowing adveraries to trace and link together all generated proofs bound to that `header` value (for example, if a random `header` is used during each BBS signature generation, adversaries will be able to link and trace the BBS proofs generated from that signature). The Issuer MUST choose a low entropy `header` value and it MUST be the same for a large number of users (Provers). Acceptable values include an application identifier, a country identifier etc.. Anacceptable values include random values, high cardinality expiration dates, the Prover's email address etc.. -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]). +On the other hand, the missuss of a `presentation_header`, chosen by the Prover and only bound to a BBS proof, does not provide as many privacy risks as the `header` value. For example, since a new `presentation_header` can be chosen each time a BBS proof is generated, random values are a viable choise. Still, to not break the unlinkability property, care must be taken that the `presentation_header` does not identify a single or small group of Provers. Acceptable values include random octet strings (possibly received from the Verifier, prior to the generation of the BBS proof), or more generally, any message the Prover may want to protect its integrity when presenting a BBS proof (note that the `presentation_header` value, when used, can be considered as "signed" by the Prover). Anacceptable values include the Prover's phone number, their complete physical adress, their date of their birth etc.. ## Total Number and Index of Signed Messages @@ -1684,7 +1697,7 @@ For certain types of message values, set membership proofs (for example, [@VB22] ## Validating Public Keys -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. +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. In case that the required checks for the validity of the Signer's public key are not performed, the results are unpredicted, causing unexpected vulnerabilities (for example, the output of the pairing operation on input an invalid elliptic curve point can be highly iregural and implementation dependant, with some returning the identity point of the elliptic curve and others returnong errors). ## Skipping Membership Checks @@ -1698,7 +1711,7 @@ There are two places where side channel attacks could be relevant in the BBS Sig ## Presentation Header Selection -The signature proofs of knowledge generated in this specification are created using a specified presentation header. A Verifier-specified cryptographically random value (e.g., a nonce) featuring in the presentation header provides strong protections against replay attacks, and is RECOMMENDED in most use cases. In some settings, proofs can be generated in a non-interactive fashion, in which case verifiers MUST be able to verify the uniqueness of the presentation header values. +The signature proofs of knowledge generated in this specification are created using a specified `presentation_header`. A Verifier-specified cryptographically random value (e.g., a nonce) featuring in the `presentation_header` provides strong protections against replay attacks, and is RECOMMENDED in most use cases. In some settings, proofs can be generated in a non-interactive fashion, in which case verifiers MUST be able to verify the uniqueness of the `presentation_header` values. ## Implementing hash\_to\_curve\_g1 @@ -1722,7 +1735,7 @@ In any case, the randomness used in ProofGen MUST be unique in each call and MUS 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. +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`). @@ -1736,15 +1749,15 @@ In any case, the privacy considerations described in (#privacy-considerations) M ## Post-quantum Security -BBS Signatures compine two security properties; data authenticity and data confidentiality. +BBS Signatures combine two security properties; data authenticity and data confidentiality. Data authenticity refers to the inability of anyone other that the Signer being able to generate BBS signatures that are valid under the Signer's public key (this property is often 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]). +Data confidentiality means that no one (not even the Signer) should be able to use a BBS proof to extract information about the messages the Prover decided not to disclose during the proof generation process, or the signature that was used to generate that proof (something that is 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). +On the other hand, data confidentiality cannot be broken, even by adversaries with unbounded computational resources and in possession of the Signer's secret key. This means that even by utilizing a CRQC, adversaries will not be able to compromise the data confidentiality property of BBS proofs. As a result, an adversary with access to such a quantum computer, will not be able to reveal neither the messages undisclosed by a BBS proof, nor the hidden signature value (which the Prover showcases possession of). This guarantees that the privacy and hiding properties of BBS proofs that are currently used, will not be compromised by future quantum-attacks (a property that is often referred to as everlasting privacy). Note that this only consideres BBS proofs, not BBS signatures, which do not possess the same hiding properties as the BBS proofs. # Ciphersuites