transferring large encrypted images.

[Selva Nair]

On Tue, Oct 13, 2015 at 12: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?
>

If the backup is from an encrypted volume to another, depending on the
scheme used, you could arrange rsync to see only decrypted data (with the
transport protected by, say, ssh): for example, both destination and source
using eCryptfs could have the decrypted volumes mounted during the backup.

But this may not be necessary: Directly backing up an encrypted volume
could still make use of rsync's delta algorithm:.in case of eCryptfs, for
example, data is encrypted in blocks of page_size (e.g., 4kB), so only a
few blocks may change during updates and subsequent rsync runs could be
almost as efficient as on unencrypted volumes -- I haven't tested this
though.

If encryption is only to protect the data during transport, you can simply
use ssh transport with rsync.

If the idea is to protect the data at a remote backup destination, say on
the cloud, rsync may not be the best option. For that I prefer duplicity
which uses the rsync algorithm to transfer only deltas (uses librsync) but
stores the backup as tar archives encrypted by GnuPG (both the initial full
backup as well as incremental deltas). You lose the advantage of a mirror
archive that rsync can maintain.

Selva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20151013/a9b77932/attachment.html>