ci/fix: typos and CodeSpell (#166)

* typos README.md

* typo README.md

* typo README.md

* typos README.md

* typos README.md

* typos README.md

* typo README.md

* add spellcheck.yml

* Create .codespell-ignore

* Update spellcheck.yml

add ignore *.svg

* Update .codespell-ignore

* typos curve.sage

* typo program.rs

* typo mod.rs

* Update .codespell-ignore

* typo mod.rs

* typos README.md

* typo mod.rs

* typo mod.rs

* typo sha256.rs

* typos sponge.rs

* typo aes_chained_cbc.rs

.codespell-ignore

@@ -0,0 +1,4 @@
+ronkathon
+crate
+nd
+te

.github/workflows/spellcheck.yml

@@ -0,0 +1,24 @@
+name: Spell Check
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+
+jobs:
+  spellcheck:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Install Codespell
+        run: pip install codespell
+
+      - name: Run Codespell
+        run: |
+          codespell \
+            --ignore-words=.codespell-ignore \
+            --skip="*.min.js,*.json,*.lock,*.bin,*.svg"

README.md

@@ -82,7 +82,7 @@ We have found the following resources helpful in understanding the foundational
 - [Plonk by Hand P2](https://research.metastate.dev/plonk-by-hand-part-2-the-proof/)
 - [Plonk by Hand P3](https://research.metastate.dev/plonk-by-hand-part-3-verification/)
 
-### Code Refrences
+### Code References
 
 - [Plonkathon](https://github.com/0xPARC/plonkathon/blob/main/README.md)
 - [Plonky3](https://github.com/Plonky3/Plonky3)

examples/aes_chained_cbc.rs

@@ -29,7 +29,7 @@ fn attacker<'a>(key: &Key<128>, iv: &Block, ciphertext: Vec<u8>) -> &'a [u8] {
   // first blocks' ciphertext
   let c1 = &ciphertext[..16];
 
-  // select new IV as last blocks' ciphertext and intiate CBC with AES again with new IV
+  // select new IV as last blocks' ciphertext and initiate CBC with AES again with new IV
   let new_iv: [u8; 16] = ciphertext[ciphertext.len() - 16..].try_into().unwrap();
   let cbc2 = CBC::<AES<128>>::new(Block(new_iv));
 

math/curve.sage

@@ -19,7 +19,7 @@ print(IntegerMod(F101, -1))
 # Lets make our elliptic curve
 E = EllipticCurve(F101, [0, 3])
 
-# lets print out the points, notice they print (x,y,z) the difference between homogenious points and affine points is that to use affine you just divide x,y by z.
+# lets print out the points, notice they print (x,y,z) the difference between homogeneous points and affine points is that to use affine you just divide x,y by z.
 # We can see here that for all points in the curve group z = 1 except the zero point at infinity. So for this field they are the same
 print(E.points())
 
@@ -49,7 +49,7 @@ N = 17
 G2 = E2([36, 31 *X])
 print(G2)
 
-# Now Lets generate the structured refrence string (SRS),
+# Now Lets generate the structured reference string (SRS),
 # we will use the "random" number 2 for the example but in practice it should be strong random.
 # a circuit with n gates requires an SRS with at least
 # n + 5 elements as below
@@ -94,4 +94,4 @@ print(tate_1, tate_2)
 weil_sage = a.weil_pairing(b, r)
 print("weil", weil_sage)
 
-######################################################################
+######################################################################

src/algebra/field/README.md

@@ -29,7 +29,7 @@ Returns `None` if the element is zero.
 The `ExtensionField` trait is used to define an extension field of a finite field.
 It inherits from the `FiniteField` trait and enforces that algebraic operations from the base field are implemented.
 It is generic over the prime `P` of the underlying base field as well as the degree `N` of the extension intended.
-The only additional constraint aside from the `FiniteField` trait and adherance to algebraic operations on the base field is:
+The only additional constraint aside from the `FiniteField` trait and adherence to algebraic operations on the base field is:
 - `const IRREDUCIBLE_POLYNOMIAL_COEFFICIENTS: [PrimeField<P>; N + 1]` - The coefficients of the irreducible polynomial that defines the extension field.
 
 We will discuss `PrimeField<P>` momentarily.
@@ -73,4 +73,4 @@ where the `[PrimeField<P>; N]` is the representation of the field element as coe
 We implement `ExtensionField` for specific instances of `GaloisField<N, P>` as, at the moment, we do not have a general compile-time-based implementation of extension fields as we do with `PrimeField<P>`, though it is possible to do so.
 Instead, we have implemented much of the arithmetic operations for `GaloisField<N, P>` in `field::extension::arithmetic`, but left some that needs to be computed by hand for the user to implement (for now).
 See, for instance, `field::extension::gf_101_2` implements the `IRREDUCIBLE_POLYNOMIAL_COEFFICIENTS` for `GaloisField<2, 101>` as well as the remaining arithmetic operations.
-There is a method to compute both the `IRREDUCIBLE_POLYNOMIAL_COEFFICIENTS` at compile time as well as the `PRIMITIVE_ELEMENT` of the field, but it is not implemented at the moment.
+There is a method to compute both the `IRREDUCIBLE_POLYNOMIAL_COEFFICIENTS` at compile time as well as the `PRIMITIVE_ELEMENT` of the field, but it is not implemented at the moment.

src/algebra/group/mod.rs

@@ -66,6 +66,6 @@ pub trait AbelianGroup: Group {
 #[const_trait]
 /// Finite cyclic group trait defined by a generator element and order of the group
 pub trait FiniteCyclicGroup: FiniteGroup + AbelianGroup {
-  /// primtive element of group
+  /// primitive element of group
   const GENERATOR: Self;
 }

src/codes/README.md

@@ -7,7 +7,7 @@ The Reed-Solomon encoding is a kind of error-correcting code that works by overs
 Our specific case takes a `Message<K, P>` that is a list of `K` field elements for the `PrimeField<P>`. 
 We can then call the `encode::<N>()` method on the `Message<K, P>` to get a `Codeword<N, K, P>` that is an encoded version of message with redundancy added.
 
-First, we create a polynomial in `Monomial` form from our messsage by having each element of the message be a coefficient of the polynomial.
+First, we create a polynomial in `Monomial` form from our message by having each element of the message be a coefficient of the polynomial.
 To do this encoding, we get the `N`th root of unity in the field and evaluate the polynomial at each of the powers of that root of unity.
 We then store these evaluations in the codeword along with the point at which they were evaluated.
 In effect, this is putting  polynomial into the Lagrange basis where the node points are the `N`th roots of unity.
@@ -63,4 +63,4 @@ m_2 = \frac{c_0 }{(\omega - 1)(\omega^2 - 1)} + \frac{c_1
 \end{align*}
 $$
 
-This process was generalized in the `decode()` method.
+This process was generalized in the `decode()` method.

src/compiler/program.rs

@@ -54,7 +54,7 @@ pub struct Cell {
 }
 
 impl Cell {
-  /// Assign a domain value to a cell where `row` represents power of primtive root of unity and
+  /// Assign a domain value to a cell where `row` represents power of primitive root of unity and
   /// `column` represents coset value: $k*\omega^(row)$
   fn label(&self, group_order: usize) -> PlutoScalarField {
     let col: u32 = self.column as u32;

src/encryption/asymmetric/rsa/README.md

@@ -1,6 +1,6 @@
 # Tiny RSA
 
-RSA was one of the firs assymetric cryptographic primitives in which the key used for encryption is different from the key used for decryption.
+RSA was one of the first asymmetric cryptographic primitives in which the key used for encryption is different from the key used for decryption.
 The security of RSA is based on the difficulty of factoring large integers.
 
 ## Key Generation
@@ -24,4 +24,4 @@ Public Key = $(e, n)$
 See the examples in the tests.rs file
 
 ## Security Assumptions
-The security of RSA relies on the assumption that it is computationally infeasible to factor large composite numbers into their prime factors, known as the factoring assumption. This difficulty underpins the RSA problem, which involves computing eth roots modulo  n  without the private key.
+The security of RSA relies on the assumption that it is computationally infeasible to factor large composite numbers into their prime factors, known as the factoring assumption. This difficulty underpins the RSA problem, which involves computing eth roots modulo  n  without the private key.

src/encryption/symmetric/chacha/mod.rs

@@ -41,15 +41,15 @@ pub type ChaCha12 = ChaCha<12, 2, 2>;
 /// [Original](https://cr.yp.to/chacha/chacha-20080128.pdf) ChaCha variant with 8 rounds
 pub type ChaCha8 = ChaCha<8, 2, 2>;
 
-/// Nothing-up-my-sleeve constant used as first four words in encrpytion state:
+/// Nothing-up-my-sleeve constant used as first four words in encryption state:
 /// `["expa", "nd 3", "2-by", "te-k"]`
 pub const STATE_CONSTS: [u32; 4] = [0x61707865, 0x3320646e, 0x79622d32, 0x6b206574];
 
 /// ChaCha cipher 256 byte key
 pub type Key = [u32; 8];
 
 /// ChaCha cipher counter consisting of big-endian integer using 32 bits limbs, usually 2 for
-/// orignal variant and 1 for IETF variant
+/// original variant and 1 for IETF variant
 #[derive(Debug, Clone, Copy)]
 pub struct Counter<const C: usize> {
   value: [u32; C],

src/encryption/symmetric/des/README.md

@@ -11,7 +11,7 @@
 
 ## Implementation details
 
-- limbs of `8 bits` are used to denote different types, i.e. `64, 56, 48, 32` in the encrpytion function.
+- limbs of `8 bits` are used to denote different types, i.e. `64, 56, 48, 32` in the encryption function.
 - all data is represented in **big-endian** order.
 - Refer to [tests](./tests.rs) for detailed examples and attack vectors.
   - Known-plaintext attack: brute force approach using exhaustive key search on the complete key space, i.e $[0,1<<2^{56}-1]$.
@@ -86,11 +86,11 @@ classDef hidden display: none;
 - Feistel function (F): applies substitution and permutation to key
 - Mixing: mix two halves together
 - Switching: switches left and right halves
-- Final Permuation (FP)
+- Final Permutation (FP)
 
 ### Feistel function
 
-Applies substitution, permutation to key which adds to the complexity of the function and increases cryptanalysis difficulty. For subsitution, DES uses S-boxes that takes as input 8-bits and output is of length 6-bits.
+Applies substitution, permutation to key which adds to the complexity of the function and increases cryptanalysis difficulty. For substitution, DES uses S-boxes that takes as input 8-bits and output is of length 6-bits.
 
 ```mermaid
 flowchart TB
@@ -120,11 +120,11 @@ P--32 bits-->Output:::hidden
 - use **Expansion** permutation to increase bits to **48**
 - Mix the expanded key with round's subkey using xor
 - Divides 48-bit output into 8 6-bits elements
-- Applies subsitution using 8 S-boxes to each element
+- Applies substitution using 8 S-boxes to each element
 - Applies permutation using permutation table to get **32-bit** output
 
 
 
 [sdes]: http://mercury.webster.edu/aleshunas/COSC%205130/G-SDES.pdf
 [des]: https://en.wikipedia.org/wiki/Data_Encryption_Standard
-[feistel]: https://en.wikipedia.org/wiki/Feistel_cipher
+[feistel]: https://en.wikipedia.org/wiki/Feistel_cipher

src/encryption/symmetric/des/mod.rs

@@ -148,7 +148,7 @@ impl DES {
   fn feistel_substitution(data: Block) -> Word {
     let mut output = [0u8; 4];
 
-    // perform 8 substitions
+    // perform 8 substitutions
     for (i, entry) in data.iter().enumerate() {
       // parse row as 6th and 1st bit
       let row = ((entry & 0b100000) >> 4) | (entry & 1);

src/encryption/symmetric/mod.rs

@@ -60,7 +60,7 @@ pub trait StreamCipher {
 
 /// Trait for block ciphers that works on bytes of specific sizes
 pub trait BlockCipher {
-  /// Block size in bytes for cipher oprations
+  /// Block size in bytes for cipher operations
   const BLOCK_SIZE: usize;
   /// Block acted upon by the cipher
   type Block: AsRef<[u8]> + AsMut<[u8]> + From<Vec<u8>> + Copy + PartialEq;

src/encryption/symmetric/modes/README.md

@@ -125,7 +125,7 @@ A brief summary of finite field arithmetic,
 
 In GCM the reducing polynomial is $f = 1 + x + x^2 + x^7 + x^{128}$
 
-If you want to read about Finite Field, the Wikipedia article on [Finite Field Arithemtic](https://en.wikipedia.org/wiki/Galois/Counter_Mode) is pretty good!
+If you want to read about Finite Field, the Wikipedia article on [Finite Field Arithmetic](https://en.wikipedia.org/wiki/Galois/Counter_Mode) is pretty good!
 
 The authenticated decryption operation is identical to authenticated encryption, except the tag is generated before the decryption.
 
@@ -146,7 +146,7 @@ But the same key and nonce pair produce the same keystream, thus, $r_1 = r_2 = r
 ```math
 c_1 = r \oplus m_1 \quad \text{and} \quad c_2 = r \oplus m_2 \\ \implies c_1 \oplus m_1 = c_2 \oplus m_2  \\ \implies m_2 = c_1 \oplus c_2 \oplus m_1
 ```
-So, after some rearrangment we get that message $m_2$ is the XOR of ciphertexts, $c_1$ and $c_2$ and the known plaintext, $m_1$.
+So, after some rearrangement we get that message $m_2$ is the XOR of ciphertexts, $c_1$ and $c_2$ and the known plaintext, $m_1$.
 Since adversary has the knowledge of all the required information, the adversary can obtain the original plaintext upto the length of the $m_1$.
 
 ## Next Steps

src/hashes/poseidon/README.md

@@ -50,12 +50,12 @@ MDS (Maximally distance separable) matrix are uses in the linear layer of the ro
 
 Each hash functions' state is divided into two sections:
 - `rate`: rate at which new elements are absorbed by the sponge
-- `capacity`: remanining elements in sponge state.
+- `capacity`: remaining elements in sponge state.
 
 Sponge behavior, based on `Sponge` metaphor which can be explained by following functions:
 - `Absorb`: absorbs new field elements $\mathbb{F}_p$ into sponge state.
   - For example: if sponge width is `10` units and sponge rate is `3`, then if a `15` unit input is entered, its divided into `5` chunks of `3` units and added to sponge state.
-  - After each chunk addition, permutation is peformed, until all chunks are absorbed.
+  - After each chunk addition, permutation is performed, until all chunks are absorbed.
 - `Squeeze`: after the absorption, hash's output is returned using squeezing of sponge state.
   - For example: for a sponge with width of `10` units and rate of `3`, if hash output of `25` units is required, then:
   - `width` number of elements are squeezed out of sponge state at each iteration.
@@ -146,4 +146,4 @@ More info and examples can be found in [tests](./tests/mod.rs).
 
 - [Poseidon by Grassi et al.](https://eprint.iacr.org/2019/458)
 - [Poseidon Journal](https://autoparallel.github.io/overview/index.html)
-- [Sponge API](https://keccak.team/sponge_duplex.html)
+- [Sponge API](https://keccak.team/sponge_duplex.html)

src/hashes/poseidon/sponge.rs

@@ -20,7 +20,7 @@
 //!
 //! let mut pluto_poseidon_sponge: PoseidonSponge<PlutoBaseField, Init> = PoseidonSponge::new(WIDTH, ALPHA, NUM_P, NUM_F, rate, rc,mds)
 //!
-//! // peform absorption any number of times
+//! // perform absorption any number of times
 //! let mut pluto_poseidon_sponge: PoseidonSponge<PlutoBaseField, Absorbing> = pluto_poseidon_sponge.start_absorbing();
 //!  let _ = pluto_poseidon_sponge.absorb(&input);
 //! let absorb_res = pluto_poseidon_sponge.absorb(&input);
@@ -142,7 +142,7 @@ impl<F: Field> PoseidonSponge<F, Absorbing> {
   pub fn absorb(&mut self, elements: &[F]) -> Result<&mut Self, &str> {
     let mut remaining_elements = elements;
 
-    // new elements not enough for proceesing in chunks
+    // new elements not enough for processing in chunks
     if self.parameters.absorb_index + remaining_elements.len() <= self.parameters.rate {
       // if new elements doesn't complete current partially filled chunk
       for (i, element) in remaining_elements.iter().enumerate() {
@@ -230,7 +230,7 @@ impl<F: Field> PoseidonSponge<F, Squeezing> {
   ///
   /// let mut pluto_poseidon_sponge: PoseidonSponge<PlutoBaseField, Init> = PoseidonSponge::new(WIDTH, ALPHA, NUM_P, NUM_F, rate, rc,mds)
   ///
-  /// // peform absorption any number of times
+  /// // perform absorption any number of times
   /// let mut pluto_poseidon_sponge: PoseidonSponge<PlutoBaseField, Absorbing> = pluto_poseidon_sponge.start_absorbing();
   ///  let _ = pluto_poseidon_sponge.absorb(&input);
   /// let absorb_res = pluto_poseidon_sponge.absorb(&input);

src/hashes/sha256.rs

@@ -58,7 +58,7 @@ pub const fn ch(x: u32, y: u32, z: u32) -> u32 { (x & y) ^ (!x & z) }
 
 /// The [Maj](https://en.wikipedia.org/wiki/SHA-2) function used in SHA-256.
 /// This is a logical function used in the hash computation used to select the "majority" of the
-/// calues of `x`, `y`, and `z`.
+/// values of `x`, `y`, and `z`.
 pub const fn maj(x: u32, y: u32, z: u32) -> u32 { (x & y) ^ (x & z) ^ (y & z) }
 
 /// An empty struct to encapsulate the SHA-256 hash function.

src/kzg/README.md

@@ -18,7 +18,7 @@ Elements in the curve group are points (pairs of integers) that lie in the field
 Now to create a pairing friendly curve we first must find the curve groups order. 
 The order is how many times do we double the generator to get the generator again, the reason we can do this is because our group is cyclic.
 Now if our base field $F_{101}$ is of prime order, then any point in the curve group is a generator.
-So in practice you can pick a point and double it untill you get back to itself (remember to check the inverse!).
+So in practice you can pick a point and double it until you get back to itself (remember to check the inverse!).
 This defines the scalar field $F_r$ where $r$ is the order. 
 In our case this is $17$. 
 Once we have have this we can computer the embedding degree.
@@ -33,13 +33,13 @@ Our second curve group now E2, is over the same curve but now over the field ext
 It's points are now represented by two degree polynomials (because our embedding degree is two), not integers.
 We now have two pairing friendly groups $E1$ and $E2$ and generators for both of them. 
 
-The next step is to construct the structured refrence string SRS with g1 and g2. The structured refrence string is generated by multiplying the generator points by some randomness $\{S^i\}$, the SRS needs to be a vector of length $t$ where $t$ is the number of constraints in the proof. 
+The next step is to construct the structured reference string SRS with g1 and g2. The structured reference string is generated by multiplying the generator points by some randomness $\{S^i\}$, the SRS needs to be a vector of length $t$ where $t$ is the number of constraints in the proof. 
 This is same as the degree of the polynomial which we would like to prove knowledge of. 
 KZG Proves an arbitrary polynomial. Plonk can be used to represent some computation as a polynomial. 
 
 Commit to a polynomial using the g1_SRS: This is done by multiplying the polynomial coefficients by the g1_SRS points (scalar multiplication in the curve group) and adding the resulting points to each other to get a single point that represents the commitment call it `p_commit`.
 
-Opening involves choosing a point to evauluate the polynomial at and dividing the polynomial by .... (need the notes for this). the resulting polynomial is also combined with the g1_SRS to get a new commitment curve point call it `q_commit`.
+Opening involves choosing a point to evaluate the polynomial at and dividing the polynomial by .... (need the notes for this). the resulting polynomial is also combined with the g1_SRS to get a new commitment curve point call it `q_commit`.
 
 Then we do the pairing check.