Merge pull request #31 from divergentdave/editorial

Editorial fixes

draft-case-ppm-binomial-dp.md

@@ -107,7 +107,7 @@ can be made about the amount of privacy loss that applies to any given input.
 There are multiple methods for applying noise to aggregates, but the one that
 offers the lowest amount of noise — and therefore the most useful outputs — is
 one where a single entity samples and adds noise, known as central
-DP. Alternatives include local DP, where each noise is added to each input to
+DP. Alternatives include local DP, where noise is added to each input to
 the aggregation, or shuffle DP, which reduces noise requirements for local DP by
 shuffling inputs.
 
@@ -376,7 +376,7 @@ The `epsilon_delta_constraint` is a function of epsilon, delta, `s`, `d`,
 more complicated formula.
 
 
-For the `epsilon_delta constraint`, {{CPSGD}} defines some intermediate
+For the `epsilon_delta_constraint`, {{CPSGD}} defines some intermediate
 functions of the success probability, `p`. For `p = 0.5`, these become fixed
 constants:
 

draft-savage-ppm-3phm-mpc.md

@@ -65,7 +65,7 @@ are never revealed to any single entity. MPC executes an agreed function,
 revealing only the output of that function.
 
 This makes MPC well-suited to handling data that is sensitive or private. MPC in
-a three-party honest majority setting, is broadly recognized as being extremely
+a three-party honest majority setting is broadly recognized as being extremely
 efficient:
 
 * Addition and subtraction have zero communication cost and negligible
@@ -484,8 +484,6 @@ the proof.
 Since the two verifiers possess all of this information distributed amongst
 themselves, this approach is referred to as "Distributed Zero Knowledge Proofs".
 
-## Distributed Zero Knowledge Proofs
-
 {{?FLPCP=DOI.10.1007/978-3-030-26954-8_3}} describes a system of zero-knowledge
 proofs that rely on linear operations. This is expanded in
 {{?BOYLE=DOI.10.1007/978-3-030-64840-4_9}} to apply to three-party
@@ -1018,7 +1016,7 @@ AES-128-GCM is RECOMMENDED, with the same KDF being used for PRSS and AES-128 as
 the PRP.
 
 For validation, the prime field used is modulo the Mersenne prime
-2<sup>61</sup>-1 validation.  Any sufficiently large prime can be used, but this
+2<sup>61</sup>-1.  Any sufficiently large prime can be used, but this
 value provides both good performance on 64-bit hardware and useful security
 margins for typical batch sizes; see TODO/below for an analysis of the batch
 size requirements and security properties that can be obtained by using this

draft-thomson-ppm-prss.md

@@ -185,7 +185,7 @@ def ss, enc = Send(kem, pk_bytes):
     ss, enc = kem.Encap(pk)
 ~~~
 
-The sender then sends the encapsulated public key, `enc`, to the receiver.  The
+The sender then sends the encapsulated secret, `enc`, to the receiver.  The
 receiver decapsulates this value to obtain the shared secret, `secret`:
 
 ~~~ pseudocode
@@ -447,7 +447,7 @@ fixed range of values.
 
 The total randomness available is limited by the entropy from the chosen KEM,
 KDF, and PRF.  Each KEM is only able to convey a maximum amount of entropy.
-Similarly, each KDF is limited in the amount of entropy it only able to retain.
+Similarly, each KDF is limited in the amount of entropy it is able to retain.
 Finally, each PRF also has limits that might further reduce the maximum entropy
 available.