Generating Block IV by XORing Block Number

[lipnitsk]

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

Exploitability: Low Security Impact: Medium

Given the File IV (an IV unique to a file), EncFS generates per-block IVs by XORing the File IV with the Block Number, then passing the result to setIVec(), which is described in #9. This is not a good solution, as it leads to IV re-use when combined with the last-block stream cipher issue in #9:

The stream algorithm (see previous section) adds 1 to the IV, which could undo the XOR with the block number, causing the IV to be re-used. Suppose the file consists of one and a half blocks, and that the File IV's least significant bit (LSB) is 1. The first block will be encrypted with the File IV (block number = 0). The second (partial) block will be encrypted with File IV XOR 1 (since block number = 1), making the LSB 0, using the stream algorithm. The stream algorithm adds 1 to the IV, bringing the LSB back to 1, and hence the same IV is used twice. The IVs are reused with different encryption modes (CBC and CFB), but CFB mode starts out similar to CBC mode, so this is worrisome.

EncFS should use a mode like XTS for random-access block encryption.

Correction 12/05/2014: XTS mode is probably not the ideal option, see Thomas Ptacek's blog post for good reasons why.

[vgough]

Thanks for the link.

[rianhunter]

As an alternative to XTS, how about storing IVs on a per block (size configurable) basis, as opposed to a per-file? Basically each atomic write block of EncFS is prefixed a new random IV.

This would slow down writes and increase storage overhead but a user could tweak the tradeoff by configuring block size.

[jetwhiz]

Are we considering Galois/Counter Mode as a fix? That would take care of this issue as well as issue 2.1 from the audit (Same Key Used for Encryption and Authentication).