Update README.md

README.md

@@ -466,18 +466,18 @@ on most CPUs via AES-NI. However, where hardware acceleration is not available,
 - `AES-GCM` can target multiple security levels (`128-bit`, `192-bit`, `256-bit`), whereas `ChaCha20-Poly1305` is only defined at
   the `256-bit` security level.
 - Nonce size:
-    - `AES-GCM`: Varies, but the standard is `96 bits` (`12 bytes`).
+    - `AES-GCM`: Varies, but the standard is `96-bit` (`12 bytes`).
       If you supply a longer nonce, this gets hashed down to `16 bytes`.
     - `ChaCha20-Poly1305`: The standardized version uses `96-bit` nonce (`12 bytes`), but the original used `64-bit`
       nonce (`8 bytes`).
 - Wear-out of a single (key, nonce) pair:
-    - `AES-GCM`: Messages must be less than `2^32 – 2` blocks (a.k.a. `2^36 – 32 bytes`, a.k.a. `2^39 – 256 bits`), that's
+    - `AES-GCM`: Messages must be less than `2^32 – 2` blocks (a.k.a. `2^36 – 32 bytes`, a.k.a. `2^39 – 256-bit`), that's
       roughly `64GB`.
       This also makes the security analysis of `AES-GCM` with long nonces complicated since the hashed nonce doesn’t
       start
       with the lower `4 bytes` set to `00 00 00 02`.
-    - `ChaCha20-Poly1305`: `ChaCha` has an internal counter (`32 bits` in the standardized IETF variant, `64 bits` in the
-      original design). Max message length is `2^39 - 256 bits`, about `256GB`
+    - `ChaCha20-Poly1305`: `ChaCha` has an internal counter (`32-bit` in the standardized IETF variant, `64-bit` in the
+      original design). Max message length is `2^39 - 256-bit`, about `256GB`
 - Neither algorithm is **nonce misuse-resistant**.
 - `ChaChaPoly1305` is better at `SIMD`
 
@@ -496,7 +496,7 @@ files. However, the content of the file could be bigger, and we read until the o
   pick up
   the new zeros bytes are written on truncating by increasing the size. If content is smaller, the read would stop and
   end-of-file of the actual content, so this would not be such a big issue
-- **What kind of metadata does it leak**: None, we encrypt filename, content, metadata and we hide files count, size and all time fields
+- **What kind of metadata does it leak**: None, we encrypt filename, content, and metadata and we hide file count, size, and all-time fields
 - It's always recommended to use encrypted disks for at least your sensitive data; this project is not a replacement for
   that
 - To reduce the risk of the encryption key being exposed from memory, it's recommended to disable memory dumps on the