From d86d09324e1262e09b040bdf53d97a5f47169995 Mon Sep 17 00:00:00 2001 From: shenpengfeng Date: Wed, 14 Aug 2024 23:47:30 +0800 Subject: [PATCH] chore: remove repetitive words Signed-off-by: shenpengfeng --- common/src/lru.rs | 2 +- crypto/box/README.md | 2 +- fog/ocall_oram_storage/trusted/README.md | 2 +- util/ffi/src/lib.rs | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/common/src/lru.rs b/common/src/lru.rs index 58a52104c3..1020762102 100644 --- a/common/src/lru.rs +++ b/common/src/lru.rs @@ -123,7 +123,7 @@ impl LruCache { 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); diff --git a/crypto/box/README.md b/crypto/box/README.md index 68e9740223..77afadd308 100644 --- a/crypto/box/README.md +++ b/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 diff --git a/fog/ocall_oram_storage/trusted/README.md b/fog/ocall_oram_storage/trusted/README.md index 8054226fcc..f13789a70a 100644 --- a/fog/ocall_oram_storage/trusted/README.md +++ b/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. diff --git a/util/ffi/src/lib.rs b/util/ffi/src/lib.rs index c1437c17ba..2707120192 100644 --- a/util/ffi/src/lib.rs +++ b/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