Can we encrypt copied files on target machine?

Jose' Sebrosa

unread,

Oct 10, 2001, 3:30:10 PM10/10/01

to

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

Jacob Martinson

unread,

Oct 10, 2001, 4:02:06 PM10/10/01

to

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

Bennett Todd

unread,

Oct 10, 2001, 4:58:46 PM10/10/01

to

--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7xLNKHZWg9mCTffwRAtfHAJ45pb8wTiaQeWrV2zuIGRP1H6q7tACeJFX3
ceNBocYeS+O0qyuv1RAOd4g=
=NO2N
-----END PGP SIGNATURE-----

--cWoXeonUoKmBZSoM--

Pierre Abbat

unread,

Oct 11, 2001, 9:13:45 AM10/11/01

to

On Wednesday 10 October 2001 16:44, Bennett Todd wrote:
> 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.

I've used rsync to CFS. Works fine. root can't read a CFS volume as root, but
of course root can su to anyone else. Not that it matters on my box since I
am root.

phma