Hacker News Reader

Comment by SugoiDev | Hacker News Reader

A delta of changes in an encrypted container should be very close to the size of the full container, shouldn't?

It seems this will only be feasible when we have homorphic encryption ready.

If someone is interested on that kind of encryption, see "A FULLY HOMOMORPHIC ENCRYPTION SCHEME"[1] and "Fully Homomorphic Encryption without Bootstrapping "[2]

[1] https://crypto.stanford.edu/craig/craig-thesis.pdf

[2] https://eprint.iacr.org/2011/277.pdf

View on HN

Well the whole hard drive is not overwritten every time a file changes when using disk encryption, so definitely not necessary.

Any encrypted disk image will work this way. It doesn’t require anything like homomorphic encryption, just a bit of metadata and key management.

No. AES encrypts blocks (I think 256kb?). So that's the only thing you have to sync.

If you use plain AES ECB, then little penguins will show up in your encrypted data. You would want to use a disk encryption scheme, like XTS, where the encryption is not just based on the data of the block, but also on the index of the block, to prevent identical blocks at different locations from looking identical. You also want it to be based on a nonce of some sort, to prevent attackers from reverting a block to an older copy.

Penguins? What are you talking about?

I don't care about low-level encryption details. That's why I use encryption software instead of coding my own.

ECB has issues:

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...

You should absolutely care about the difference between ECB and a stream cipher mode like CBC. ECB is way less safe.

That would depend on the cipher mode, no? Assuming the container is using something like CTR, the diff should only consist of changed bytes.

Reply on news.ycombinator.com