From 8c9d9eb8af88035a05378214e86b679fce091acf Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 3 Apr 2011 14:47:43 -0400 Subject: update --- doc/design/encryption.mdwn | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'doc/design') diff --git a/doc/design/encryption.mdwn b/doc/design/encryption.mdwn index 43d8119e3..c9b1bdb5d 100644 --- a/doc/design/encryption.mdwn +++ b/doc/design/encryption.mdwn @@ -11,6 +11,8 @@ as well as the filenames. The size of the encrypted files, and access patterns of the data, should be the only clues to what type of is stored in such a remote. +[[!toc]] + ## encryption backends It makes sense to support multiple encryption backends. So, there @@ -94,7 +96,7 @@ for each file in the repository, contact the encrypted remote to check if it has the file. This can be done without enumeration, although it will mean running gpg once per file fscked, to get the encrypted filename. -### risks +## risks A risk of this scheme is that, once the symmetric cipher has been obtained, it allows full access to all the encrypted content. This scheme does not allow @@ -108,6 +110,6 @@ amelorates these type of risks by using locked memory. This design does not support obfuscating the size of files by chunking them, as that would have added a lot of complexity, for dubious benefits. If the untrusted party running the encrypted remote wants to know file sizes, -they could correlate chunks that are accessed together. Enctypting data +they could correlate chunks that are accessed together. Encrypting data changes the original file size enough to avoid it being used as a direct fingerprint at least. -- cgit v1.2.3