fix: Run spellcheck

easy/src/fhe0.typ

@@ -9,7 +9,7 @@ Actually, Alice wants Bob to compute $f(x)$ -- but
 she doesn't want to tell him $x$.
 
 Alice wants to encrypt $x$ and send Bob $Enc (x)$.
-Then Bob is going to "apply $f$ to the cyphertext",
+Then Bob is going to "apply $f$ to the ciphertext",
 to turn $Enc (x)$ into $Enc (f(x))$.
 Finally, Bob sends $Enc (f(x))$ back,
 and Alice decrypts it to learn $f(x)$.
@@ -31,7 +31,7 @@ operations you can do before the error gets too big.
 As a sort of silly example, imagine your message is a whole number
 between 0 and 10 (so it’s one of 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10), and
 your "encryption" scheme encodes the message as a real number that is
-very close to the message. So if the cyphertext is 1.999832, well then
+very close to the message. So if the ciphertext is 1.999832, well then
 that means the original message was 2. The decryption procedure is
 "round to the nearest integer."
 
@@ -50,7 +50,7 @@ many operations, the error will exceed $0.5$, and the rounding procedure
 won’t give the right answer anymore.
 
 But as long as you’re careful not to go over the error limit, you can
-add cyphertexts with confidence.
+add ciphertexts with confidence.
 
 In fact, for our levelled FHE protocol, our message will be a bit: 
 either 0 or 1;

easy/src/fhe2.typ

@@ -65,7 +65,7 @@ The private key is simply the vector $a$.
 == How to encrypt $mu$?
 <how-to-encrypt-mu>
 Suppose you have a message $m in { 0 , 5 }$. (You’ll see in a moment why
-we insist that $mu$ is one of these two values.) The cyphertext to
+we insist that $mu$ is one of these two values.) The ciphertext to
 encrypt $m$ will be a pair $(upright(bold(x)) : y)$, where $x$ is a
 vector, $y$ is a scalar, and
 $upright(bold(x)) dot.op upright(bold(a)) + epsilon.alt = y + mu$, where
@@ -76,7 +76,7 @@ access to the public key – that list of pairs $(upright(bold(x)) : y)$
 above. You want to make up your own $upright(bold(x))$, for which you
 know approximately the value $upright(bold(x)) dot.op upright(bold(a))$.
 You could just take one of the vectors $upright(bold(x))$ from the
-table, but that wouldn’t be very secure: if I see your cyphertext, I can
+table, but that wouldn’t be very secure: if I see your ciphertext, I can
 find that $upright(bold(x))$ in the table and use it to decrypt $mu$.
 
 Instead, you are going to combine several rows of the table to get your
@@ -123,7 +123,7 @@ Now you add them up to get the following.
 )
 
 Finally, let’s say your message is $m = 5$. So you set
-$y = y_0 - m = 6 - 5 = 1$, and send the cyphertext:
+$y = y_0 - m = 6 - 5 = 1$, and send the ciphertext:
 #figure(
   align(center)[#table(
     columns: 1,
@@ -170,7 +170,7 @@ and add them up".
 
 Of course, combining $m$ rows will have the effect of multiplying the
 error by $m$ – so if the initial $epsilon.alt$ was bounded by $1$, then
-the error in the cyphertext will be at most $m$. But remember that $q$
+the error in the ciphertext will be at most $m$. But remember that $q$
 is exponentially large compared to $m$ and $n$ anyway, so a mere factor
 of $m$ isn’t going to scare us!
 
@@ -180,7 +180,7 @@ constant $r$, where $r$ is bigger than the error bound (right now that’s
 $m$) – which allows you to encode a message space of size $q \/ r$
 rather than just a single bit.
 
-When we do FHE, we’re going to apply many operations to a cyphertext,
+When we do FHE, we’re going to apply many operations to a ciphertext,
 and each is going to cause the error to grow. We’re going to have to put
 some effort into keeping the error under control – 
 and the size of $q\/ r$ will determine how many operations 

easy/src/fhe3.typ

@@ -28,7 +28,7 @@ Our #emph[secret key] will be a vector
 $ upright(bold(v)) = (v_1, dots, v_n) in (ZZ \/ q ZZ)^n $ – a
 vector of length $n$, where the entries are integers modulo $q$. Suppose
 we want to encode a message $mu$ that’s just a single bit, let’s say
-$mu in { 0 , 1 }$. Our cyphertext will be a square $n$-by-$n$ matrix $C$
+$mu in { 0 , 1 }$. Our ciphertext will be a square $n$-by-$n$ matrix $C$
 such that $ C upright(bold(v)) approx mu upright(bold(v)) . $ Now if we
 assume that $upright(bold(v))$ has at least one "big" entry (say $v_i$),
 then decryption is easy: Just compute the $i$-th entry of
@@ -66,13 +66,13 @@ won’t really use this.
 
 Negation of a bit (NOT) is equally simple, though. If $mu in { 0 , 1 }$
 is a bit, then its negation is simply $1 - mu$. And if $C$ is a
-cyphertext for $mu$, then $upright(I d) - C$ is a cyphertext for
+ciphertext for $mu$, then $upright(I d) - C$ is a ciphertext for
 $1 - mu$, since
 $ (upright(I d) - C) upright(bold(v)) = upright(bold(v)) - C upright(bold(v)) approx (1 - mu) upright(bold(v)) . $
 
 Multiplication is also a good operation on bits – it’s just AND. To
 multiply two bits, you just multiply (matrix multiplication) the
-cyphertexts:
+ciphertexts:
 $ C_1 C_2 upright(bold(v)) approx C_1 (mu_2 upright(bold(v))) = mu_2 C_1 upright(bold(v)) approx mu_2 mu_1 upright(bold(v)) = mu_1 mu_2 upright(bold(v)) . $
 
 (At this point you might be concerned about this symbol $approx$ and
@@ -83,12 +83,12 @@ Anyway, once you have AND and NOT, you can build arbitrary logic gates –
 and this is what we mean when we say you can perform arbitrary
 calculations on your encrypted bits, without ever learning what those
 bits are. At the end of the calculation, you can send the resulting
-cyphertexts back to be decrypted.
+ciphertexts back to be decrypted.
 
 == A constraint on the secret key $upright(bold(v))$ and the "Flatten" operation
 <a-constraint-on-the-secret-key-mathbfv-and-the-flatten-operation>
 In order to make the error estimates work out, we’re going to need to
-make it so that all the cyphertext matrices $C$ have "small" entries. In
+make it so that all the ciphertext matrices $C$ have "small" entries. In
 fact, we will be able to make it so that all entries of $C$ are either
 $0$ or $1$.
 
@@ -138,9 +138,9 @@ we used above to turn $upright(bold(x))$ into $upright(bold(x)) prime$,
 applied to each $k + 1$ entries of each row of the matrix $C$.
 
 So now, using this $"Flatten"$ operation, we can insist that all of our
-cyphertexts $C$ are matrices with coefficients in ${ 0 , 1 }$. For
+ciphertexts $C$ are matrices with coefficients in ${ 0 , 1 }$. For
 example, to multiply two messages $mu_1$ and $mu_2$, we first multiply
-the corresponding cyphertexts, then flatten the resulting product:
+the corresponding ciphertexts, then flatten the resulting product:
 $ "Flatten"(C_1 C_2) . $
 
 Of course, revealing that the secret key $upright(bold(v))$ has this
@@ -156,15 +156,15 @@ $ C_1 upright(bold(v)) = mu_1 upright(bold(v)) + epsilon.alt_1 , $ where
 $epsilon.alt$ is some vector with all its entries bounded by a bound
 $B$. (And similarly for $C_2$ and $mu_2$.)
 
-When we add two cyphertexts, the errors add:
+When we add two ciphertexts, the errors add:
 $ (C_1 + C_2) upright(bold(v)) = (mu_1 + mu_2) upright(bold(v)) + (epsilon.alt_1 + epsilon.alt_2) . $
 So the error on the sum will be bounded by $2 B$.
 
 Negation is similar to addition – in fact, the error won’t change at
 all.
 
 Multiplication is more complicated, and this is why we insisted that all
-cyphertexts have entries in ${ 0 , 1 }$. We compute
+ciphertexts have entries in ${ 0 , 1 }$. We compute
 $ C_1 C_2 upright(bold(v)) = C_1 (mu_2 upright(bold(v)) + epsilon.alt_2) = mu_1 mu_2 upright(bold(v)) + (mu_2 epsilon.alt_1 + C_1 epsilon.alt_2) . $
 
 Now since $mu_2$ is either $0$ or $1$, we know that $mu_2 epsilon.alt_1$
@@ -178,7 +178,7 @@ bounded by $n B$. Adding this to the error for $mu_2 epsilon.alt_1$, we
 get that the total error in the product $C_1 C_2 upright(bold(v))$ is
 bounded by $(n + 1) B$.
 
-In summary: We can start with cyphertexts having a very small error (if
+In summary: We can start with ciphertexts having a very small error (if
 you think carefully about this
 protocol, you will
 see that the error is bounded by approximately $n log q$). Every
@@ -191,13 +191,13 @@ more than $log_n q$ input bits, but no bit can follow a path of length
 greater than $log_n q$ AND gates.)
 
 This gives us a #emph[levelled] fully homomorphic encryption protocol:
-it lets us evaluate abritrary circuits on encrypted data,
+it lets us evaluate arbitrary circuits on encrypted data,
 as long as those circuits have bounded depth.
 If we need to evaluate a bigger circuit, we have two options.
 + Increase the value of $q$.  
   Of course, the cost of the computations increases with $q$.
 + Use some technique to "reset" the error
-  and start anew, as if with a freshly encrypted cyphertext.
+  and start anew, as if with a freshly encrypted ciphertext.
 
   This approach is called "bootstrapping" and it incurs some hefty 
   computational costs.

easy/src/pair.typ

@@ -25,7 +25,7 @@ nondegenerate bilinear function
 $ pair : E times E -> ZZ slash N ZZ $
 for some large integer $N$.
 I think this should be called a *bilinear pairing*,
-but for some reason everyone justs says *pairing* instead.
+but for some reason everyone just says *pairing* instead.
 A curve is called *pairing-friendly* if this pairing can be computed reasonably
 (e.g. BN254 is pairing-friendly, but Curve25519 is not).
 
@@ -70,7 +70,7 @@ So this gives us a way to _verify_ two-by-two multiplication.
   - $pair([x^3], 1) = pair([x^2], [x]) $
   - $[y] = [x^3] + 2 [1]$.
 
-  The process of verifing this sort of identity is quite general:
+  The process of verifying this sort of identity is quite general:
   The prover sends intermediate values as needed
   so that the verifier can verify the claim using only pairings and linearity.
 ] <pair-verify-example>

src/cq.typ

@@ -4,7 +4,7 @@
 
 This is a summary of cq, 
 a recent paper that tells how to do "lookup arguments"
-in a succint (or ZK) setting.
+in a succinct (or ZK) setting.
 
 == What are lookups
 
@@ -235,7 +235,7 @@ pair(Com(L), [beta] - Com(F)) = pair([1] + Com(Q_L Z_n), [1])
 $
 (which verifies the claimed equality).
 
-The process of verifing this sort of identity is quite general:
+The process of verifying this sort of identity is quite general:
 The prover sends intermediate values as needed
 so that the verifier can verify the claim using only pairings and linearity.
 ] <cq-pairing-verify>
@@ -284,7 +284,7 @@ $
     R(zeta^j) (beta - T(zeta^j)) = M(zeta^j)
 $
 Let $R_j$ be the polynomial 
-(a mutiple of a Lagrange basis polynomial)
+(a multiple of a Lagrange basis polynomial)
 such that
 $
     R_j(zeta^j) = 1 / (beta - t_j)

src/pair.typ

@@ -25,7 +25,7 @@ nondegenerate bilinear function
 $ pair : E times E -> ZZ slash N ZZ $
 for some large integer $N$.
 I think this should be called a *bilinear pairing*,
-but for some reason everyone justs says *pairing* instead.
+but for some reason everyone just says *pairing* instead.
 A curve is called *pairing-friendly* if this pairing can be computed reasonably
 (e.g. BN254 is pairing-friendly, but Curve25519 is not).
 
@@ -70,7 +70,7 @@ So this gives us a way to _verify_ two-by-two multiplication.
   - $pair([x^3], 1) = pair([x^2], [x]) $
   - $[y] = [x^3] + 2 [1]$.
 
-  The process of verifing this sort of identity is quite general:
+  The process of verifying this sort of identity is quite general:
   The prover sends intermediate values as needed
   so that the verifier can verify the claim using only pairings and linearity.
 ] <pair-verify-example>

src/r1cs.typ

@@ -48,7 +48,7 @@ In particular, note that in step 3, the verifier can compute $C'$ themselves and
 We thus have:
 
 #proposition[
-  There exists a protocol that runs in $O(n)$ verifier time, which lets the verifier get the value of $a dot b$ for some commited $a$.
+  There exists a protocol that runs in $O(n)$ verifier time, which lets the verifier get the value of $a dot b$ for some committed $a$.
   The proof size can be made to take $O(log n)$ space with Fiat-Shamir.
 ] <dot_product>