Address Crypto Panel review comments #330
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
| 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.. |
There was a problem hiding this comment.
Suggested change
| 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.. | |
| 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.. |
| @@ -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). | |||
There was a problem hiding this comment.
Suggested change
| 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). | |
| 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). |
|
|
||
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. | |
| 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. |
| @@ -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. | |||
There was a problem hiding this comment.
Suggested change
| 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. | |
| This operation computes a deterministic signature from a secret key (`SK`), a set of `generators` (points of G1) and optionally a `header` and a vector of `messages`. Note that signature generation is deterministic, in contrast to the academic literature, where signature generation, and more specifically the calculation of the `e` value (Procedure step 2 below), is randomized (i.e., the `e` value is drawn at random, instead of been deterministically calculated by hashing the Signer's secret key and the list of messages). This alteration 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. |
| @@ -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. | |||
There was a problem hiding this comment.
Suggested change
| 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, guaranteeing the authenticity and integrity of the disclosed messages. |
| @@ -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. | |||
There was a problem hiding this comment.
Suggested change
| 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. | |
| 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. |
| @@ -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. | |||
There was a problem hiding this comment.
Suggested change
| 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. |
|
|
||
| ## 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.. |
There was a problem hiding this comment.
Suggested change
| 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 credential, Prover or small group of Provers), it can be used as a correlation vector to trace and link together all BBS proofs made by a signature bound to that `header` value. This will result to significantly worst privacy guarantees, by allowing adversaries to trace and link together all generated proofs bound to that `header` value (for example, if a random `header` is used during each BBS signature generation, adversaries will be able to link and trace the BBS proofs generated from that signature). The Issuer MUST choose a low entropy `header` value and it MUST be the same for a large number of users (Provers). 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.. |
| 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]). |
There was a problem hiding this comment.
Suggested change
| 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]). | |
| 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]). |
Wind4Greg
reviewed
Dec 17, 2024
| @@ -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. | |||
There was a problem hiding this comment.
"signature it self," should be "signature itself,"
Wind4Greg
reviewed
Dec 17, 2024
|
|
||
| **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. |
There was a problem hiding this comment.
"the value of BBS proof" should be "the value of a BBS proof"
Wind4Greg
reviewed
Dec 17, 2024
|
|
||
| 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. |
There was a problem hiding this comment.
"their interaction with a prover Verifier," should be "their interaction with a Verifier," right?
Wind4Greg
reviewed
Dec 17, 2024
| @@ -387,19 +394,19 @@ 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. | |||
There was a problem hiding this comment.
"inputted message is an octet" should be "input message is an octet"
Wind4Greg
reviewed
Dec 17, 2024
| @@ -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. | |||
There was a problem hiding this comment.
ProofGen also uses the presentation_header and ProofVerify uses that and header and disclosed messages...
Wind4Greg
reviewed
Dec 18, 2024
|
|
||
| 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. |
There was a problem hiding this comment.
"The inputted presentation_header (ph) values." should be "The input presentation_header (ph) values."
Wind4Greg
reviewed
Dec 18, 2024
| @@ -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. | |||
There was a problem hiding this comment.
"gurantees consearn only the proof" should be "guarantees concern only the proof"
" and ofcourse" should be " and of course"
Wind4Greg
reviewed
Dec 18, 2024
| 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]). |
There was a problem hiding this comment.
"side chanells," should be "side channels,"
Wind4Greg
reviewed
Dec 18, 2024
|
|
||
| ## 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.. |
There was a problem hiding this comment.
"corelation vector" should be "correlation vector"
"gurantees, by allowing" should be "guarantees, by allowing"
"Anacceptable values" should be "Unacceptable values"
Wind4Greg
reviewed
Dec 18, 2024
|
|
||
| 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.. |
There was a problem hiding this comment.
"the missuss of a" should be "the misuse of a"
"viable choise." should be "viable choice."
"Anacceptable values" should be "Unacceptable values"
Wind4Greg
reviewed
Dec 18, 2024
| @@ -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). | |||
There was a problem hiding this comment.
"recommendation applies is the" should be "recommendation applies to the"
"be highly iregural" should be "be highly irregular"
"and implementation dependant," should be "and implementation dependent,"
"and others returnong errors)" should be "and others returning errors)"
Wind4Greg
reviewed
Dec 18, 2024
|
|
||
| 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. |
There was a problem hiding this comment.
"reveal neither the messages undisclosed by a BBS proof, nor the hidden signature value" should be "reveal either the messages undisclosed by a BBS proof, or the hidden signature value"
Wind4Greg
approved these changes
Dec 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Editorial updates to address the CFRG Crypto Panel review: https://mailarchive.ietf.org/arch/msg/crypto-panel/Vk5O4h_U3-QcWrm22KWwRFmSl7E/