Not exactly
|
| Author | Content |
|---|---|
| macemoneta Nov 28, 2009 10:20 AM EDT |
"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. |
| tracyanne Nov 28, 2009 5:03 PM EDT |
I suspect there is even less exposure, if the .encfs6.xml file is not kept in the directory. But in the end the amount of trust one gives to 3rd parties is up to you. |
| caitlyn Nov 28, 2009 7:12 PM EDT |
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. |
| macemoneta Nov 28, 2009 9:50 PM EDT |
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. |
| tracyanne Nov 29, 2009 1:29 AM EDT |
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. |
| gus3 Nov 29, 2009 2:02 AM EDT |
Argh. So much experience, so little... something. 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. |
| jezuch Nov 29, 2009 7:05 AM EDT |
Quoting: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. Well, "encryption" isn't everything, because you can misuse it horribly, and it's quite difficult to make it right. It only *seems* easy, but Black Hats know better. Having said that, I don't know the details of the solution at hand. Thus, I won't use it ;) |
| krisum Nov 29, 2009 9:19 AM EDT |
@tracyanne
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 |
| tracyanne Nov 29, 2009 5:17 PM EDT |
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. |
| macemoneta Nov 30, 2009 8:35 AM EDT |
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. |
| krisum Nov 30, 2009 2:12 PM EDT |
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. |
| macemoneta Nov 30, 2009 2:36 PM EDT |
The encryption keys are different, but the algorithm and implementation are the same for both the key and data. If you can algorithmically decode one, you can decode the other. |
| tracyanne Nov 30, 2009 4:29 PM EDT |
If you have the Key the seed and the Data, you are almost there, it's that simple. |
| krisum Dec 01, 2009 4:58 AM EDT |
Quoting: but the algorithm and implementation are the same for both the key and data.Probably you have not much idea of cryptanalysis. The major strength of encryption lies not in its algorithm or implementation but in its key. The best algorithm is useless with a weak key. Quoting: If you can algorithmically decode one, you can decode the other.No, it depends on the strength of the two keys. Assuming that the generated key is much stronger than the provided password (which will be always the case), there is no comparison of the two. |
| macemoneta Dec 01, 2009 5:24 AM EDT |
"Probably you have not much idea of cryptanalysis." That must be it. :) |
| gus3 Dec 01, 2009 1:00 PM EDT |
Quoting:The best algorithm is useless with a weak key.And the best key does no good if the algorithm is cryptographically poor. Just ask Jon Lech Johansen. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!