Cryptomator – Encrypt files on your cloud storage(cryptomator.org)
cryptomator.org
Cryptomator – Encrypt files on your cloud storage
https://cryptomator.org/
55 comments
From the gocryptfs homepage
> 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.
> 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.
If you don’t need to access via phones, gocryptfs is a good option.
It might be possible via terminal to mount in Android, but I am not sure about iOS.
Cryptomator does a lot more on user friendliness, looking at their community page.
It might be possible via terminal to mount in Android, but I am not sure about iOS.
Cryptomator does a lot more on user friendliness, looking at their community page.
Cf. https://github.com/hardcore-sushi/DroidFS on Android.
I just tried this and it's much better than the Android app for Cryptomator, especially for browsing images.
The DroidFS dev is responsive as well.
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:
https://github.com/cryfs/cryfs/issues/192
https://github.com/cryfs/cryfs/issues/192
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.
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.
Details are described in audit that was performed for gocryptfs: https://defuse.ca/audits/gocryptfs.htm
> 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.
> 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.
[1]: https://github.com/cryptomator/siv-mode
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.
[1]: https://github.com/cryptomator/siv-mode
https://docs.cryptomator.org/en/latest/security/architecture... says AES in CTR mode unless I'm missing something.
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).
Seems like it has no Android support.
Are there any FUSE file systems on Android? Not a rhetorical question.
But how is it a relevant question? Cryptomator and gocryptfs have Android support.
gocryptfs doesn't have official support for Android. Not sure about Cryptomator.
How does it compare to gocryptfs?
The design of both are very similar. There are only minor feature differences. The following list is not exhaustive:
`securefs` has but `gocryptfs` hasn't:
* Native Windows support.
* Extended attribute on Mac.
* Random padding.
`gocryptfs` has but `securefs` hasn't:
* Reverse mount (mount a plain dir as an encrypted dir).
`securefs` has but `gocryptfs` hasn't:
* Native Windows support.
* Extended attribute on Mac.
* Random padding.
`gocryptfs` has but `securefs` hasn't:
* Reverse mount (mount a plain dir as an encrypted dir).
Thanks for your quick reply - interesting, will take a look!
BTW the reverse mount turns out to be a very useful feature that solves many problems with large file systems!
BTW the reverse mount turns out to be a very useful feature that solves many problems with large file systems!
Alternatively, rclone also lets you encrypt your data to any cloud providers they support. Great tool!
OK, but please compare
https://rclone.org/crypt/
vs
https://nuetzlich.net/gocryptfs/quickstart/
https://rclone.org/crypt/
vs
https://nuetzlich.net/gocryptfs/quickstart/
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.
[deleted]
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.
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.
This is not a good thing to do for two reasons.
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.
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.
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!
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.
Single binary alternative, open source: https://github.com/FiloSottile/age
From former head of Go security team at Google.
From former head of Go security team at Google.
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 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.
Yeah, it's unauthenticated in asymmetric mode https://github.com/FiloSottile/age/issues/59
This is incorrect, they use https://en.wikipedia.org/wiki/ChaCha20-Poly1305
What’s the connection of this with the post?
This is a utility to encrypt a file from command line. It’s like saying ZIP is an alternative, because it has encryption.
This is a utility to encrypt a file from command line. It’s like saying ZIP is an alternative, because it has encryption.
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.
Well... 99% clients wont install thirdparty software to decrypt shared files.
Well... 99% clients wont install thirdparty software to decrypt shared files.
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.
B2 is
Are you sure? I'm scared for traffic costs on data that sometimes I would need rapid access.
B2 1TB/storage/month ~ $5 250GiB/traffic/month ~$2,5
On OneDrive 1TB/storage/month ~ $7 (home user, there's cheaper enterprise plans) 250GiB/traffic/month $0
B2 1TB/storage/month ~ $5 250GiB/traffic/month ~$2,5
On OneDrive 1TB/storage/month ~ $7 (home user, there's cheaper enterprise plans) 250GiB/traffic/month $0
1TB OneDrive in familly plan is 2 USD/month + office 365.
BX11 is
Saw a similar tool called Kopia [1] posted on HN last year. Anybody have experience with it?
[1]: https://news.ycombinator.com/item?id=27471945
[1]: https://news.ycombinator.com/item?id=27471945
Kopia is more for backup (snapshot with deduplication) instead of encrypt files on-the-fly for cloud storage. Very different use case.
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!
If only it worked on Linux, I get a SIGSEGV on two different distros for 1.6.10.
Back to VeraCrypt, I guess.
That's odd, I've been using cryptomator on arch for like 2 years now with no issue.
is there much of a reason to use this over something like rclone with a crypt backend configured?
What library/driver is used to provide a virtual disk?
Another comment had a link to their GitHub, which after a bit of looking mentions fuse : https://github.com/cryptomator/cryptomator/blob/develop/src/...
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.