From 2c9af0db19c8fba4c2c6f269d2de60525638bcdd Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Mon, 2 Dec 2024 17:43:17 +0200 Subject: [PATCH] Update README.md --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 8b9c14e5..2a910d1b 100644 --- a/README.md +++ b/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