chore: remove repetitive words

common/src/lru.rs

@@ -123,7 +123,7 @@ impl<K: PartialEq + Eq + Hash, V> LruCache<K, V> {
             self.key_to_entry_index
                 .remove(&self.entries[index].as_ref().unwrap().0);
 
-            // Replace it with the new entry and put at at the front.
+            // Replace it with the new entry and put at the front.
             self.entries[index] = Some((key.clone(), val));
             self.key_to_entry_index.insert(key, index);
             self.used_indexes.push_front(index);

crypto/box/README.md

@@ -24,7 +24,7 @@ Decryption takes the private key and the cryptogram and repoduces the message.
 Properties
 ----------
 
-The `VersionedCryptoBox` object aims for semantic security at at least 128-bit security level,
+The `VersionedCryptoBox` object aims for semantic security at least 128-bit security level,
 and non-malleability of the cryptograms. The primitives used at current version are:
 
 - Ristretto elliptic curve (`curve25519-dalek` crate) for key exchange

fog/ocall_oram_storage/trusted/README.md

@@ -242,7 +242,7 @@ it is suitable for this purpose.
 
 This AEAD-based ORAM memory interface idea seems novel and elegant, somewhat reducing the number of cryptographic components in the described design.
 
-The two major implementation difficulties with the AEAD approach are are:
+The two major implementation difficulties with the AEAD approach are:
 - While the AES IV is 16 bytes, the AES-GCM IV is only 12 bytes. Neither of the values `block_idx` and `block_ctr` can be comfortably restricted to 4 bytes.
   - An implementation might split the difference and truncate to 6 bytes, which might be okay.
   - Alternatively, the implementation might hash `block_idx || block_ctr` down from 16 bytes to 12 bytes.

util/ffi/src/lib.rs

@@ -24,7 +24,7 @@
 //! an allocated "owned" object is allocated by Rust code and passed back to
 //! foreign code, that foreign code takes ownership (takes over responsibility
 //! for disposing of the object), with the caveat that the actual memory
-//! deallocation needs be be performed by the original allocator. In practice,
+//! deallocation needs be performed by the original allocator. In practice,
 //! this usually means that any time foreign code calls a Rust FFI function that
 //! returns an owned object, the foreign code becomes responsible for later
 //! calling the corresponding "free" function, usually taking the form of