addressing Greg's comments

Author: BasileiosKal

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, guaranteeing 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 itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages.
 
 {mainmatter}
 
@@ -62,7 +62,7 @@ Beyond the core properties of a digital signature scheme, the BBS signatures and
 
 **Selective Disclosure** - The scheme allows a Signer to sign multiple messages and produce a single -constant size- output signature. A Prover then possessing the messages and the signature can generate a proof whereby they can choose which messages to disclose, while revealing no information about the undisclosed messages. The proof itself guarantees the integrity and authenticity of the disclosed messages (e.g. that they were originally signed by the Signer).
 
-**Unlinkable Proofs** - The proofs generated by the scheme are zero-knowledge, proofs of knowledge of the signature, meaning a verifying party in receipt of a proof is unable to determine which signature was used to generate the proof, removing a common source of correlation. In general, the value of 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 a BBS proof is indistinguishable from random even if generated from the same signature.
 
 **Proof of Possession** - The proofs generated by the scheme prove to a Verifier that the party who generated the proof (Prover) was in possession of a signature without revealing it. The scheme also supports binding a `presentation_header` to the generated proof, which acts as a message signed by the Prover. The `presentation_header` can include arbitrary information such as a cryptographic nonce, an audience/domain identifier and or time based validity information (for more details on the `presentation_header`, see (#header-and-presentation-header-usage)).
 
@@ -330,7 +330,7 @@ Similarly, the Prover can choose a `presentation_header` value to be bound to th
 
 ### 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.
+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 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
 
@@ -394,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 input 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,
 
@@ -487,7 +487,7 @@ Procedure:
 
 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 value, chosen by the Prover, will also be integrity protected (signed) by the resulting proof (see (#header-and-presentation-header-usage)). Finally, to indicate which of the messages should be disclosed, the operation accepts a list of integers in ascending order, representing the indexes of those messages.
 
 ```
 proof = ProofGen(PK, signature, header, ph, messages, disclosed_indexes)
@@ -1075,7 +1075,7 @@ At a high level, the challenge will be calculated as the digest (using `hash_to_
 - 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 input `presentation_header` (`ph`) values.
 
 This operation makes use of the `serialize` function, defined in (#serialize).
 
@@ -1669,13 +1669,13 @@ 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. 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.
+This section will go through threats to the Prover's privacy. Note that a BBS proof is unlinkable against both the Verifiers and the Signer, as well as multiple Verifiers colluding with each other and Verifiers colluding with the Signer. Bear in mind that, those guarantees concern only the proof value, as outputed by the `CoreProofGen` (Section (#coreproofgen)) and of course 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 channels, that could compromise the unlinkability property of the BBS proof. Note that, the following sections describe ways to minimize possible identifying information revealed during a BBS proof presentation, related to the BBS Signatures scheme. To minimize the privacy threats of an entire system, other protections may also need to be employed, for example, using an IP hiding proxy network like TOR ([@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..
+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 correlation 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 guarantees, 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.. Unacceptable values include random values, high cardinality expiration dates, the Prover's email address etc..
 
 On the other hand, the misuse of a `presentation_header`, chosen by the Prover and only bound to a BBS proof, does not incur as many privacy risks as the `header` value. For example, since a new `presentation_header` can be chosen each time a BBS proof is generated, random values are a viable choice. Still, to not break the unlinkability property, care must be taken that the `presentation_header` does not identify a single or small group of Provers. 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). Unacceptable values include the Prover's phone number, their complete physical address, their date of their birth etc..
 
@@ -1697,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. If the required checks for the validity of the Signer's public key are not performed, the results are unpredictable, leading to unexpected vulnerabilities (for example, the output of the pairing operation on input of an invalid elliptic curve point can be highly irregular and implementation-dependent, with some returning the identity point of the elliptic curve and others returning errors).
+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 to 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. If the required checks for the validity of the Signer's public key are not performed, the results are unpredictable, leading to unexpected vulnerabilities (for example, the output of the pairing operation on input of an invalid elliptic curve point can be highly irregular and implementation-dependent, with some returning the identity point of the elliptic curve and others returning errors).
 
 ## Skipping Membership Checks
 
@@ -1757,7 +1757,7 @@ Data confidentiality means that no one (not even the Signer) should be able to u
 
 On the presence of a Cryptographically Relevant Quantum Computer (CRQC), meaning a computer that will be able to break the discrete logarithm problem in the groups used by BBS Signatures (see [@I-D.ietf-pquip-pqc-engineers]), the data authenticity property will not hold. Specifically, an adversary could use a CRQC to reveal the Signer's secret key from their public key, hence giving them the ability to generate BBS signatures on behalf of that Signer, for messages of their choosing, as well as BBS proofs using those signatures.
 
-On the other hand, data confidentiality cannot be broken, even by adversaries with unbounded computational resources and in possession of the Signer's secret key. This means that even by utilizing a CRQC, adversaries will not be able to compromise the data confidentiality property of BBS proofs. As a result, an adversary with access to such a quantum computer, will not be able to reveal 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 considers BBS proofs, not BBS signatures, which do not possess the same hiding properties as the BBS proofs.
+On the other hand, data confidentiality cannot be broken, even by adversaries with unbounded computational resources and in possession of the Signer's secret key. This means that even by utilizing a CRQC, adversaries will not be able to compromise the data confidentiality property of BBS proofs. As a result, an adversary with access to such a quantum computer, will not be able to reveal either the messages undisclosed by a BBS proof, or the hidden signature value (which the Prover showcases possession of). This guarantees that the privacy and hiding properties of BBS proofs that are currently used, will not be compromised by future quantum-attacks (a property that is often referred to as everlasting privacy). Note that this only considers BBS proofs, not BBS signatures, which do not possess the same hiding properties as the BBS proofs.
 
 # Ciphersuites