4

This actually happened on Mac OS X, but I believe I can get the answer here rather than on http://apple.stackexchange.com

I have a directory encrypted with encfs. I accidentally deleted .encfs6.xml from there.

Now when I want to mount this directory as encfs one, encfs wants to create new encrypted volume there. Can I somehow force it to open existing one instead of creating new one?

Of course I remember the password.

0

2 Answers 2

5

.encfs6.xml contains the key. If you've lost that file, you won't be able to decrypt your files.

The encryption key is not derived from the password. What is derived from the password is the key used to encrypt the file encryption key which is stored in encfs6.xml. This is a standard method. It's done this way for two reasons:

  • For security: passwords typically have low entropy — it's usually possible to find them by enumerating all likely possibilities (12345678, password, iloveyou, Passw0rd, …). On the other hand, keys are generated randomly; having a non-negligible of chance guessing the right key would take longer than the age of the universe. So an attacker who guesses your password must also get hold of the key file .encfs6.xml. (This is not much of an advantage when the key file isn't stored together with the encrypted data though.)
  • For usability: this way, if you change your password, the software only needs to update .encfs6.xml, it doesn't need to reencrypt all the files.

Restore .encfs6.xml from your backup.

If you don't have a backup, you may be able to recover it using forensic tools that search for deleted files. This is of course not guaranteed to work, and not necessarily easy even if it does work.

1

I had the idea to guess every salt and the number of iterations, but using your original known passphrase, so to recover/rebuild the .encfs6.xml file but without the missing <encodedKeyData>... I tried a test, using the useful-sounding option --anykey, it should:

--anykey
Turn off key validation checking. This allows EncFS to be used with secondary passwords. This could be used to store a separate set of files in an encrypted filesystem. EncFS ignores files which do not decode properly, so files created with separate passwords will only be visible when the filesystem is mounted with their associated password.

.encfs6.xml contains info like this:

<encodedKeySize>44</encodedKeySize>
<encodedKeyData>
t+mDmS6qiUwJcUY2rX2oj6jMlfQ3QIiGPG2BRZspTUZiUOcKBxIq70uVILk=
</encodedKeyData>
<saltLen>20</saltLen>
<saltData>
9pmECBnKHDXpW+3E+Z7WO9xWwls=
</saltData>
<kdfIterations>147015</kdfIterations>
<desiredKDFDuration>500</desiredKDFDuration>

I thought it might be possible to use --anykey even if it did not match the encodedKeyData (changing it to different data) but still read the original files using the original passphrase. As in, you remember/guess all the other data except the encodedKeyData. So I created a new EncFS folder & test files, and tried editing the .encfs6.xml file, changing or deleting the <encodedKeyData>...</encodedKeyData> entry.

It didn't work, with the wrong data it would quietly mount, but no files were decrypted. Deleting the entry failed with this error:

terminate called after throwing an instance of 'boost::archive::iterators::dataflow_exception'
what(): attempt to decode a value not in base64 char set
Aborted

The only use for --anykey appears to "hide" some files using a different password, I'm guessing using the filename encryption, but still needs the original encodedKeyData.

And, changing the <saltData> by one character lets encfs --anykey mount successfully with any passphrase too, but even using the original passphrase NO files are decrypted, and no error is given.

So, you 100% NEED the .encfs6.xml file, it's like a keyfile with an encrypted key (similar to a LUKS header I think).

2
  • so if you loose that file, there is no way to decrypt? what if you back up the file ? not the safest method but ..... Feb 12, 2018 at 20:20
  • @TannerSummers A backup of that file should work. While you're at it, keep a backup of the actual files somewhere safe too, that's even better :)
    – Xen2050
    Feb 21, 2018 at 3:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .