Questions about hardlinks in reverse mode

[Aikhjarto]

In the conclusion, the old audit of encfs there is a paragraph I do not understand:

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. EncFS attempts to protect files from malicious
modification, but there are serious problems with this feature.

Is this still true for the current 1.9.x versions of encfs?

I want to rsync a directory tree containing hardlinked files to an off-site location and intend to use the reverse mode of encfs for encryption. Does the above statement apply for hardlinks in reverse mode?

[rfjakob]

Yes this still applies, nothing was changed in the crypto.

Are you clear how the vulnerability works? (So you can judge how it affects your use case)

[benrubson]

Not sure however that having hard-linked files in the encfs FS makes this vulnerability easier to exploit.
I see no reason.
@rfjakob ?

[Aikhjarto]

@rfjakob No, I'm not clear how the vulnerability works. This is why I'm asking. I'm not even sure which parts of the audit refer to normal and which to reverse mode.

[rfjakob]

Ok. The problem is with the last block of a file. If that block is modified, without the length of the file changing too much, you can see what has changed in the block with bit granularity (you get the XOR of of the block plaintexts).

[rfjakob]

The same attack applies to reverse mode, in a more severe form: In reverse mode, files don't have a unique file id. So you can perform the XOR attacks on the last block even across different files, provided that they are about the same length (within 1kiB).

[benrubson]

In reverse mode, files don't have a unique file id.

I think they can ? based on their inode number. This can however leads to some limitations (explained in the man page).

[rfjakob]

That is correct, I implemented that a while ago. However I later decided that it can cause too much headache for users (all the encrypted data changes when you move the files to a new filesystem) and it is disabled by default.

[benrubson]

Absolutely (these are the limitations documented into the man page).
I was thinking about another way to implement this, but did not found yet :) Not easy !

[Aikhjarto]

Ok, just for clarification:
In normal mode if I have two files just differs in the last block, the last block can be decrypted by an adversary.
In reverse mode the last blocks of all files with similar sizes can be decrypted by an adversary.
Are those statements correct?

[rfjakob]

In normal mode if I have two files just differs in the last block, the last block can be decrypted by an adversary.

File header must be the same, then yes

In reverse mode the last blocks of all files with similar sizes can be decrypted by an adversary.

Yes

PS: I'm not sure if you can completely decrypt the last block, the original report is also not clear on that. But you can at least get some information about the plaintext out of it.

[rfjakob]

@benrubson Sorry, missed the question about the hard links: I also don't see a reason hard links make things different.

[benrubson]

In reverse mode the last blocks of all files with similar sizes can be decrypted by an adversary.

Use Per-File Initialization Vectors in reverse mode to mitigate this (as if you were in normal mode).
But be aware of the limitation discussed above.

[Aikhjarto]

Thank you for your explanations. Now I see, I should go for the the Per-File Initialization Vector.
From the discussion in this thread, I concluded, that the Per-File Initialization Vector is disabled per default. However, the man-page says it's enabled by default.
Whos right then?

The standard encfs6.xml contains several parameters containing "IV" but non of them is called anything like Per-File Initialization Vector.
Which one controls the usage of Per-File Initialization Vector?

[rfjakob]

Per default, it's enabled in normal mode, and disabled in reverse mode.

In the config file it is called "uniqueIV" if i remember correctly.

[rfjakob]

PS: To verify that uniqueIV is working, you can check that identical plaintext is encrypted to DIFFERENT ciphertext. In the example below uniqueIV is OFF, and files "1" and "2" are encrypted to identical ciphertext:

# "a" -> reverse mount -> "b"
$ echo fobar > a/1
$ echo fobar > a/2
$ sha256sum */*
d5bbe239f5650edd6b81fc9b72f219c9ff0bb71cb3e9666fb264d236bfbafa60  a/1
d5bbe239f5650edd6b81fc9b72f219c9ff0bb71cb3e9666fb264d236bfbafa60  a/2
c8dbacc1ea18b43eba2508ed25a6bcc89b8ae7a9b5bcb418180c1a035e4e0c6b  b/9da6G2NDNtyA1FKD410,W30b
c8dbacc1ea18b43eba2508ed25a6bcc89b8ae7a9b5bcb418180c1a035e4e0c6b  b/MdeUwy8shrVH2sH47HE0Wosm