The problem
When encrypting data, using a chaining encryption mode, the bytes before effect the value of the bytes that come after. This means a change at byte N effects changes at N+1, N+2 ...
A file:
| X====================|
^
Change at this byte effects the rest
Rsync transfers :
X====================|
----------------------
A solution
Murk encrypts a file but resets the encryption every 8K or so (by default) which localises the effects of changes....
The file:
| X====== |
^
Change at this byte is localised
Rsync transfers :
X======
-------
However, in doing this, the strength of the encrypted file is weakened in
two ways:
1) The reset provides an attacker with a large selection of similarly
encrypted blocks. This makes it weaker than standard cbc encryption. 2) Identical blocks will encrypt to the same result. This allows a statistical
analysis to be run on the encrypted file which gives away information about its contents.
It is hoped that future versions of murk will address point (1). Unfortunately, it is not possible to do anything about point (2) without destroying rsync efficiency.
Peformance
In terms of being efficient when transfering data with rsync, murk needs special conditions to be of any use. The tables below show bytes transfered in two example transfers:
Plain rsync is rsync on the uncompressed files mcrypt -p compresses a whole file with bzip2 and then encrypts it.
- Transfering openssl-0.9.7e.tar onto openssl-0.9.7d.tar (the intial files were not gziped). Size of openssl-0.9.7e is 15418880 bytes.
Plain rsync 4353737
mcrypt -p then rsync 2452373
murk then rsync 3570755
This shows that both murk and rsync on uncompressed data cannot compete with a well compressed file. This is because there is around 25% difference in the two files and the data is nicely compressible. It doesn't matter that the compression badly messes with the efficiency of rsync since the whole file compressed is smaller that the uncompressed deltas.
2) In a more of a backup scenario, this is my docs directory (600MB) with a
new manual (100K) added.
Plain rsync 110192
mcrypt -p then rsync 80754324
murk then rsync 119486
It is in situations like this that murk can be useful. These are small changes in big pieces of data.