Encryption
Hi all, I recently came across a possible requirement of backing up certainfiles on a remote server ... in an encrypted format. This got me seriously thinking about the possibility of doing such a thing with rsync. I am not too knowledgable about encryption and the mechanisms of the rsync algorithm (at least as yet :), but I would like to know whether this is attainable or 'far fetched' so to speak. In other words, the requirement would be that rsync encrypts the data in transmission (like is done with ssh), but the data is stored on the receiver still encrypted. The reverse (i.e. decryption with private key) would be done only when the client is retreiving the data from the server. The idea is that data stored on the remote server would be unreadable to the people on that side, but can be decrypted when rsyncing back to the local server in case of data loss. I have amedium to goodknowledge of C, but before delving into understanding the rsyncsource,I wanted to hear any opinions on how possible, if at all, this is... Julian -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Encryption
Julian Pace Ross wrote... The idea is that data stored on the remote server would be unreadable to the people on that side, but can be decrypted when rsyncing back to the local server in case of data loss. In that case encyption will have to take place before transmission anyway. Else you do rely on an uncorrpted rsync on the remote side. My solution for that problem is outside of rsync. I am using an encrypted filesystem where encryption takes place on the local side and the actual storage is accessed via the network. rsync itself is a local (file only) operation then. The network block device in Linux would be a nice thing for that but it lacks a lot of features to make it usable (according bug reports are on my todo list). So currently my solution is really ugly: The remote side exports (via nfs) a directory with a single huge file. The directory is mounted, then that image using loopback and encryption. This works but results in poor performance as caching is virtually disabled. Christoph -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Encryption
In order for the rsync algorithm to work, both sides have to be looking at data in the same format (i.e. both either process encrypted data or unencrypted data). If you want a true public key/private key system, then the only way to do it is to encrypt and decrypt on the client side. That creates two problems - the client has to encrypt the file it wants to send completely, prior to talking to the daemon, regardless of file size (which creates a scalability issue) - Calculating the binary change of encrypted files creates an issue. If I have two separate versions of the same file, their encrypted counterparts will be identical at the binary level until the first change in one verses the other. That means that if you modify the beginning of a file (just change the first bit), the two files will be completely different. There is another option that we have implemented in a backup scenario. If youre interested, please email me directly. Alex From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julian Pace Ross Sent: Sunday, April 16, 2006 12:44 PM To: rsync@lists.samba.org Subject: Encryption Hi all, I recently came across a possible requirement of backing up certainfiles on a remote server ... in an encrypted format. This got me seriously thinking about the possibility of doing such a thing with rsync. I am not too knowledgable about encryption and the mechanisms of the rsync algorithm (at least as yet :), but I would like to know whether this is attainable or 'far fetched' so to speak. In other words, the requirement would be that rsync encrypts the data in transmission (like is done with ssh), but the data is stored on the receiver still encrypted. The reverse (i.e. decryption with private key) would be done only when the client is retreiving the data from the server. The idea is that data stored on the remote server would be unreadable to the people on that side, but can be decrypted when rsyncing back to the local server in case of data loss. I have amedium to goodknowledge of C, but before delving into understanding the rsyncsource,I wanted to hear any opinions on how possible, if at all, this is... Julian -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Encryption
Hi guys I have experimented with a similar approach, in my case the backup server does 'pull' of data, using rsync+ssh, saving it into a encryopted loopback file system image. At the moment I am experimenting with a linux metadevices based encrypted file systems that are only mounted to receive the special files. In both cases I run into how to sotre the key (or passphrase) safely problems, but that is lieft for you to solve, because much of your solution depends on your own circumstanmces and risk analysis. Cheers Tom On Sun, Apr 16, 2006 at 08:16:32PM +0200, Christoph Biedl wrote: Julian Pace Ross wrote... The idea is that data stored on the remote server would be unreadable to the people on that side, but can be decrypted when rsyncing back to the local server in case of data loss. In that case encyption will have to take place before transmission anyway. Else you do rely on an uncorrpted rsync on the remote side. My solution for that problem is outside of rsync. I am using an encrypted filesystem where encryption takes place on the local side and the actual storage is accessed via the network. rsync itself is a local (file only) operation then. The network block device in Linux would be a nice thing for that but it lacks a lot of features to make it usable (according bug reports are on my todo list). So currently my solution is really ugly: The remote side exports (via nfs) a directory with a single huge file. The directory is mounted, then that image using loopback and encryption. This works but results in poor performance as caching is virtually disabled. Christoph -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Tomasz M. Ciolek *** tmc at dreamcraft dot com dot au *** GPG Key ID: 0x41C4C2F0 GPG Key Fingerprint: 3883 B308 8256 2246 D3ED A1FF 3A1D 0EAD 41C4 C2F0 Key available on good key-servers *** signature.asc Description: Digital signature -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 3692] New: regression: symlinks are created as hardlinks with --link-dest
https://bugzilla.samba.org/show_bug.cgi?id=3692 Summary: regression: symlinks are created as hardlinks with -- link-dest Product: rsync Version: 2.6.7 Platform: x86 URL: http://rsync.samba.org OS/Version: FreeBSD Status: NEW Severity: major Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] hi. this refers to the official 2.6.7 release, no mods. was working on verifying some older bugs and this one popped up as new, it used to work ok. wanted to get it posted though i've no patch. will gladly test any submitted. regression: symlinks are created as hardlinks with --link-dest the first run creates them erroneously as hardlinks. a single repeat of the same command 'fixes' the mistake of the first and should not be necessary. the nth repeat of the same command does nothing because it's now in sync. by verbose example... ## show the current state of things [] ls -aliT 0 1 2 3 4 ls: 1: No such file or directory ls: 2: No such file or directory ls: 3: No such file or directory ls: 4: No such file or directory 0: 550260 drwxr-x--- 2 moo moo 512 Apr 16 22:35:34 2006 . 415920 drwxr-xr-x 5 moo moo 512 Apr 17 00:46:06 2006 .. 550261 prw-rw 1 moo moo 0 Aug 9 02:01:36 2005 fifo0 550262 prw-rw 2 moo moo 0 Aug 2 00:47:06 2005 fifohard1 550262 prw-rw 2 moo moo 0 Aug 2 00:47:06 2005 fifohard2 550270 -rw-rw 1 moo moo 0 Aug 9 02:01:36 2005 file0 550271 -rw-rw 2 moo moo 0 Jul 31 22:58:45 2005 filehard1 550271 -rw-rw 2 moo moo 0 Jul 31 22:58:45 2005 filehard2 550263 brw-rw 1 moo moo2, 2 Aug 9 02:01:36 2005 nullb0 550264 brw-rw 2 moo moo2, 2 Aug 4 01:48:48 2005 nullbhard1 550264 brw-rw 2 moo moo2, 2 Aug 4 01:48:48 2005 nullbhard2 550265 crw-rw 1 moo moo2, 2 Aug 9 02:01:36 2005 nullc0 550266 crw-rw 2 moo moo2, 2 Aug 4 01:50:01 2005 nullchard1 550266 crw-rw 2 moo moo2, 2 Aug 4 01:50:01 2005 nullchard2 550267 srw-rw 1 moo moo 0 Aug 9 02:01:36 2005 socket0 550268 srw-rw 2 moo moo 0 Aug 4 02:05:00 2005 sockethard1 550268 srw-rw 2 moo moo 0 Aug 4 02:05:00 2005 sockethard2 550273 -rw-r- 1 moo moo 0 Apr 16 21:47:16 2006 source0 550269 lrwxr-x--- 1 moo moo 7 Apr 16 21:57:12 2006 target1 - source0 ## ok, now copy 0 to 1 using 0 as a reference... # the use of 0 as a reference when initializing the # first copy is valid though perhaps confusing. it also # happens to make writing backup scripts easier by # eliminating some initialization logic. [] rsync -Haxv --delete --link-dest=`pwd`/0/ ./0/ ./1/ created directory ./1 ./ fifo0 fifohard2 fifohard1 = fifohard2 socket0 sockethard2 sockethard1 = sockethard2 # ...hey where'd that hardlink come from and where's my symlink? # perhaps using link() instead of symlink(). [] ls -aliT 1 550259 drwxr-x--- 2 moo moo 512 Apr 16 22:35:34 2006 . 415920 drwxr-xr-x 6 moo moo 512 Apr 17 00:47:08 2006 .. 550272 prw-rw 1 moo moo 0 Aug 9 02:01:36 2005 fifo0 550274 prw-rw 2 moo moo 0 Aug 2 00:47:06 2005 fifohard1 550274 prw-rw 2 moo moo 0 Aug 2 00:47:06 2005 fifohard2 550270 -rw-rw 2 moo moo 0 Aug 9 02:01:36 2005 file0 550271 -rw-rw 4 moo moo 0 Jul 31 22:58:45 2005 filehard1 550271 -rw-rw 4 moo moo 0 Jul 31 22:58:45 2005 filehard2 550263 brw-rw 2 moo moo2, 2 Aug 9 02:01:36 2005 nullb0 550264 brw-rw 4 moo moo2, 2 Aug 4 01:48:48 2005 nullbhard1 550264 brw-rw 4 moo moo2, 2 Aug 4 01:48:48 2005 nullbhard2 550265 crw-rw 2 moo moo2, 2 Aug 9 02:01:36 2005 nullc0 550266 crw-rw 4 moo moo2, 2 Aug 4 01:50:01 2005 nullchard1 550266 crw-rw 4 moo moo2, 2 Aug 4 01:50:01 2005 nullchard2 550275 srw-rw 1 moo moo 0 Aug 9 02:01:36 2005 socket0 550276 srw-rw 2 moo moo 0 Aug 4 02:05:00 2005 sockethard1 550276 srw-rw 2 moo moo 0 Aug 4 02:05:00 2005 sockethard2 550273 -rw-r- 3 moo moo 0 Apr 16 21:47:16 2006 source0 550273 -rw-r- 3 moo moo 0 Apr 16 21:47:16 2006 target1 # lets see what happens if it's run again... [] rsync -Haxv --delete --link-dest=`pwd`/0/ ./0/ ./1/ target1 - source0 # ...the second run seems to have fixed the problem... [] ls -aliT 1 550259 drwxr-x--- 2 moo moo 512 Apr 16 22:35:34 2006 . 415920 drwxr-xr-x 6 moo moo 512 Apr 17 00:47:08 2006 .. 550272 prw-rw 1 moo moo 0 Aug 9 02:01:36 2005 fifo0 550274 prw-rw 2 moo moo 0 Aug 2 00:47:06 2005 fifohard1 550274 prw-rw 2 moo moo 0 Aug 2 00:47:06 2005 fifohard2 550270 -rw-rw 2 moo moo 0 Aug 9 02:01:36 2005 file0
