Hi Folks, I was wondering if I could ask this question here. Initially when I was thinking up how to do this I was expecting block encryption to stay consistent from one 'encryption run' to the next, but I found out later that most schemes randomize the result by injecting a random block or seed at the beginning and basing all other encrypted data on that. In order to prevent plaintext attacks I guess (the block at the beginning of many formats is always the same?) and also to prevent an attacker from learning the key based on multiple encryptions using the same key. However the downside is that any optimization scheme is rendered useless, such as rsync's. What is a best practice for this, if any? My backup software that I'm currently using, I'm on Windows, does encryption but since it has the key, it can create differentials/incrementals so the whole image does not need to be retransferred. If it works, but that's another story. Still, differentials and incrementals are all fine (grandfather, father, son) but updating the/a main full image file itself would perhaps be much more efficient still. For some reason my host and rsync on Windows are rather slow, I get some 500K/s upload for a 20GB file. Which takes, kinda long. I might start splitting the files in lower gigabyte chunks as well, though. Currently sending it to another host at 1MB/s which rsyncs it to the real target where I'm less concerned about how long it takes. But I'm sending it over with scp (pscp) because for some reason rsync is also rather slow here (maybe it's my computer). Scp has no partial option (how silly) but I can just rsync if it fails. Still, I wonder how other people are doing this, if they do something like this. Regards, Xen.
Why are you encrypting the files and not the filesystem and the channel? On Tue, Oct 13, 2015 at 6:54 PM, Xen <list at xenhideout.nl> wrote:> Hi Folks, > > I was wondering if I could ask this question here. > > Initially when I was thinking up how to do this I was expecting block > encryption to stay consistent from one 'encryption run' to the next, but I > found out later that most schemes randomize the result by injecting a random > block or seed at the beginning and basing all other encrypted data on that. > > In order to prevent plaintext attacks I guess (the block at the beginning of > many formats is always the same?) and also to prevent an attacker from > learning the key based on multiple encryptions using the same key. > > However the downside is that any optimization scheme is rendered useless, > such as rsync's. > > What is a best practice for this, if any? > > My backup software that I'm currently using, I'm on Windows, does encryption > but since it has the key, it can create differentials/incrementals so the > whole image does not need to be retransferred. If it works, but that's > another story. > > Still, differentials and incrementals are all fine (grandfather, father, > son) but updating the/a main full image file itself would perhaps be much > more efficient still. > > For some reason my host and rsync on Windows are rather slow, I get some > 500K/s upload for a 20GB file. Which takes, kinda long. > > I might start splitting the files in lower gigabyte chunks as well, though. > > Currently sending it to another host at 1MB/s which rsyncs it to the real > target where I'm less concerned about how long it takes. > > But I'm sending it over with scp (pscp) because for some reason rsync is > also rather slow here (maybe it's my computer). > Scp has no partial option (how silly) but I can just rsync if it fails. > > Still, I wonder how other people are doing this, if they do something like > this. > > Regards, > > Xen. > > > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Paolo Bolzoni <paolo.bolzoni.brown at gmail.com> schreef:> Why are you encrypting the files and not the filesystem and the channel?Because of what the other person mentioned. If anything anywhen gets compromised, people may have access to the filesystem(s) and the channel(s) before they get access to the file. That is to say, yes it is a remote host with a form of cloud suppliance. I do not think that I can encrypt that filesystem. Of course, I could encrypt it on the spot but then rsync would also not work. They might take my private key from somewhere, so to speak (that does the transfer) but then they still won't have the file. The local filesystem is encrypted, not one of the others. I mean I see the advantage technically but practically having an encrypted file is way superior for me. They are images, so they are like filesystems themselves. It is a filesystem that is being stored on a filesystem. That's why I encrypt the image. And I store them on remote hosts that I do not control. Regards, X.