diff options
| author |  Joey Hess <joey@kitenet.net> | 2011-04-03 14:47:43 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2011-04-03 14:47:43 -0400 |
| commit | 8c9d9eb8af88035a05378214e86b679fce091acf (patch) | |
| tree | 81cee4058015d112e2f2cc15b3a2a71a9da646e7 | |
| parent | dbe41e667bba1096de8d60b75f932efcbf674f85 (diff) | |
update
| -rw-r--r-- | doc/design/encryption.mdwn | 6 |
1 files changed, 4 insertions, 2 deletions
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. |