4 ms·

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

by ctur 4y ago

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.

POPOSYS 4y ago
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!
aborsy 4y ago
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.
jeroenhd 4y ago
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.

by ctur 4y ago

POPOSYS 4y ago

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!

aborsy 4y ago

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.

jeroenhd 4y ago

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.