<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><span class=""><div class="gmail_quote">On Tue, Oct 13, 2015 at 12:54 PM, <span>Xen</span> <span dir="ltr"><<a href="mailto:list@xenhideout.nl" target="_blank">list@<span>xenhideout</span>.<span>nl</span></a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="overflow:hidden">Hi Folks,<br>
<br>
I was wondering if I could ask this question here.<br>
<br>
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.<br>
<br>
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.<br>
<br>
However the downside is that any optimization scheme is rendered useless, such as rsync's.<br>
<br>
What is a best practice for this, if any?</div></blockquote><div> </div></div></span>If the backup is from an encrypted volume to another, depending on the scheme used, you could arrange <span>rsync</span> to see only decrypted data (with the transport protected by, say, ssh): for example, both destination and source using <span>eCryptfs</span> could have the decrypted volumes mounted during the backup.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">But this may not be necessary: Directly backing up an encrypted volume could still make use of <span>rsync's</span> delta algorithm:.in case of <span>eCryptfs</span>, for example, data is encrypted in blocks of page_size (e.g., 4kB), so only a few blocks may change during updates and subsequent <span>rsync</span> runs could be almost as efficient as on unencrypted volumes -- I haven't tested this though.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If encryption is only to protect the data during transport, you can simply use ssh transport with <span>rsync</span>. </div><div class="gmail_extra"><br></div><div class="gmail_extra">If the idea is to protect the data at a remote backup destination, say on the cloud, <span>rsync</span> may not be the best option. For that I prefer duplicity which uses the <span>rsync</span> algorithm to transfer only deltas (uses <span>librsync</span>) but stores the backup as tar archives encrypted by <span>GnuPG</span> (both the initial full backup as well as incremental deltas). You lose the advantage of a mirror archive that <span>rsync</span> can maintain. </div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"> </div><div class="gmail_extra"><span>Selva</span></div></font></span></div>
</div><br></div>