Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UtahFS: Encrypted File Storage

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: UtahFS: Encrypted File Storage

#31

Post by rcxdude »

jeffbee wrote: post #28
mtgx wrote: post #5

Dropbox and Google could easily encrypt the files locally with your own key prior to uploading them to their servers. But of course they won't do that, because then how else will they mine your data? Also, you probably shouldn't trust them even if they did offer this anyway.

Sure, if you don't want search or sharing or 90% of the other features of Google Drive then encrypting on the client side makes great sense. For people who demand that their computers are useful, it doesn't make any sense.

Sharing can be accomplished like encrypted file-hosting sites do: encoding a decryption key in the anchor of the URL. Search of course is harder, but it's a bit unreasonable that it's not an option at all.

Re: UtahFS: Encrypted File Storage

#32

Post by eric1293 »

I find it difficult to set up a good system for encrypted storage.

1. Cryptomator: it's immature and buggy, especially the 1.5 version. See comments in forum.cryptomator. The files and folders disappear, vaults crash, vaults fail to mount, etc.

Boxcryptor is the paid version and not buggy. But it's not open source.

2. EncFS. Has security issues that haven't been resolved.

3. CryFS. Too slow and immature.

4. Encrypted backup, like rclone or duplicity. These are not sync tools.

5. eCryptfs: Used for Ubuntu home encryption (even then somewhat outdated), not for cloud.

6. AWS KMS: server side encryption; amazon has the keys.

7. Gocryptfs: It's OK. Reasonably fast. Cons: command line only, and for Linux. Uses OpenSSL library which isn't all that secure.

It seems to me gocrytfs is the best among these.

Re: UtahFS: Encrypted File Storage

#34

Post by eric1293 »

Tepix wrote: post #25

One way to achieve encrypted remote file storage is to combine Linux's EncFS² with some other type of remote storage protocol such as CIFS. The basic idea is to mount a CIFS volume from a server you don't trust with your unencrypted files, then you mount that directory again with EncFS to get to the unencrypted files. The main drawbacks are that EncFS will not hide your directory structure and file sizes and also tha…

EncFS 2.0 does not seem to have been released. I don't recommend it due to security problems.

Re: UtahFS: Encrypted File Storage

#36

Post by slaymaker1907 »

libeclipse wrote: post #21
ianopolous wrote: post #17

They should use Peergos [1], which satisfies all their requirements. It's built on top of ipfs, encrypts metadata as well as data, and hides file sizes and directory structure too. A directory is indistinguishable from a small file. We can also use S3 compatible object storage, including allowing direct reads and writes from the browser. Disclaimer: I'm the founder. 1. https://github.com/peergos/peergos

Peergos doesn't hide access patterns as far as I can tell.

ORAM is pretty costly for a feature that many people don’t actually need. Yes it is log(n) for reads and writes, but the bigger downside is that ORAM by design thrashes any cache you happen to be using. I imagine this would be particularly noticeable for filename resolution with deep directories.

Plus, ORAM provides no protection out of the box for timing based attacks.

Re: UtahFS: Encrypted File Storage

#37

Post by Legogris »

eric1293 wrote: post #32

I find it difficult to set up a good system for encrypted storage. 1. Cryptomator: it's immature and buggy, especially the 1.5 version. See comments in forum.cryptomator. The files and folders disappear, vaults crash, vaults fail to mount, etc. Boxcryptor is the paid version and not buggy. But it's not open source. 2. EncFS. Has security issues that haven't been resolved. 3. CryFS. Too slow and immature. 4. Encrypted…

What’s wrong with LUKS / tomb?

Re: UtahFS: Encrypted File Storage

#38

Post by eric1293 »

Legogris wrote: post #37
eric1293 wrote: post #32

I find it difficult to set up a good system for encrypted storage. 1. Cryptomator: it's immature and buggy, especially the 1.5 version. See comments in forum.cryptomator. The files and folders disappear, vaults crash, vaults fail to mount, etc. Boxcryptor is the paid version and not buggy. But it's not open source. 2. EncFS. Has security issues that haven't been resolved. 3. CryFS. Too slow and immature. 4. Encrypted…

What’s wrong with LUKS / tomb?

It's one big container. A small change means the whole file has to be uploaded again. If you are lucky for Dropbox blocks are synced only.

Also it lacks authentication. The snapshots of the XTS mode are prone to certain attacks.

Re: UtahFS: Encrypted File Storage

#39

Post by fbriff »

eric1293 wrote: post #32

I find it difficult to set up a good system for encrypted storage. 1. Cryptomator: it's immature and buggy, especially the 1.5 version. See comments in forum.cryptomator. The files and folders disappear, vaults crash, vaults fail to mount, etc. Boxcryptor is the paid version and not buggy. But it's not open source. 2. EncFS. Has security issues that haven't been resolved. 3. CryFS. Too slow and immature. 4. Encrypted…

I would also add: 8. Securefs [1]

Gocryptfs has a comparison of these projets, here [2].

Focused on Windows only, to my experience, securefs is the one that is working the best as it is not using dokany but winfsp (FUSE for Windows). With all other solutions using dokany, the copy or sync of large number of files is damn slow or hanging.

[1] https://github.com/netheril96/securefs

[2] https://nuetzlich.net/gocryptfs/comparison/

Re: UtahFS: Encrypted File Storage

#40

Post by linsomniac »

Legogris wrote: post #14
diablo1 wrote: post #12

Interesting name for a file system. Reminds me of this: https://en.wikipedia.org/wiki/Utah_Data_Center

Also https://en.wikipedia.org/wiki/Tahoe-LAFS

While reading this I kept thinking "Isn't Utah the name of Zooko's FS?" Took me a minute to remember it was Tahoe.
Post reply on HN