I recommend gocryptfs - very good performance, easy to automate, one binary, cross plattform, no fiddling with fuse libraries. It works like expected.
Cryptomator is a strange example of how GUI-centric developers seem to be unaware of how important it is to make software usable on the command line.
Also it is a good example of how using Java produces unexpected limitations and complications.
I lost two days fiddling around with several simple use cases without good results - what an experience switching to gocryptfs and getting everything I need up in a few minutes because it just falls out naturally.
It is an interesting lesson about software usability to compare cryptomator vs gocryptfs.
> Linux is fully supported. Beta-quality MacOS support is available, which means things usually work fine, but you may hit the odd issue (please file a ticket if you do!).
> Third-party implementations exist for for
> Windows: cppcryptfs
> Android: DroidFS
So gocryptfs has only beta support of Mac and no first party support for Windows/Android, and no support of iOS.
On the other hand, Cryptomator has first party support for all these platforms.
Based on the above, I don’t think that gocryptfs is really in the same space as Cryptomator which provides easy to use encrypted folders across all the major platforms that most people use.
gocryptfs security model is not very good - attacker who has access to ciphertexts can do way more than casual user could expect. If you are interested in such things, take a look at CryFS paper: https://eprint.iacr.org/2017/773.pdf.
True, they can see files sizes and you don't get integrity. But for less than top-secret stuff I'd take that tradeoff over CryFS performance issues with large files:
Gocryptfs, Cryptomator and Rclone use authenticated encryption per file (with AES-GCM, AES-CTR-HMAC, etc).
What do you mean there is no integrity? Tampering with ciphertext is detected, because the ciphertext is authenticated.
File sizes and the directory structure are of course known. You can do deduplication like Borg, Restic, CryFS, but you get a performance hit that can be noticeable with sync.
> Against a less-powerful active adversary who can modify the ciphertexts but has no access to the mounted filesystem, gocryptfs keeps file contents secret and provides imperfect integrity protection. In at least one case, imperfections in the integrity protections lead to a break of confidentiality. It is possible that the integrity imperfections lead to further confidentiality breaks depending on which applications are using the filesystem.
> Cryptomator's technology meets the latest standards and encrypts both files and filenames with AES and 256 bit key length.
I know you're advertising to slightly less technical users, but please provide some documentation explaining your choices! AES alone doesn't say anything about the mode of operation, which makes or breaks the scheme.
From a little sleuthing, it seems likely that they're using GCM-SIV[1], which is a good choice.
Yeah, looks like you're right. SIV is only used to encrypt the "directory hierarchy," whatever that means in this context (why use two different modes?).
If it is not against the rules, I want to promote my project (https://github.com/netheril96/securefs) here. It is essentially the same functionality, but with authenticated encryption, better password hashing and optionally file size obfuscation (but no fancy UI).
Just because rclone is more completely documented doesn't mean it's harder to use. rclone has a wizard that quickly guides you through the steps, has secure defaults (e.g., generates secure password), and readily expands to other remote types once you've done one.
Not to go full neckbeard on this one, but in addition to FUSE-based options, there is at least one approach that achieves as good (or better) results using more trusted and common primitives in Linux:
Just use cryptsetup on loopback mounted LUKS-structured files, and put the encrypted file in Dropbox or wherever. No filesystem-level weirdness, no random software with unknown/untested pedigree. Add a cronjob that unmounts the filesystem every N minutes and you have a pretty decent sometimes-on place to store just about anything. Double bonus, put a git repository and checkout in the filesystem and you get history of whatever you're stashing in there.
Disk encryption is with XTS mode, also not authenticated. If the remote is not trusted, a number of attacks are possible.
Small changes in the LUKS container can trigger uploading the entire container. It seems, since Dropbox syncs deltas, it can get away with that by uploading changed blocks. That’s not the case with most cloud providers.
That was actually the motivation for per file encryption for cloud storage.
Mounted filesystems are easy to corrupt and not necessarily protected against server side attacks. Also, not every sync provider implements good block level sync, so you may be wasting a lot of bandwidth this way.
I'd much rather go for classics like eCryptFs and EncFs. EncFs especially seems like a good match here, with its cross platform support. Gocryptfs also exists as a replacement, but portability doesn't seem to be as good.
Either way, they have the same advantage (mounting a file system transparently with access to file based sync) without the disadvantage of needing to download the entire LUKS container.
Optimizing for cloud sync is quite difficult. If we could trust something like AES ECB (we can't, don't use it) we could efficiently synchronise only changes to files like we can with unencrypted files, but alas. Partial modification with the same key and the same IV often go against the assumptions made by encryption modes and can easily introduce vulnerabilities. You probably also need to at least re-encrypt the rest of the file if you change just a single bit in the middle.
If understanding your instructions correctly this will trigger upload of the whole encrypted file with every change on the mounted LUKS device.
Some rsync-like binary diff could work with mounted big files syncing chunks across networks, but I am not sure if that works well when more than one mount of the remote file exists. Not sure if dropbox is a good tool for that.
Please update, if I am wrong - I am interested in mounting encrypted remote files from more than one devices!
Longtime happy Cryptomator user here. Use rclone, veracrypt, etc for stuff, but Cryptomator the perfect balance between security, ease of use, and reliability.
Cryptomator provides entire encrypted remote drives. Age is a simple command line utility that is normally used to encrypt single files. Different sorts of things.
Age in asymmetrical mode would be particularly bad for remote storage as it doesn't authenticate the file in this mode. The people running the server would be able to overwrite the files with whatever they wanted if they could get access to or figure out the public key used.
Age also (iirc) doesn't provide authenticated encryption which is... a really weird decision to make and makes it unsuitable for anything in which you don't have authentication by another mechanism.
It is authenticated in symmetrical mode based on knowledge of the shared password. But still not something that should be recommended to anyone who might not know the issues.
I’ve been using Cryptomator for a few months now. Very happy with it. Closest to “main stream” file encryption tool that I’ve used. Confident anyone in my family could use it without much instruction.
Problem with cloud encryption is, when you need share files. For example I use OneDrive for send photographs/videos for my clients. But with encryption, I cannot send them anything.
If you're willing to use SaaS services (as you're mentioned OneDrive already), there are proper E2EE providers where you can work together and share files. Although I am not sure real time collaboration (such as Google Docs or Office online) is feasible with end-to-end encryption yet.
OneDrive is cheapest 1TB cloud storage I can get. I don't care about realtime colaboration, ony sharing files here and there, but having them encrypted on cloud.
The thing that makes this really good vs. the geek options is that this works on my mobile device as well… lovely app. Used for a few weeks. Excellent!
Cryptomator is a strange example of how GUI-centric developers seem to be unaware of how important it is to make software usable on the command line.
Also it is a good example of how using Java produces unexpected limitations and complications.
I lost two days fiddling around with several simple use cases without good results - what an experience switching to gocryptfs and getting everything I need up in a few minutes because it just falls out naturally.
It is an interesting lesson about software usability to compare cryptomator vs gocryptfs.