I have a standard setup created by ecryptfs-setup-private. I've tried to figure out if the (unwrapped) wrapped passphrase [UWP] is the only thing I have to worry about (except the encrypted files themselves).

My understanding is that any key used by eCryptfs, fnek or fekek, is derived from the UWP by salting and hashing it. Does that mean there is some hardcoded salt somewhere in eCryptfs' code or that the UWP is not the only thing to remember if I want to decrypt my data on another computer?


Ok, I think I know the answer.

After I unmounted the private folder and removed the ~/.ecryptfs folder I was able to recover the data using the ecryptfs-recover-private command. It asked only for the mount passphrase and then it was able to decrypt both the data and the filenames.

Now, to be 99,99% sure that there's no catch I also checked eCryptfs' source code.

Ecryptfs-mount-private calls scripts like this one or that one and they all share the following piece of code:

rc = ecryptfs_read_salt_hex_from_rc(salt_hex);
if (rc) {
} else
    from_hex(salt, salt_hex, ECRYPTFS_SALT_SIZE);

-- where ecryptfs_read_salt_hex_from_rc() calls rcryptfs_parse_rc_file() which in turn tries to read the salt from some .ecryptfsrc file.

And if that file doesn't exist or the read attempt is otherwise unsuccessful the default value of ECRYPTFS_DEFAULT_SALT_HEX is used. Btw in the subsequent line of the header file there is the ECRYPTFS_DEFAULT_SALT_FNEK_HEX constant which is used in the ecryptfs_insert_wrapped_passphrase_into_keyring() function as a hardcoded salt value.

Case closed?

EDIT: I found this: https://bugs.launchpad.net/ecryptfs/+bug/376580/comments/3

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.