Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
[Full-disclosure] Multiple Vulnerabilities in EncFS

From: Micha Riser (michapovworld.org)
Date: Thu Aug 26 2010 - 07:05:18 CDT

EncFs is a file system encryption solution for Linux and can be found on

A security analysis of EncFS has revealed multiple vulnerabilities:
(1) Only 32 bit of file IV used
(2) Watermarking attack
(3) Last block with single byte is insecure

1. Only 32 bit of file IV used
By default, EncFS adds an 8byte random value as header of each encrypted file.
These bytes are supposed to be used to randomize the initialization vectors of
the blocks. However, we have noticed that from these 8 bytes, only 4 bytes are
actually used for this purpose. The other 4 bytes get lost as a uint64
datatype is handled over as a 32-bit integer argument.

2. Watermarking attack
Watermarking is an attack which does not give any secrets to the attacker but
allows him to prove that the user of the encrypted file system has a certain
file stored on his drive. The file has previously been specially prepared by the

Following [1], data encrypted with the CBC cipher mode is vulnerable to
watermarking attacks under some circumstances. Consider a file which is divided
into file blocks B1 , ..., Bk of blocksize which are individually encrypted
using CBC and AES (whereas each file block consists of blocksize/16 cipher
blocks) (as in EncFS). The attack succeeds if the attacker is able to
calculate the XOR of the initialization vectors (IV) for some Bi and Bj , i !=
j. If so, the attacker prepares the first plain text blocks of block i and j
  Pi1 XOR Pj1 = IV(i) XOR IV(j)
and therefor
  Pi1 XOR IV(i) = Pj1 XOR IV(j)
This causes that
 Ci1 = Enc(Pi1 XOR IV(i)) = Enc(Pj1 XOR IV(j)) = Cj1
i.e. the first cipher block of file blocks i and j are identical. Therefore, the
attacker can test the cipher blocks Ci1 and Cj1 and conclude with high
probability whether this is his prepared file or not.

We analyzed the distribution of IV(i) XOR IV(j) for a randomly chosen blocks
and a random so-called fileIV which is used to make the IVs different from file
to file. This showed that IV(i) XOR IV(j) is not at all uniformly distributed.
There is a certain value for IV(i) XOR IV(j) which is highly more probable
that expected for a uniform distribution (2*10^-4).

We then watermarked a file such that the even file blocks start with the found
value and the odd file blocks with all zero. So, the encrypted file is
successfully recognized by testing whether there are two consecutive file
blocks that start with the same cipher block. Using a file with 50000 blocks we
achieved a probability of > 99.9% of recognizing the watermarked file.

3. Last block with single byte is insecure
The CFB cipher mode is insecure if it is used twice with the same
initialization vector. In CFB, the first block of the plain text is XOR-ed with
the encrypted IV:
  C0 = P0 XOR Ek (IV )
Therefore, for two cipher blocks C0 and C0' encrypted with the same IV, it
holds that:
  C0 XOR C0' = (P0 XOR Ek (IV )) XOR (P0' XOR Ek (IV )) = P0 XOR P0'
This means that an attacker gets the XOR of the two plain texts. EncFs uses a
modified version of CFB which additionally shuffles and reverses bytes. It is not
clear however, if the modifications generally help against this problem.

A security problem arises definitely if the last block contains only a single
byte and an attacker has two versions of the last block. Operating on a single
byte, the shuffle and reverse operation do nothing. What remains is a double
encryption with CFB and XOR-ing the two cipher bytes gives the XOR of the
two plain text bytes due to the reason described above. Encrypting the last
block with a stream cipher instead of a block cipher saves at most 16 bytes
(one cipher block). We think it would be better to sacrifice these bytes and in
exchange rely only on a single encryption mode for all blocks which simplifies
both the crypto analysis and the implementation.


[1] Clemens Fruhwirth. New methods in hard disk encryption. Technical
reportInstitute for Computer Languages, Vienna University of Technology, 2005.

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/