Projects / murk

murk

murk is an rsync-friendly encryption that runs on the Unix command line. Users can encrypt a file and backup the changes to an untrusted host.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  01 Apr 2005 12:31

    Release Notes: This release changes the encryption reset behaviour so that a different IV is used with each section of file. Cygwin is now actively supported. This release is not compatible with the files produced by previous releases.

    •  27 Jan 2005 19:59

      Release Notes: Decryption has been made easier by putting settings such as the cipher type into the file header. An unattended mode has been added so that encryption can be done by a script with murk reading keys from a file. Performance has been improved when used with Rsync. There is support for bigger block sizes, which is good for large files that have rare or small changes.

      •  02 Oct 2004 20:07

        Release Notes: Data corruption on decryption was fixed. Installation tests were added. More platforms are supported.

        •  12 Sep 2004 13:13

          No changes have been submitted for this release.

          Recent comments

          27 Jan 2005 13:22 alienscience

          Re: Not quite as strong
          This is true. The repeated block issue hadn't occured to me either -- and thats something that will never go away since its the very thing that makes the files useful with rsync. Currently, there is a disclaimer at the bottom of the manpage, however I'll add it to the homepage in the description of murk's operation.


          My only idea for getting round the weaknesses, in resetting the encryption, is to have a different key for each block. What I haven't worked out is how to generate these keys in a predicable way so that different generations of a file can be efficiently rsynced. By predicable, I mean a block of data always gets encrypted with the same key.


          However, it is interesting you mention the importance of the iv being reset to its original value. Would there be any mileage in resetting the iv to, say, a checksum or digest of the plain text block? Indentical blocks would encrypt identically but similar blocks would give away less about their contents.

          27 Jan 2005 12:27 phirate

          Not quite as strong
          You may have already considered this, but "resetting" the encryption I assume means returning to the IV generated from the passphrase. If you do this every 8k for example, you provide any attacker with a large set of similarly produced ciphertexts. In addition, every 8k block that is equal will encrypt to the same value allowing the attacker to make inferences about the contents of the file from the prevalence of particular encrypted results.

          I'm not convinced either of these issues is a particularly big deal in this case, but it might be worth noting somewhere prominent that block ciphers are chained for these exact reasons, and that the user should understand that the resulting encrypted file is not as strong as one produced normally. I think it's more than fair to say (assuming you're using a decent cipher :) that it is still plenty strong enough for regular data, although I'd be worried about anything that someone might take a few months to try and break.

          Screenshot

          Project Spotlight

          OpenStack4j

          A Fluent OpenStack client API for Java.

          Screenshot

          Project Spotlight

          TurnKey TWiki Appliance

          A TWiki appliance that is easy to use and lightweight.