Merge pull request #312 from kdenhartog/patch-1

spelling fix

draft-irtf-cfrg-bbs-signatures.md

@@ -1656,7 +1656,7 @@ 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 chanel 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. The following sections will describe possible threats, resulting from side channel information or identifying disclosed messages, that could compromise the unlinkability property of the BBS proof. Such threats, if exploited, could lead to correlation of the Prover's interactions with different Verifiers, resulting to fingerprinting attacks on the Prover's activity.
 
 Note that, the following sections describe ways to minimize possible identifying information revealed during a BBS proof presentation. To minimize the privacy threats of an entire system, other protections may also need to be employed, for example, using an IP hiding proxy network like TOR ([@DMS04]).
 
@@ -1708,7 +1708,7 @@ BBS signatures can be implemented on any pairing-friendly curves suitable for ty
 
 The `key_material` input to the `KeyGen` operation defined in (#secret-key) MUST be infeasible to guess and MUST be kept secret. One possibility is to generate the `key_material` from a trusted, cryptographically secure pseudo random function [@!RFC4086]. Secret keys MAY be generated using other methods; in this case they MUST be infeasible to guess and MUST be indistinguishable from uniformly random modulo r.
 
-The `ProofGen` operation defined in (#proof-generation-proofgen) is by its nature a randomized algorithm, requiring the generation of multiple uniformly distributed, pseudo random scalars. This makes `ProofGen` vulnerable to attacks caused by bad entropy (like the ones described in [@HDWH12]). If randomness is re-used or is in any way predictable or maliciously constructed, an adversary may be able to unveil the undisclosed from the proof messages or the hidden signature value. More subtle attacks are also possible, where the security properties of the BBS proof may not be broken, but a system making use of the BBS scheme may still be compromised. As an example, consider systems that need to monitor and potentially restrict outbound traffic, in order to minimize data leakage during a breach. In such cases, the attacker could manipulate couple of bits in the output of the `get_random` function ((#parameters)) to create an undetected chanel out of the system. Although the applicability of such attacks is limited for most of the targeted use cases of the BBS scheme, some applications may want to take measures towards mitigating them. To that end, it is RECOMMENDED to use a deterministic RNG (like a ChaCha20 based deterministic RNG), seeded with a unique, uniformly random, single seed [@!DRBG]. This will limit the amount of bits the attacker can manipulate (note that some randomness is always needed).
+The `ProofGen` operation defined in (#proof-generation-proofgen) is by its nature a randomized algorithm, requiring the generation of multiple uniformly distributed, pseudo random scalars. This makes `ProofGen` vulnerable to attacks caused by bad entropy (like the ones described in [@HDWH12]). If randomness is re-used or is in any way predictable or maliciously constructed, an adversary may be able to unveil the undisclosed from the proof messages or the hidden signature value. More subtle attacks are also possible, where the security properties of the BBS proof may not be broken, but a system making use of the BBS scheme may still be compromised. As an example, consider systems that need to monitor and potentially restrict outbound traffic, in order to minimize data leakage during a breach. In such cases, the attacker could manipulate couple of bits in the output of the `get_random` function ((#parameters)) to create an undetected channel out of the system. Although the applicability of such attacks is limited for most of the targeted use cases of the BBS scheme, some applications may want to take measures towards mitigating them. To that end, it is RECOMMENDED to use a deterministic RNG (like a ChaCha20 based deterministic RNG), seeded with a unique, uniformly random, single seed [@!DRBG]. This will limit the amount of bits the attacker can manipulate (note that some randomness is always needed).
 
 In any case, the randomness used in ProofGen MUST be unique in each call and MUST have a distribution that is indistinguishable from uniform. If the random scalars are re-used, created from "bad randomness" (for example with a known relationship to each other) or are in any way predictable, the undisclosed messages or the signature value may be compromised. Naturally, a cryptographically secure pseudorandom number generator or pseudo random function is REQUIRED to implement the `get_random` functionality. See [@!RFC4086] for guidance on implementing such functionality. See also [@!RFC8937], for recommendations on generating good randomness in cases where the Prover has direct or in-direct access to a secret key.