download |  support |  manpage

murk

News

What is it?

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.

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

cvs access

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/murk login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/murk co murk0