Editing Configuration File Disables MACs

[lipnitsk]

From: https://defuse.ca/audits/encfs.htm

Exploitability: High
Security Impact: Medium

The purpose of MAC headers is to prevent an attacker with read/write access to the ciphertext from being able to make changes without being detected. Unfortunately, this feature provides little security, since it is controlled by an option in the .encfs6.xml configuration file (part of the ciphertext), so the attacker can just disable it by setting "blockMACBytes" to 0 and adding 8 to "blockMACRandBytes" (so that the MAC is not interpreted as data).

EncFS needs to re-evaluate the purpose of MAC headers and come up with something more robust. As a workaround, EncFS could add a command line option --require-macs that will trigger an error if the configuration file does not have MAC headers enabled.

[samrocketman]

From the audit conclusion.

EncFS is probably safe as long as the adversary only gets one copy of
the ciphertext and nothing more. EncFS is not safe if the adversary
has the opportunity to see two or more snapshots of the ciphertext at
different times.

I use a git repository to track my encfs encrypted files when it is not mounted (to take snapshots and the like). Does that mean I'm doing my own data security a disservice? I started using EncFS after that fiasco with truecrypt.

I realize using git with EncFS in that way is not the norm which is why I pose this question.

[rfjakob]

The issue you are referring to is tracked in bug #9, that a stream cipher is used to encrypt the last block. That is, the issue affects the last 1kB of each file. If the attacker has two snapshots of an encrypted file, he can determine what has changed between those copies in the last 1kB. So yes, by tracking the encrypted files in git, the attacker gets those snapshots for free.
This will be fixed once the stream cipher is switched out for ciphertext stealing (on the agenda, see bug #9).

[rfjakob]

Released in 1.8.1.