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

Directory structure is leaked, not end to end encrypted #94

Closed
KopfKrieg opened this issue Jan 16, 2019 · 5 comments

Comments

Projects
None yet
4 participants
@KopfKrieg
Copy link

commented Jan 16, 2019

The promise on the official website for the end to end encryption reads as follows:

Security properties: Never leak directory structure, filenames or file content to the server.

But currently, this is a lie. The Nextcloud Desktop Client currently doesn't automatically encrypt subfolders of encrypted folders, and even if I create subfolders using the Android App (which automatically encrypts subfolders of encrypted folders), the whole (!) directory structure is visible on the server. I can see every single folder in my so-called "end to end encrypted" folder.

This is a huge architectural flaw, leading to false promises and users who think their data is save even though it's not.

I'd like to open the discussion on how to approach the issue. End to end encryption is something I (personally) really want and need because some of my data is very sensitive. I currently see two options:

  1. Either fix the current implementation, which probably breaks the current approach and might not be backwards compatible
  2. Or integrate a different, already existing solution (like encfs, cryptomator or whatever) to address the issue

Another issue is the different code-base for desktop and mobile clients, which leads to the previously mentioned differences in the Android and Desktop app.

@jospoortvliet

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

We're sorry, this is an implementation issue, but we're aware, and we will fix it. It is not at all an architecture issue.

As far as there's an architecture issue, it'll be addressed. Next week the client engineers have a E2E hackweek in Stuttgart. Anyone is welcome, of course, if you want to help hack on it.

@KopfKrieg

This comment has been minimized.

Copy link
Author

commented Jan 16, 2019

Good to hear it's being worked on.

It is not at all an architecture issue.

It's currently possible to have an unencrypted folder within an encrypted folder, and that data is leaked. IMHO that's an architectural issue (end to end encrypted folders shouldn't be able to leak any data in design terms, or not?).

@jospoortvliet

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

It's currently possible to have an unencrypted folder within an encrypted folder, and that data is leaked. IMHO that's an architectural issue (end to end encrypted folders shouldn't be able to leak any data in design terms, or not?).

That is possible because due to a bug subfolders aren't being encrypted. It was never meant to be that way, it wasn't designed that way of course - so isn't a problem in the design or architecture but the execution, that's what I was trying to say. Doesn't matter anyway, if our arch/RFC isn't clear enough on it, we have to fix that too of course. Next week, I have high expectations 👍

@joergister

This comment has been minimized.

Copy link

commented Jan 26, 2019

Any news?
Which of the current issues were you able to address at the hackfest?
Is there a Blogpost about the outcome somewhere?

@tobiasKaminsky

This comment has been minimized.

Copy link
Member

commented Jan 28, 2019

There will be soon a version 2 of RFC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.