This tool attempts to decrypt EncFS volumes that were first created between 2006 and 2008 using vulnerable Debian versions of OpenSSL. These versions produced predictable random numbers from a very small range (~32K possible start values). Therefore, volume keys generated with vulnerable versions can be recovered without knowledge of the password.

MAKE A BACKUP COPY OF THE VOLUME YOU WANT TO DECRYPT BEFORE USING THIS TOOL. Read below for why it WILL SHRED YOUR DATA IF YOU DON'T

How does it work?

EncFS, like other encryption software, does not encrypt the files directly with the password, but generates a random volume key to encrypt all files, and then encrypts the volume key with the password and stores it. This allows the password to be changed without having to re-encrypt the data itself, only the stored volume key has to be re-encrypted.

This software does not recover the password itself (this is infeasible). Instead, it recovers predictable volume keys generated by vulnerable OpenSSL versions. As such, it can be used on any volume that has initially been created using such a vulnerable version, even if the password has been changed since.

You really want to create a backup first

MAKE A BACKUP COPY OF THE VOLUME YOU WANT TO DECRYPT BEFORE USING THIS TOOL. HERE'S WHY: Things that can go wrong, and, if your data is valuable, will go wrong:

• If the volume was encrypted by a non-vulnerable key, but this tool incorrectly believes that it has recovered the key, and overwrites the encfs config file, then it is impossible to decrypt the volume, even using the original password.
• The tool attempts to make a backup of the original config file before overwriting it, but do not rely on this working correctly in every case.
• Finally, if the volume is mounted using an incorrect key and subsequently modified, it may be possible that the data itself is corrupted (although I cannot exactly imagine how). So then you have a backup of the original config file, but corrupted data that you will not be able to decrypt anymore.

CREATE A FULL BACKUP OF THE VOLUME YOU ARE TRYING TO RECOVER I MEAN IT

What if it doesn't work?

The tool just exhaustively generates all keys that could have been generated using vulnerable versions of Debian's OpenSSL (between 2006 and 2008). That's only very few parameter values (one of usually ~32k process IDs, the architecture that they key generator was executed on, the number of key bytes that the cipher needs (AES/Blowfish/...) and some other minor variations depending on the EncFS version). For each of these keys, decryption of the volume is attempted and validated using some heuristics.

The tool generates all keys using the exact same parameters from your encrypted volume, so it should work even if you selected unusual parameters during creation. Process IDs up to 32767 are tested, which is the maximum value for almost all Linux installations (if you changed it, you would definitely know it).

So what if the tool still cannot find a key? Possible reasons:

• Maybe the volume key was not originally created on a vulnerable Debian. Note: only the creation matters. If you created the volume with a vulnerable version, you can recover the key even if the password was changed later with a "good" version. On the other hand, if the volume was created earlier using a "good" version (pre-2006) and you later changed the password using a vulnerable version, you cannot recover the key. This is because we do not attack the password, but the volume key directly, which is never changed after creation.
• An OpenSSL version with a predictable, but different, PRNG was used. The simulation of the broken PRNG currently is that of that variant of OpenSSL 0.9.8c that Debian shipped. It can simulate both the output of i386 and amd64 builds. (The generators have been verified to generate the same random numbers for these two platforms. Other platforms with the same sizeof(long int) should generate the same sequences.) As far as I know, all affected OpenSSL versions used the same algorithm.
• An EncFS version with a different volume key generation algorithm was used. EncFS did not directly use the random bytes but applied some rounds of SHA1 on them before. At some point in 2008 the algorithm was changed. It probably also only depended on OpenSSL's random bytes, so these keys should be predictable as well (they're just different from the older ones). That change is however not implemented yet, i.e. this tool only implements the SHA1 variant. Furthermore, some versions consumed random bytes prior to key generation, which means different bytes were used for volume key generation. The current version of the tool uses the generation algorithm from EncFS 1.2.5 (from 2005), which was as far as I know not changed until early 2008.

If you think you used a vulnerable OpenSSL for key generation but this tool cannot recover the key, and you want to open an issue, include the following information:

• output of encfsctl info /path/to/volume, in particular the EncFS version that the volume was created with
• architecture information (32/64 bit library/i386/amd64 or a totally different one like ARM?)
• the version of the SSL library used at that time, if you still know it

Notes about the password

EncFS checks passwords by (roughly) testing if a checksum based on the decrypted volume key matches. In the versions I examined, that was a 4-byte checksum. A match of the checksum will cause EncFS to mount the volume, but if the key was not actually decrypted correctly, the volume will appear empty.

For that reason, exhaustive enumeration of passwords will likely come up with some false positives after a few hours/days of trying.

Of course, if your EncFS volume was not created with predictable volume keys, but you assume that your password at that time was particularly weak (pet/family names, 12345, etc.) you can still try to guess the password by using standard password enumeration tools. A future version of this tool will include a mode that causes it to read passwords from standard input and check each of them. The same heuristics as for volume key enumeration will be used, so false positives (correct checksum but incorrect key) can be eliminated. (Also, doing this in a single process will be slightly faster than spawning a new encfs process for each password to test.)