Hacker News Reader

Comment by POPOSYS | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

Reply on news.ycombinator.com