Hello, I am a french student and I have written a technical report on an extension of the rsync algorithm to crypted files. I started from the situation of a client machine A user who doesn't wish to save an original file v0 and its successive versions v1 v2 v3 ... on a distant server B but rather to save the private ciphering of these files on the server. Let C be the cipher algorithm and xi=C(vi) the ciphering of the clear file vi, the client A wishes to save x0, x1, x2... on the server B and not v0,v1.... This situation arrises for secured files backup providers which offer an option of a secured and confidential file's history backup - a client can keep the history of a file. Trying to use rsync here is not a good solution because the ciphering transformation on file versions disperses the correlations between them and then when Rsync tries to localize common blocks between ciphered versions, he hardly ever finds and the compression resulting from the common sequences factorisation can't happen. My method proposes a solution to this problem and allows to save ciphered versions on a distant server with costs (storage, communications, algorithmic complexity) comparable to rsync. I want to know if anyone finds my work of interest and if anyone of you knows if such a problem have been adressed before. I keep the documentation of my article (in french but i am working on an english translation) for anyone who would have more details. Thank you! Ps: sorry for my small english skill. --------------------------------- Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en fran?ais ! -------------- next part -------------- HTML attachment scrubbed and removed
>>>>> "MM" == mmikaelfr <iso-8859-1> >>>>> wrote the following on Thu, 27 Jun 2002 15:26:51 +0200 (CEST)MM> I am a french student and I have written a technical report on MM> an extension of the rsync algorithm to crypted files. I started MM> from the situation of a client machine A user who doesn't wish MM> to save an original file v0 and its successive versions v1 v2 v3 MM> ... on a distant server B but rather to save the private MM> ciphering of these files on the server. Let C be the cipher MM> algorithm and xi=C(vi) the ciphering of the clear file vi, the MM> client A wishes to save x0, x1, x2... on the server B and not MM> v0,v1.... This situation arrises for secured files backup MM> providers which offer an option of a secured and confidential MM> file's history backup - a client can keep the history of a file. Sounds interesting. Do you mean that the server holds multiple versions of the file so older versions can also be restored? Is this done by storing checksum information about older files on the client? Also, if I understood right, isn't this a bit different from rsync since on the server you wouldn't see the files x0, x1, x2, ... but rather the files x0, d1, d2, ... where d1 is a some kind of delta from x0 to x1 (or I suppose an encrypted delta from v0 to v1)? Or have I misunderstood your system? -- Ben Escoto -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20020627/d134a660/attachment.bin
On Thu, Jun 27, 2002 at 03:26:51PM +0200, Mikael moshir wrote:> > Hello, > > I am a french student and I have written a technical > report on an extension of the rsync algorithm to crypted > files. I started from the situation of a client machine A > user who doesn't wish to save an original file v0 and its > successive versions v1 v2 v3 ... on a distant server B but > rather to save the private ciphering of these files on the > server. Let C be the cipher algorithm and xi=C(vi) the > ciphering of the clear file vi, the client A wishes to > save x0, x1, x2... on the server B and not v0,v1.... This > situation arrises for secured files backup providers which > offer an option of a secured and confidential file's > history backup - a client can keep the history of a file. > > Trying to use rsync here is not a good solution because > the ciphering transformation on file versions disperses > the correlations between them and then when Rsync tries to > localize common blocks between ciphered versions, he > hardly ever finds and the compression resulting from the > common sequences factorisation can't happen. > > My method proposes a solution to this problem and allows > to save ciphered versions on a distant server with costs > (storage, communications, algorithmic complexity) > comparable to rsync. I want to know if anyone finds my > work of interest and if anyone of you knows if such a > problem have been adressed before. I keep the > documentation of my article (in french but i am working on > an english translation) for anyone who would have more > details. Thank you! > > Ps: sorry for my small english skill.That skill is sufficient but you need shorter lines (hit the carriage return). I will try to clarify since it looks like this hasn't been understood. terminology: plaintext == unencrypted file ciphertext == encrypted file client == local system server == distant system You have a client with plaintext files. The server provides access to multiple versions of files but on the server they are encrypted. As you have described it this sounds a great deal like a SCM (source code management) system with encryption thrown in. Presumably the encryption is because the user doesn't wish to trust the owner of the server with maintaining his privacy. Judging by several recent threads there are quite a few people who could be interested. I suggest you look in the list archives for the word "encrypt". You speak of a technical report that i assume actually discusses the method. If you can distill that down (cut out the academic verbiage and focus on actual method sans proofs) to a couple of hundred words or less you could post it for discussion. A link to source code wouldn't hurt. We focus here on what actually works and even broken code speaks louder than speculation. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt