consistent sections reference

Author: BasileiosKal

draft-irtf-cfrg-bbs-signatures.md

@@ -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.
 
-**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. 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.
 
@@ -142,7 +142,7 @@ U
 : The number of message indexes that are undisclosed in a proof-of-knowledge of a signature.
 
 scalar
-: An integer between 0 and r-1, where r is the prime order of the selected groups, defined by each ciphersuite (see also [Notation](#notation)).
+: An integer between 0 and r-1, where r is the prime order of the selected groups, defined by each ciphersuite (see also (#notation)).
 
 generator
 : A valid point on the selected subgroup of the curve being used that is employed to commit a value.
@@ -226,13 +226,13 @@ subgroup\_check\_G1(P), subgroup\_check\_G2(P) -> VALID or INVALID
 
 This document is organized as follows:
 
-* [Scheme Definition](#scheme-definition) defines the core operations and parameters for the BBS signature scheme.
+* Scheme Definition ((#scheme-definition)), defines the core operations and parameters for the BBS signature scheme.
 
-* [Utility Operations](#utility-operations) defines utilities used by the BBS signature scheme.
+* Utility Operations ((#utility-operations)), defines utilities used by the BBS signature scheme.
 
-* [Security Considerations](#security-considerations) describes a set of security considerations associated to the signature scheme.
+* Security Considerations ((#security-considerations)), describes a set of security considerations associated to the signature scheme.
 
-* [Ciphersuites](#ciphersuites) defines the format of a ciphersuite, alongside a concrete ciphersuite based on the BLS12-381 curve.
+* Ciphersuites ((#ciphersuites)), defines the format of a ciphersuite, alongside a concrete ciphersuite based on the BLS12-381 curve.
 
 # Conventions
 
@@ -317,7 +317,7 @@ When serializing one or more values to produce an octet string, each element wil
 
 We also use strings in double quotes to represent ASCII-encoded literals. For example "BBS" will be used to refer to the octet string, `010000100100001001010011`.
 
-Those rules will be used explicitly on every operation. See also [Serialize](#serialize).
+Those rules will be used explicitly on every operation. See also `serialize` defined in (#serialize).
 
 ### Header and Presentation Header Usage
 
@@ -1050,7 +1050,7 @@ Procedure:
 
 ### Challenge Calculation
 
-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).
+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`).
 
@@ -1357,7 +1357,7 @@ Procedure:
 
 This operation calculates the domain value, a scalar representing the distillation of all essential contextual information for a signature. The same domain value must be calculated by all parties (the Signer, the Prover and the Verifier) for both the signature and proofs to be validated.
 
-The input to the domain value includes the `header` value chosen by the signer to encode any information that is required to be revealed by the Prover (such as an expiration date, or an identifier for the target audience). This is in contrast to the signed message values, which may be withheld during a proof.
+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.
 
@@ -1685,6 +1685,10 @@ Note that checking that the points are in the correct subgroup is essential to a
 
 There are two places where side channel attacks could be relevant in the BBS Signatures scheme. First, against the Signer, where side channel leakage during signature generation could reveal their secret key. Second, against the Prover, where a side channel attack could be used during proof generation to either directly reveal the udnisclosed messages and signature value, or reveal the random scalars used, leading again to the leakage of the undisclosed messages or the hidden signature. Therefore, implementations MUST apply proper side channel attack protection. One method to achieve this, is by using elliptic curve implementations that execute curve operations in constant time.
 
+## 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.
+
 ## Implementing hash\_to\_curve\_g1
 
 The security analysis models hash\_to\_curve\_g1 as random oracles.  It is crucial that these functions are implemented using a cryptographically secure hash function.  For this purpose, implementations MUST meet the requirements of [@!I-D.irtf-cfrg-hash-to-curve].
@@ -1762,7 +1766,7 @@ The parameters that each ciphersuite needs to define are generally divided into
 
 - octet\_point\_length: Number of bytes to represent a point encoded as an octet string outputted by the `point_to_octets_E*` function.
 
-- hash\_to\_curve\_suite: The hash-to-curve ciphersuite id, in the form defined in [@!I-D.irtf-cfrg-hash-to-curve]. This defines the hash\_to\_curve\_g1 (the hash\_to\_curve operation for the G1 subgroup, see the [Notation](#notation) section) and the expand\_message (either expand\_message\_xmd or expand\_message\_xof) operations used in this document.
+- hash\_to\_curve\_suite: The hash-to-curve ciphersuite id, in the form defined in [@!I-D.irtf-cfrg-hash-to-curve]. This defines the hash\_to\_curve\_g1 (the hash\_to\_curve operation for the G1 subgroup, see the Notation defined in (#notation)) and the expand\_message (either expand\_message\_xmd or expand\_message\_xof) operations used in this document.
 
 - expand\_len: Must be defined to be at least `ceil((ceil(log2(r))+k)/8)`, where `log2(r)` and `k` are defined by each ciphersuite (see Section 5 in [@!I-D.irtf-cfrg-hash-to-curve] for a more detailed explanation of this definition).
 
@@ -2756,13 +2760,13 @@ Using the following input message,
 msg = {{ $H2sFixture.bls12-381-shake-256.h2s.message }}
 ```
 
-And the default dst defined in [hash\_to\_scalar](#hash-to-scalar), i.e.,
+And following dst value,
 
 ```
 dst = {{ $H2sFixture.bls12-381-shake-256.h2s.dst }}
 ```
 
-We get the following scalar, encoded with I2OSP and represented in big endian order,
+We get the following scalar output from `hash_to_scalar` ((#hash-to-scalar)), encoded with I2OSP and represented in big endian order,
 
 ```
 scalar = {{ $H2sFixture.bls12-381-shake-256.h2s.scalar }}
@@ -2992,13 +2996,13 @@ Using the following input message,
 msg = {{ $H2sFixture.bls12-381-sha-256.h2s.message }}
 ```
 
-And the default dst defined in [hash\_to\_scalar](#hash-to-scalar), i.e.,
+And following dst value,
 
 ```
 dst = {{ $H2sFixture.bls12-381-sha-256.h2s.dst }}
 ```
 
-We get the following scalar, encoded with I2OSP and represented in big endian order,
+We get the following scalar output from `hash_to_scalar` ((#hash-to-scalar)), encoded with I2OSP and represented in big endian order,
 
 ```
 scalar = {{ $H2sFixture.bls12-381-sha-256.h2s.scalar }}