Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How Secure am i if keyfile is stored outside of cloud?? #122

Closed
dakkusingh opened this issue Oct 29, 2015 · 7 comments
Closed

How Secure am i if keyfile is stored outside of cloud?? #122

dakkusingh opened this issue Oct 29, 2015 · 7 comments
Labels

Comments

@dakkusingh
Copy link

I read this security report and was somewhat concerned..
https://defuse.ca/audits/encfs.htm

However, if my key is never uploaded to the cloud, is it still a concern that someone could try to brute force? Is there any way possible for anyone to decrypt the container if key is never shared?

@rfjakob
Copy link
Collaborator

rfjakob commented Oct 31, 2015

When the keyfile is stored somewhere else, brute-forcing is out of the question.

But, the key finding in the report is

2.2. Stream Cipher Used to Encrypt Last File Block

This means that you leak some data about the modifications that take place in the last block (1kB) of your files. To get that data, the attacker must have a copy of the file before and after the modification. It does not matter where the key is stored, this always applies.

Depending on the data you store, this can be no concern at all (for example, photos and videos that do not change) or a big problem (letters that you are editing).

@dakkusingh
Copy link
Author

Thank you for the response.

2.2. Stream Cipher Used to Encrypt Last File Block

I am right in understanding that if the key is never stored with the data, the above is also not a concern? So, regardless of the versioned storage, if the key is never stored with the data we are perfectly safe?

@rfjakob
Copy link
Collaborator

rfjakob commented Nov 1, 2015

No, this always applies. The attack works without knowing anything about the key.

I have edited my answer above to make that clear.

What operating system are you on?

@dakkusingh
Copy link
Author

Thank you for clarifying this. I wasnt sure if not having the key made you immune to this versioning issue.

Is there any way to protect against this? Also, is there any documentation to test this exploit?

I am on OSX 10.11.1 and backup to a mixture of Dropbox and OneDrive.
Dropbox has versioning but as of yet OneDrive does not support versioning!

@rfjakob
Copy link
Collaborator

rfjakob commented Nov 1, 2015

Fixing this issue requires an incompatible format change and there is currently no way to mitigate it. The whole issue is documented in this ticket: #9

If you were on Linux I would recommend you to try out gocryptfs (developed by myself). Gocryptfs fixes this issue and a few more and has gone through quite some testing on Linux. However, on Mac OS X, you'd probably would be the first one to try it out.

@Harry5001
Copy link

The problem should become relevant when saving a file multiple times / when someone has the file in multiple versions. I have a question to this: Does the problem only occur, when there are multiple encoded files of the exactly identic source-file, or is it also relevant if there are multiple files of the same source file that has been modified in the second version before encoding? Another question: In case of one file could be decoded because of multiple versions of that file, are there all other files also compromised that had been encoded with the same key? Or are these still secure as long as no second encoded version is available?

@benrubson
Copy link
Contributor

Question is finally answered here : #439 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants