From f47a0214494fdb1e177d90ea0fd3a39062b06344 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Tue, 19 Nov 2024 18:18:40 +0200 Subject: [PATCH] Update README.md --- README.md | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/README.md b/README.md index 899a30b..a96a1dd 100644 --- a/README.md +++ b/README.md @@ -498,18 +498,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**: close to none. The filename, actual file size and other file attrs (times, - permissions, other flags) are kept encrypted. What it could possibly leak is the following - - If a directory has children, we keep those children in a directory with name as inode number and encrypted names - of children as files in it. - So we could see how many children a directory has. - However, we can't identify that actual directory name; - We can just see its inode number (internal representation like an ID for each file), but we cannot see the actual - filenames of the directory or children. - Also, we cannot identify which file content corresponds to a directory child - - Each file content is saved in a separate file, so we can see the size of the encrypted content but not the - actual filesize - - We can also see the last time the file was accessed +- **What kind of metadata does it leak**: None, we encrypt filename, content, metadata and we hide files count, size amd 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