Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 20 21:22
    overheadhunter closed #849
  • Sep 20 08:51
    overheadhunter edited #769
  • Sep 20 08:50
    overheadhunter edited #808
  • Sep 20 06:34
    stale[bot] unlabeled #830
  • Sep 20 06:20
    stale[bot] labeled #830
  • Sep 19 19:07
    no-response[bot] unlabeled #849
  • Sep 19 16:01
    stale[bot] closed #879
  • Sep 19 10:30
    overheadhunter closed #346
  • Sep 19 09:57
    overheadhunter demilestoned #129
  • Sep 19 09:57
    overheadhunter milestoned #129
  • Sep 19 09:57
    overheadhunter labeled #129
  • Sep 19 09:56
    overheadhunter labeled #396
  • Sep 19 09:56
    overheadhunter labeled #849
  • Sep 19 09:55
    overheadhunter labeled #881
  • Sep 19 07:02
    overheadhunter closed #251
  • Sep 19 07:02
    overheadhunter demilestoned #251
  • Sep 18 22:38
    overheadhunter labeled #356
  • Sep 18 22:38
    overheadhunter demilestoned #356
  • Sep 18 22:36
    overheadhunter closed #625
  • Sep 18 22:35
    overheadhunter milestoned #625
Tillerino
@Tillerino
I'm a bit confused about the *.cryptomator file extension since totalvoidness/cryptomator@efac770
Or rather about the FileChooser. On windows, FileChooser only allows choosing files, not directories.
The plan is still to have the extension only for folders, right?
Sebastian Stenzel
@overheadhunter
As windows (afaik as well as tux) doesn't support bundles, the solution is to create a folder "foo.cryptomator" with a file inside "foo.cryptomator/foo.cryptomator". This way we have just one file extension supported for bundles AND files. When opening these bundles or files with the Cryptomator application, we must differentiate between files and directories. If the given path is a file, we move one level up to its parent:
if (path != null && Files.isDirectory(path)) {
    vaultPath = path;
} else if (Files.isRegularFile(path) && path.getParent().getFileName().toString().endsWith(Vault.VAULT_FILE_EXTENSION)) {
    vaultPath = path.getParent();
}
Sebastian Stenzel
@overheadhunter
Btw by changing the workflow this way, it is no longer possible for a user to choose an existing (unencrypted) folder. This should avoid a lot of problems, e.g. if users try to encrypt their whole dropbox directory. The “create/save” and “reopen” methaphor is broadly used and should avoid these kind of misconceptions
Tillerino
@Tillerino
Yes. It's confusing when you know the old way, but now we can also associate the .cryptomator extension with cryptomator on windows.
I guess we can hide the file on osx.
Sebastian Stenzel
@overheadhunter

I guess we can hide the file on osx.

The average user doesn’t look into a bundle, so he will not find it anyway. And even if he does and tries to open it, everything works as expected

Tillerino
@Tillerino
Oh, you're right ^^
Tillerino
@Tillerino
Oh by the way, I looked around a bit and there's a license plugin for maven, which has some handy goals: http://mojo.codehaus.org/license-maven-plugin/
Sebastian Stenzel
@overheadhunter
Nice
Tillerino
@Tillerino
It can also make and update headers for all source files, which is pretty neat.
Sebastian Stenzel
@overheadhunter
This is the most important thing right now. Aggregating 3rd party licenses is great too, but afaik we’re pretty up-to-date with that.
Sebastian Stenzel
@overheadhunter

Ok everyone: How should we proceed with the usernames? It appears to me, that they’re quite useless. I don’t aim to build an enterprise application and in a multi-user scenario there wouldn’t be any effective access control mechanisms.

Once a user is added to cryptomator, he can’t be removed any more without the necessity of a full re-encryption with a new masterkey. Creating a new masterkey would again force all other users to re-create the personal KEK.

Imo multiple usernames don’t add a benefit: When you want to share a vault, just choose a shared passphrase. This way the user is really aware of the fact, that he’s sharing a secret and chooses a proper means (like encrypted email). If there were multiple usernames, people might be less cautious when it comes to sharing a vault.

Additionally multiple usernames add unnecessary complexity to Cryptomator: We need to check, if the username can be used as a filename, we need additional UI controls and might have to deal with users, who expect the username to be encrypted.

I would vote for rejecting issue #21

Tobias Hagemann
@tobihagemann
I've discussed this with @totalvoidness and my opinion is also that we don't need usernames. That users can't be removed without a full re-encryption is probably the decisive argument. And of course that it adds imo unnecessary complexity. From a UI/UX perspective, it would be extremely smart to only have an "enter password" text field, which would make the application simple and accessible.
Tillerino
@Tillerino
That would have the additional bonus that the (new) .cryptomator files could be used to store the keys.
Sebastian Stenzel
@overheadhunter
Interesting idea. Today its just an empty shortcut file without any use.
But that might be risky. The .cryptomator file has the same name as its parent folder. If the user renames the parent folder (which is a legitimate action), he might forget about the equally named file. (especially if he’s a Mac user). And then we can not deterministically derive the correct path to the masterkeys file
Tillerino
@Tillerino
Then how about using a fixed name for the file? Maybe masterkey.cryptomator or something.
encryption.masterkey
Sebastian Stenzel
@overheadhunter
That would be technically feasible. But how about the user experience for win and tux users? Would one expect to open a masterkey.cryptomator file inside a example.cryptomator folder, if one saved a vault as “example” before?
As far as I can tell we have two options:
  • Give the masterkey a fixed name (e.g. masterkey.json) and let the .cryptomator file remain untouched
  • Move the masterkey contents to the .cryptomator file and make the filename base fixed, too
Sebastian Stenzel
@overheadhunter

The more I think about it, the more I like the idea of a fixed “masterkey.cryptomator” (which is in fact a json file).

From a users point of view the analogy of opening a “masterkey” to unlock a vault should (hopefully :smile:) work

Zach H
@ZeldaZach
Hellooo
Sebastian Stenzel
@overheadhunter
Hellooo back ;) Sorry different time zone, was asleep :D
Zach H
@ZeldaZach
Figures lol
abyssis
@abyssis
Hello, from a perspective of someone who barely understands the complexity of "these" things (code wise). How secure this is, really?
alveretzu
@alveretzu
Java?
Hello
Sebastian Stenzel
@overheadhunter
@abyssis depends on your password. Difficult to answer your question without explaining all impl details. Did you read the security section on the website? Maybe you find something specific to ask about in there
@alveretzu I don't get your question, maybe some message got lost
abyssis
@abyssis
@totalvoidness I was mainly curious how secure this is, because if I'm understanding this right, it's basically built in Java, isn't it?
alveretzu
@alveretzu
Espanol
Sebastian Stenzel
@overheadhunter
Still hard to answer. As long as your computer itself isn't compromised it is pretty secure, if you don't use weak passwords. Take a look at the scrypt whitepaper if you're interested in bruteforce times
alveretzu
@alveretzu
what did you say?
abyssis
@abyssis
@totalvoidness Gotcha.
abyssis
@abyssis
Would this work with Seafile?
Tobias Hagemann
@tobihagemann
If Seafile syncs with your local filesystem, then yes!
abyssis
@abyssis
How does this compare to encfs btw?
Sebastian Stenzel
@overheadhunter
Cryptomator avoids some flaws reported in the defuse.ca audit. But that doesn't mean, there aren't other weaknesses, that aren't discovered yet. We don't know what we don't know
abyssis
@abyssis
Yo
do you ever plan on getting a fundraiser up, to get a similar audit done?
Sebastian Stenzel
@overheadhunter
I do want to get an audit, but currently relying on paypal only.
Beshoy Girgis
@egyptianbman
Hello, awesome product!

By downloading Cryptomator, you agree to only use it for testing only with recoverable data. Cryptomator contributors will not be liable for any loss or damage to your data.

How long / when do you think Cryptomator will be ready for non-testing usage?

I noticed the YouTube video had a different setup inside the encrypted directory than what is currently in place.