News for hackers. Stuff that matters.
Re: encryption is not gravy by replax on Monday April 30, 2012 @10:27AM (#3909372)
As far as I know, you could do delta uploads with encrypted files. It should not be any different if the file itself is encrypted. For the same reason you can e.g. use rsync delta syncs with encrypted files...
Re: encryption is not gravy by naner on Monday April 30, 2012 @11:37AM (#3909656)
There should not be any similarities between an encrypted file and the same file encrypted again after some changes are made to the file. Even if you just change one character in a text file.

I'm sure the rync delta transfer algorithm still works fine with encrypted files, but the changes for encrypted files are going to be calculated as 100% so you're not going to save anything.

Re: encryption is not gravy by ColinDabritz on Monday April 30, 2012 @11:47AM (#3909702)
I took this to mean that since the user side has full access to the plain text, the user client could calculate a delta, then encrypt it and upload just the encrypted delta.

You'd still need to pull it all down and apply the deltas each time you put it somewhere new, but it would work. Possibly with a 'full version' on some longer schedule. As a bonus, you'd get automatic history, which Dropbox stores anyway.

It's still got issues, no doubt, but it could be done, no?

Re: encryption is not gravy by keeperofdakeys on Monday April 30, 2012 @12:25PM (#3909892)
What you describe is nearly exactly how an encrypted backup service called tarsnap works. Basically, it provides de-duplicated, compressed backups to the Amazon S3 cloud using local key files. The difference here is that it deals with data in blocks, not explicit deltas. This means you have no concept of 'history', and separate archives on the service have no strict dependencies on each other (they merely reference certain blocks that have been uploaded). It uses a cli-only interface inspired from tar, and is very handy for cron backups of important data.

There is also a project called ddar, which is designed to provide merely the de-duplication of tarsnap so you can setup your own repository (tarsnap only works with its service).

Re: encryption is not gravy by dkokelley on Monday April 30, 2012 @01:38PM (#3910319)
You might be thinking of a hash. Hashes have a cascading effect where a single bit change in the source file has a "waterfall" effect during the hashing where the output is drastically different from the hash of the unmodified input.

I don't think this is necessarily the case with all encryption mechanisms.

Re: encryption is not gravy by sreitshamer on Monday April 30, 2012 @11:43AM (#3909685)
You could do the delta on the client side before you do the encryption. That's what Arq does.
Re: encryption is not gravy by accountoftheday on Monday April 30, 2012 @12:28PM (#3909909)
This is nonsense. Block ciphers do exist.
Re: encryption is not gravy by naner on Monday April 30, 2012 @02:22PM (#3910560)
Yes they do, though I don't think that was what he was referring to.