Robin Lee Powell wrote: > On Mon, Apr 28, 2008 at 12:44:10AM +0300, Shachar Shemesh wrote: > >> o Using the later, I find it hard to believe that it >> actually provides rsync friendliness. In particular, >> does it provide rsync friendliness if the change (not at >> the end of the file) caused a modification to the file >> size? >> > > OK, here's what I did: > > dd if=/dev/zero of=test_long1 bs=1M count=16 > dd if=/dev/urandom of=test_rand_1m bs=1M count=1 > cat test_long1 test_rand_1m >test_long2 > cat test_rand_1m test_long1 >test_long3 > cat test_rand_1m test_long1 test_rand_1m >test_long4 > >
> So yeah, it appears to work. If you want me to test something else, > let me know. > Your change is block aligned. Try a change that is one byte long. > It's worth noting that I prioritized rsyncability over security in > my setup; I used block encoding, and no IV at all. > Like I said in my earlier email, I suspect that block encoding actually increases security. Also, if rsyncrypto provides rsyncability enough for you, there should be no problem with adding the IV back. The IV will make different file names have different session keys, but rsyncrypto has that too. (In actuality, that is not a correct statement. The IV will cause different files to have different encodings for the same data. As far as cryptographic strength goes, they actually WILL have the same key, which means that rsyncrypto still has more secure encoding in this case as well). > > Stream mode only affects files names, AFAICT. > I don't know. I haven't seen the actual algorithm explained. What I gathered from the presentation I read was that block mode meant encrypting the file in CBC mode, reverting to a known IV every "block" while stream mode meant using CFB. For comparison sake, rsyncrypto uses CBC, reverting to a known IV in a self synchronizing way, so that block sizes are dynamic by track specific points in the file. This, itself, is a potential information leak about the plain text file, but an extremely minor one (and will be even smaller for rsyncrypto 2). All ciphers suffer when almost the same data is re-encrypted using the same key. CBC is rather robust. CFB, however, has a huge problem. Any change means that two different plain texts are XORed with the same pseudo random stream. By simply XORing the two versions, Eve has a XOR of the two plain texts encrypted. Assuming they are not very random, a simple double frequency analysis will give her a good chance of cracking the plain text. What's worse, once cracked, this applies to ALL future encryptions using the same key. > -Robin > > Shachar ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Rsyncrypto-devel mailing list Rsyncrypto-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
