D8449: Have a default backend (if one available)

Crypto Dude noreply at phabricator.kde.org
Tue Oct 24 15:06:20 UTC 2017


cryptodude added a comment.


  In https://phabricator.kde.org/D8449#159337, @ngraham wrote:
  
  > I don't think choosing a random backend makes sense without at least some information provided to the user. How about adding a text view below the combobox showing a quick human-friendly summary of the purported advantage of each backend? like this:
  
  
  A distro may have a preference, and only install one. This is the main reason where the above approach makes a difference. We pick the one that is available. With debian (and all derivatives) already having flagged encfs, I think that this will have a big impact for a very small price.
  
  But you make a good point. We should not choose randomly.
  
  As I do know a bit about crypto, I can list the differences. Unfortunately the difference to end users is probably something they won't care about because the differences between the two systems are not really seen in the usecases that Vault currently provides. Though I don't know about future plans.
  
  Differences are;
  
  - CryFS has a storage that looks more like a git database than a dir.  EncFS has a one-to-one connection between user-file and encrypted file.
  
  We do allow the user to set the "encrypted data location" dir, as such they may choose a shared drive (BAD!), but that's not the default and as such this difference between systems doesn't really expose much. If it did, I'd suggest you avoid encFS as it leaks a lot of metadata that CryFS protects.
  
  - EncFS just one-to-one encrypts a file, and its filename. This means that filesystem features like chmod/chown of the main storage are transparently visible on the mounted drive. Filename length is similarly limited. Symlinks in your mount are symlinks on the target device.
  
  As such you will get a nasty surprise if you store your data dir on something like vfat (usb pen) where most of these examples are not available.
  
  - EncFS has a "volume-key-file", which is like your gpg key, a file on the filesystem. It additionally requires a password.
  
  This might be useful to do a 2factor authentication, but Vault would need quite a lot of extra work to support that. As such this feature is unused.
  
  When it comes to security, both use external libraries (openssl et all) to do the actual hard lifting, which are peer reviewed and everything.
  
  more; https://www.cryfs.org/comparison
  
  I'm not sure what to write in a short summary, other than that encfs should NOT be used if there is even a small chance of a 3rd party being able to see or add to the encrypted files (for instance on a usb-pen).
  
  Ok, what about this;
  we turn off the ability of the user to select a location to store his encrypted data if they choose encFS, because it would be insecure.
  
  as such we pre-select cryFS (should it be available), so the user can have all the features they want.
  
  We also provide some user-visible information, like you suggested, on actual differences for the user. For instance;
  
  CryFS: most secure and user friendly.
   EncFS: Do not use this if you ever expect your encrypted files to be copied where others can see them. For instance for backup or on a usb-key or cloud-service.
  
  ps. I'd like to see more backends, so this is not a fight between just CryFS and EncFS.

REPOSITORY
  R845 Plasma Vault

REVISION DETAIL
  https://phabricator.kde.org/D8449

To: cryptodude, ivan, #plasma
Cc: ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20171024/8fb1e9a3/attachment-0001.html>


More information about the Plasma-devel mailing list