3 ms·

> seems to preclude efficient sync with current tech. I disagree. You can deterministically chunk the large file with one of the existing rolling checksum sche

by ef4 12y ago

> seems to preclude efficient sync with current tech. I disagree. You can deterministically chunk the large file with one of the existing rolling checksum schemes, and then use the chunks as your primitive instead of whole files. The server only sees encrypted chunks. The client knows to only upload changed chunks. That still leaves important choices to be made about cipher mode, key management, etc. But it's not intractable.

gaigepr 12y ago
Assuming you are using AES with CBC, best case you will have to resend every block after and including the first one that changed. My understanding is that CBC is among the most secure forms of AES encryption because it is essentially impossible to have patterns in data (unlike EBC). Practically speaking then one must assume that it is common to upload most of a file. Any software that boasts this security cannot effectively 'diff' your files. EDIT: Formatting
- Eiwatah4 12y ago
  You don't have to apply the CBC mode to complete files. If it is secure for a 1 MB file, I don't see why it would be insecure for 100 parts of a 100 MB file. If you manage to merge small files into the same blocks, you even gain some privacy because the server can't even tell the number of files anymore. [1] also has a discussion of the trade-offs of the different modes of operation for whole disk encryption. That seems related here because nobody wants to rewrite the whole disk after changing the first byte. 1: https://en.wikipedia.org/wiki/Disk_encryption_theory https://en.wikipedia.org/wiki/Disk_encryption_theory
  - gaigepr 12y ago
    I understand now. that is a clever idea; I like it a lot.
- ef4 12y ago
  There are other modes that are more suitable for random access. For example, TrueCrypt uses XTS mode. Tarsnap uses CTR mode. Either would satisfy the requirement of allowing you to edit one block without rewriting all the blocks that follow.
unhammer 12y ago
Looks like http://en.wikipedia.org/wiki/Duplicity_%28software%29 http://en.wikipedia.org/wiki/Duplicity_%28software%29 does something like this. Ie. client-side encryption that is still rdiffable.

by ef4 12y ago

gaigepr 12y ago

Assuming you are using AES with CBC, best case you will have to resend every block after and including the first one that changed. My understanding is that CBC is among the most secure forms of AES encryption because it is essentially impossible to have patterns in data (unlike EBC). Practically speaking then one must assume that it is common to upload most of a file. Any software that boasts this security cannot effectively 'diff' your files. EDIT: Formatting

Eiwatah4 12y ago
You don't have to apply the CBC mode to complete files. If it is secure for a 1 MB file, I don't see why it would be insecure for 100 parts of a 100 MB file. If you manage to merge small files into the same blocks, you even gain some privacy because the server can't even tell the number of files anymore. [1] also has a discussion of the trade-offs of the different modes of operation for whole disk encryption. That seems related here because nobody wants to rewrite the whole disk after changing the first byte. 1: https://en.wikipedia.org/wiki/Disk_encryption_theory https://en.wikipedia.org/wiki/Disk_encryption_theory
- gaigepr 12y ago
  I understand now. that is a clever idea; I like it a lot.
ef4 12y ago
There are other modes that are more suitable for random access. For example, TrueCrypt uses XTS mode. Tarsnap uses CTR mode. Either would satisfy the requirement of allowing you to edit one block without rewriting all the blocks that follow.

unhammer 12y ago

Looks like http://en.wikipedia.org/wiki/Duplicity_%28software%29 http://en.wikipedia.org/wiki/Duplicity_%28software%29 does something like this. Ie. client-side encryption that is still rdiffable.