Have something to say?

Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?

Not exactly

"The problem with this is that the encryption key and the salt value are available in the cloud environment, which rather defeats the purpose of encrypting in the first place, namely to ensure that the cloud owners do not under any circumstances have access to your private files."

The information in the .encfs6.xml is encrypted with the password, as are the files themselves. There is no exposure by leaving the .encfs6.xml file in the directory.

Quoting:But in the end the amount of trust one gives to 3rd parties is up to you.

Well said. To me that is the crux of the whole cloud computing thing. I am not willing to trust third parties with my data. I've been in IT and seen security mishandled or done poorly by too many corporate entities and government institutions to trust my data to a third party.

If you don't trust the encryption of the xml data, you shouldn't be trusting encfs' implementation at all, as your files are protected with the same encryption. Removing the xml data improves the security of your data files as much as removing one of the data files - which is to say, not at all.

macemoneta, the file .encfs6.xml is not encrypted, it is in plain text and human readable, the Key is is base 64 format, as is the seed. They exist in this format so that the encfs application can authenticate the password. If they were themselves encrypted, there would be no possibility of authenticating.

Leaving the .encfs6.xml file in the encrypted directory when uploading to the cloud means that any one who has access to your files can use the .encfs6.xml file to extract your password.

removing that file before uploading, and adding a link into the encrypted directory makes it safe.

A "flag file", in this case .encfs6.xml, is a data leakage, whether or not it's encrypted. The facile case is that it's unencrypted. However, if it is encrypted:

In the normal, "not under attack" scenario, the password from the user is used to decrypt the flag file (in this case, .encfs6.xml). A successful decryption of the first N octets means the password was correct; otherwise, a failure is flagged, and the user may try another password.

In an attack scenario, the flag file gives the attacker a known sequence in the first N octets to which a candidate key must decrypt the sequence under attack. This will take some time, but without this precondition, the key search would take much longer.

Quoting:
macemoneta, the file .encfs6.xml is not encrypted, it is in plain text and human readable, the Key is is base 64 format, as is the seed.

Macemoneta is correct, the key data in base64 format is an encrypted one using the password that is supplied when creating/mounting the encfs filesystem. See the backups section here: http://www.arg0.net/encfsintro

Yes, krisum, you and macemonet are correct, it is encrypted, and stored in base 64, I get that wrong. The point is that if the file is available with the data (the encrypted files), then potentially the password can be extracted, and the data compromised. Not having the key available with the data makes extracting the password considerably more difficult, depending on the encryption strength used, and therefore the data is more secure.

Where macemonet is incorrect is in assuming that it is safe to supply the key, encrypted or not, along with the data.

If you are saying that someone could decrypt the file access key stored in the xml file, and thus use it to access the files, then why wouldn't they just perform the (far simpler, due to larger data sample) task of decrypting the files themselves?

Both the files and the key are encrypted with the same algorithm and implementation. If you can decrypt the key you don't need it - you can just decrypt the files. If you can decrypt the files, the presence or absence of the xml file is immaterial.

I haven't seen any method proposed for using the xml encrypted key in a way that creates any risk to the integrity of the encrypted data. The presumption that the process would be easier with a few bytes of additional encrypted data is unfounded, and unsupported.

Quoting:
Both the files and the key are encrypted with the same algorithm and implementation.

No, from what I recall the encryption of files uses the (encrypted) key (and other parameters from the control file) and not just the password directly. So not uploading the control file may be better to avoid dictionary and other offline attacks on the key.

Btw, for those interested in a GUI there is a nice package "cryptkeeper" that sits in the tray and allows creation/mounting of encfs directories.