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

Reply via email to