Eran Tromer wrote:
On 25/06/05 22:26, Shachar Shemesh wrote:
encrypting the information we rsync
Not just over the wire, according by your webpage, but even backup
server can't decrypt it. Excellent.
Otherwise we gain nothing.
But how can you do that with a secure (hence chained) encryption mode
while maintaining the communication efficiency of rsync? The only way I
see is to keep the backup data in numerous separately encrypted
fragments (inconvenient)
not only inconvenient, but won't solve your fundamental problem.
and have the sender transmit the encrypted
block hashes (communication cost)
Receiver, if anything. No, that will never do.
or keep them between sessions
(stateful).
That will most certainly never do.
It's also susceptible to traffic analysis, but that's
probably not a major concern.
It's a good question whether traffic analysis is a concern. As far as
algorithms go, our analysis assumes that we have only two parties. The
user of the backup server (Alice) and the backup server operator
(Mellisa), who is also the adversary. This means that Mellisa can
perform actual comparing of before and after images, possibly even
affecting the delta encrypted.
Consider, for example, a case where your company rents Lingnu's backup
services. One of the things most crucial to a company is its customer
list, which is therefor, obviously, also backed up.
I want to gain said customer list. I therefor enroll, under an assumed
name, as your customer, giving crafted information as my personal
details. I then analyze the changes that happened to the encrypted file
as a result.
As far as I can tell, the encryption method we use is reasonably
resilient to even this kind of attack.
They had the same problem with gzipped files, BTW, and proposed
solutions were to either gunzip+gzip on the fly (but then the resulting
gz file may differ from the original even though its content is
identical) or to use a patched gzip which occasionally resets the
compression state. Neither is applicable in this case.
Actually, the resulting algorithm draws a lot from the rsyncable patch
to gzip. Naturally, further changes were necessary, but we do, in fact,
compress the encrypted data, and we use rsyncable gzip in order to do that.
Eran
As far as I can tell, there are two ways I can answer this email. I can
tell you that you can't realistically expect me to explain, on a public
list, without making you sign an NDA first, the main competitive
advantage we have, or to disclose our trade secret patent protected
algorithm (and I wouldn't be the first one to think, mistakingly, that
it is possible to patent trade secrets).
Or, I can tell you to hold your breath just a little bit longer, and
hear all about it in the up coming August Penguin, where I'm giving a
lecture on the way this precise algorithm is built, as well as publish a
paper performing cryptanalysis of it.
If you feel truly impatient, feel free to download rsyncrypto, the
program we use to perform the actual magic, and analyze it. The project
is at http://sourceforge.net/projects/rsyncrypto, and the utility itself
is GPL. If you find bugs, I will be more than happy to receive patches
:-). The program is also a single "apt-get install" away for any Debian
system, possibly also Ubunto and other derivatives. It has even made it
into Sarge, despite being integrated into Sid after the official Sarge
feature freeze. I can't say I understand it, but as the maintainer, I am
not complaining.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
