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
> 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
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.