[feature request] remote encrypted volumes #19

New Issue

sophana · 2023-09-18T16:21:09+02:00

sophana commented

2023-09-18 16:21:09 +02:00

I love droidfs. However, It would be very nice if encrypted files could be stored in a remote (custom or public) server.
protocol would be sftp, webdav, ftp or another?

Ideally it would keep compatibility with gocryptfs, so data could be accessed from android or desktop machines.

From what I've read gocryptfs was modified to change its backend file provider.
I don't know much about android content providers, but it seems that it is possible to access a "remote content provider" like google drive or others. Unfortunately, they are not listed when I create a volume.

If android SAF can't do the job, what about using a specific library to access files remotely (jsch, or any other)?

I love droidfs. However, It would be very nice if encrypted files could be stored in a remote (custom or public) server. protocol would be sftp, webdav, ftp or another? Ideally it would keep compatibility with gocryptfs, so data could be accessed from android or desktop machines. From what I've read gocryptfs was modified to change its backend file provider. I don't know much about android content providers, but it seems that it is possible to access a "remote content provider" like google drive or others. Unfortunately, they are not listed when I create a volume. If android SAF can't do the job, what about using a specific library to access files remotely (jsch, or any other)?

hardcoresushi commented

2023-09-19 17:36:13 +02:00

As explained in the README, this is not possible. This is because gocryptfs and cryfs are programs designed to access the encrypted volume via direct file system calls. The only way to open remote volumes would be to simulate their local presence via FUSE or directly in the kernel. Unfortunately, these methods require root access on Android. As a workaround, you can store the encrypted volume locally and synchronize it on a remote server using an external application such as Nextcloud.

sophana commented

2023-09-19 17:43:09 +02:00

weren't libgocryptfs modified to access volume files through api calls?

I've seen cppcryptfs written in c++. Maybe it is more hackable?
https://github.com/bailey27/cppcryptfs/tree/master/libcppcryptfs/file

weren't libgocryptfs modified to access volume files through api calls? I've seen cppcryptfs written in c++. Maybe it is more hackable? https://github.com/bailey27/cppcryptfs/tree/master/libcppcryptfs/file

hardcoresushi commented

2023-09-19 18:13:50 +02:00

There are actually two sides to an encryption program like gocryptfs. The decrypted/plaintext side has been modified to be accessible via function calls, but the encrypted/ciphertext side has not been touched. As a result, it expects the encrypted volume to be stored on the file system.

It would take at least an equivalent amount of work to also modify the encrypted part so that it works with callbacks. If you have time, you create a PR for this.

There are actually two sides to an encryption program like gocryptfs. The decrypted/plaintext side has been modified to be accessible via function calls, but the encrypted/ciphertext side has not been touched. As a result, it expects the encrypted volume to be stored on the file system. It would take at least an equivalent amount of work to also modify the encrypted part so that it works with callbacks. If you have time, you create a PR for this.

Sign in to join this conversation.