[tor-commits] [torspec/master] Fix several typos found in the NewHope proposal.

[isis at torproject.org]

commit 5c11590522923f8cbca307f6be92357087a5ca2d
Author: Isis Lovecruft <isis at torproject.org>
Date:   Sun May 8 15:05:36 2016 +0000

    Fix several typos found in the NewHope proposal.
    
     * THANKS TO eikovi at sigaint.org for pointing them out.
---
 proposals/XXX-newhope-hybrid-handshake.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/proposals/XXX-newhope-hybrid-handshake.txt b/proposals/XXX-newhope-hybrid-handshake.txt
index 2a5e076..d11fbd2 100644
--- a/proposals/XXX-newhope-hybrid-handshake.txt
+++ b/proposals/XXX-newhope-hybrid-handshake.txt
@@ -46,7 +46,7 @@ Depends: prop#220 prop#249 prop#264
   - A NewHope key exchange.
 
   The shared keys derived from these two handshakes are then concatenated and
-  used as input to the SHAKE-256 extendable output function (XOF), as decribed
+  used as input to the SHAKE-256 extendable output function (XOF), as described
   in FIPS-PUB-202 [2], in order to produce a shared key of the desired length.
   The testvectors in §C assume that this key has a length of 32 bytes, but the
   use of a XOF allows arbitrary lengths to easily support future updates of
@@ -84,7 +84,7 @@ Depends: prop#220 prop#249 prop#264
   for Curve25519 points.
 
   Let `ID` be a router's identity key taken from the router microdescriptor.
-  In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal
+  In the case for relays possessing Ed25519 identity keys (cf. Tor proposal
   #220), this is a 32-byte string representing the public Ed25519 identity key.
   For backwards and forwards compatibility with routers which do not possess
   Ed25519 identity keys, this is a 32-byte string created via the output of
@@ -180,7 +180,7 @@ Depends: prop#220 prop#249 prop#264
   assumed to imply the responder also lacks support for fragmented EXTEND2
   cells.  Alternatively, for initiators with a sufficiently late consensus
   method, the initiator MUST check that "proto" line in the responder's
-  descriptor (c.f. Tor proposal #264) advertises support for the "Relay"
+  descriptor (cf. Tor proposal #264) advertises support for the "Relay"
   subprotocol version 3 (see §5).
 
 
@@ -352,14 +352,14 @@ Depends: prop#220 prop#249 prop#264
   Because our proposal requires both the client and server to send more than
   the 505 bytes possible within a CREATE2 cell's HDATA section, it depends
   upon the implementation of a mechanism for allowing larger CREATE cells
-  (c.f. Tor proposal #249).
+  (cf. Tor proposal #249).
 
   We reserve the following handshake type for use in CREATE2V/CREATED2V and
   EXTEND2V/EXTENDED2V cells:
 
     0x0003            [NEWHOPE + X25519 HYBRID HANDSHAKE]
 
-  We introduce a new sub-protocol number, "Relay=3", (c.f. Tor proposal #264
+  We introduce a new sub-protocol number, "Relay=3", (cf. Tor proposal #264
   §5.3) to signify support this handshake, and hence for the CREATE2V and
   fragmented EXTEND2 cells which it requires.
 
@@ -564,10 +564,10 @@ Depends: prop#220 prop#249 prop#264
   not need any timing-attack protection.
 
 
-  poly_getnoise() first generates 4096 Bytes of uniformly random data. This can
+  poly_getnoise() first generates 4096 bytes of uniformly random data. This can
   be done by reading these bytes from the system's RNG; efficient
   implementations will typically only read a 32-byte seed from the system's RNG
-  and expand it through some fast PRNG (for example, ChaCha20 or AES-256 in CTR
+  and expand it through some fast PRG (for example, ChaCha20 or AES-256 in CTR
   mode). The output of the PRG is considered an array of 2048 16-bit integers
   r[0],...,r[2047]. The coefficients of the output polynomial are computed as
   HW(r[0])-HW(r[1]), HW(r[2])-HW(r[3]),...,HW(r[2046])-HW(r[2047]), where HW
@@ -579,7 +579,7 @@ Depends: prop#220 prop#249 prop#264
 
 
   poly_ntt(poly f): For a mathematical description of poly_ntt see the [0]; a
-  pseudocode description of a very naive inplace transformation of an input
+  pseudocode description of a very naive in-place transformation of an input
   polynomial f = f[0] + f[1]*X + f[2]*X^2 + ... + f[1023]*X^1023 is the
   following code (all arithmetic on coefficients performed modulo q):