rsync - Oct 2001 - Can we encrypt copied files on target machine?

The problem
-----------

I want to copy a file from machine A (master) to machine B (backup) but I would
like to stop root user on machine B to easily look at the file contents.  So I
encrypt the file to send at machine A and send just the encrypted version to
machine B (which has no means to decrypt the file).

Then I make a small change in the file in the machine A and want to send the
new version to machine B.  If I simply repeat the procedure (encrypt at A and
rsync with B) I lose the rsync advantages, since a local change in the raw file
leads to a global change in the encrypted file.


The solution?
-------------

Maybe I can split the raw file at A in several parts, encrypt them separately
and send them as separated files to B, along with info on how to rebuild the
file from the *decrypted* parts (remember, B doesn't know how to decrypt). 
The
problem then would be to keep at A a record of the parts sent do B, in order to
decide how to split the file the next time A wants to send it to B (the
spliting is not trivial, since the parts must be equal to those already at B if
possible).

So eventually I finish using the rsync algorythm, not to do the final copy of
files from A to B, but to do the splitting of the raw file at A into parts.  I
just need to build an auxiliary file with info on how to join the parts,
instead of the parts already joined.


The questions
-------------

Can rsync do the spliting and build info on how to join instead of joining?
Does anyone have this kind of problem?
Has the problem an easier solution?
Am I missing something?

Thanks,
Sebrosa

Why not rsync to a system where you are the root user?  

On Wed, Oct 10, 2001 at 08:27:35PM +0100, Jose' Sebrosa
wrote:
> 
> The problem
> -----------
> 
> I want to copy a file from machine A (master) to machine B (backup) but I
would
> like to stop root user on machine B to easily look at the file contents. 
So I
> encrypt the file to send at machine A and send just the encrypted version
to
> machine B (which has no means to decrypt the file).
> 
> Then I make a small change in the file in the machine A and want to send
the
> new version to machine B.  If I simply repeat the procedure (encrypt at A
and
> rsync with B) I lose the rsync advantages, since a local change in the raw
file
> leads to a global change in the encrypted file.
> 
> 
> The solution?
> -------------
> 
> Maybe I can split the raw file at A in several parts, encrypt them
separately
> and send them as separated files to B, along with info on how to rebuild
the
> file from the *decrypted* parts (remember, B doesn't know how to
decrypt).  The
> problem then would be to keep at A a record of the parts sent do B, in
order to
> decide how to split the file the next time A wants to send it to B (the
> spliting is not trivial, since the parts must be equal to those already at
B if
> possible).
> 
> So eventually I finish using the rsync algorythm, not to do the final copy
of
> files from A to B, but to do the splitting of the raw file at A into parts.
I
> just need to build an auxiliary file with info on how to join the parts,
> instead of the parts already joined.
> 
> 
> The questions
> -------------
> 
> Can rsync do the spliting and build info on how to join instead of joining?
> Does anyone have this kind of problem?
> Has the problem an easier solution?
> Am I missing something?
> 
> Thanks,
> Sebrosa
>

How about using something like the Cryptographic File System (CFS),
where the files are stored encrypted locally, and the encryption is
confined to blocks. This is done to make the encrypted files
random-addressable in the CFS implementation, but a consequence it
seems to me is that at least some changes might still rsync
efficiently.

Or maybe you'd be better off using CFS to a mirrored drive, where
one half of the mirror is a network block device provided from the
far end.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20011010/f7a8d4ae/attachment.bin