Feature request: encfs --reverse alike functional

Hello, I'm using rclone to backup files to cloud with encryption, it's helpful, but some cloud provider have very limited API support(limit call number/ rate but allow unlimited web/vendor app access), I'd like to know if rclone can implement

encfs --reverse

alike functional, so user can create a 'encrypted view' of original files, then upload to cloud through web/vendor app ?

from encfs page

Reverse mode
encfs --reverse provides an encrypted view of an unencrypted folder. This enables encrypted remote backups using standard tools like rsync.

for example I want to backup a 500GB file to cloud with encryption, without this function, I have to mount a local dir as encrypt remote, then copy local file to encrypted remote, then copy the encrypted files to cloud through web /vendor app,
but with this function, I can directly copy the encrypted view file to cloud through web/vendor app, thus save time/cloud API call comsuption.

Hi comicfans,

I guess you can do it by cleverly combining:

Hi Ole:

Thank you for your reply, I've read the rclone crypt docs, I think it provides similar function which I need, but I don't understand how driver-client-id/driver-scope/mount can combine together to get my intention, could you please provide some detail information ?

I imagine you could create your own client ID and get it registered as a web/vendor app with unlimited access and then use drive-scope to select the private data of your client ID.

unfortunately, some cloud providers limit API access no matter which web/vendor app, or even don't allow API access. If your suggestion depends on rclone crypt on transfer (instead of creating a encrypted view mount without transfer) , I think it still can't handle my condition. you may ask why I want to use rclone with a cloud provider without API access, because I can use it as cold backup, not a realtime encrypted storage.

OK, sorry for the confusion, I think I got your point. Let me try to confirm in other words:

You would like rclone to have a backend giving an encrypted view of the (unencrypted) files in the underlying remote. You would then use another tool to upload the encrypted data from rclone mount or rclone serve.

Conceptual example:

type = alias
remote = /folder/with/plain/files/

type = cryptreverse
remote = plain:
> ls /folder/with/plain/files/
> rclone ls plain:
> rclone ls cryptreverse:

> cat /folder/with/plain/files/file1
Hello World
> rclone cat plain:file1
Hello World
> rclone cat cryptreverse:rjhasdiuywqernbscviuhwdf

Is this correctly understood?

What would be the benefit of using rclone compared to already existing tools, such as enfFS --reverse?

How would rclone (being focused on transfers to/from/between many cloud providers) benefit from this?

Interesting idea.

Rclone can't do that directly at the moment.

What you could do is set up a crypt pointing to a local directory, copy the files you want to upload into it, then upload that local directory. This would mean making two copies of all your data though...

Yes, this is my intention.

and for the question "rclone compared to already existing tools" is that
I can still use rclone to directly access (some) files from encrypted remote
after I use web/vendor app to upload the encrypted view, if the cloud provider
has API access function, but just limit the call number. of course, if provider
disable API function completely, rclone didn't make any differences to encfs --reverse
except that rclone encrypt/decrypt is compatbile with itself, so with rclone I
can quickly accesss encrypted file no matter if transfer to cloud through rclone directly,
or using encrypted view and transfer with vender app ( I expect the encrypted view should
be binary/path same as the encrypted transfer result, as long as they use same key)
and if rclone don't have this function, I can only use encfs --reverse to backup to the cloud (which
don't support API access), and use rclone for left ones. (but these two path/binary encrypt is not compatible with each other)

Id also be interested in a rclone crypt reverse mode - being able to setup an encrypted mirror of a folder without storing the data twice. EncFs offers this, but there are security concerns apparently, and another alternative is gocryptfs, however id love to stick with a possible rclone solution

I came here looking for the same thing.

What would be the benefit of using rclone compared to already existing tools, such as enfFS --reverse?

In my case, I want to back up a filesystem that is already mounted via RClone because it has an S3 backend. So, the benefits of using such a feature instead of encFS are:

  • one round-trip through FUSE, rather than two (better performance)
  • fewer moving pieces = fewer edge-cases (bugs, compatibility issues)

Basically, what I want to achieve is OpenIO (local erasure coding) <-> actual filesystem representation -> Jottacloud (really cheap versioned backup)

I have the same underlying need that @comicfans describes - a reverse crypt mount.

In my case, this is because my connection is sufficiently slow and wobbly (thanks, BT!) that when I'm archiving multi-GB files to a perfectly /good/ provider (rsync.net, in this case), there are some files that I can't get through without a disconnection. Rclone's SFTP provider not having "resume after partial upload" functionality means that my best bet is to rsync --in-place a locally crypt'd view of the files. If I could use a reverse crypt mount to avoid the "rclone it locally to a throw-away directory, first" overhead of IO, time, and storage, that'd be /fantastic/ :smiley:

A minor thought: I /think/ that any reverse crypt feature would need to make explicit its decisions about the stability of the crypt'd files it exposes.

For example: for my use case, imagine I rsync my data set initially, reading a reverse crypt mount. Then I come back and discover that a large file needs to be sent again. If rsync re-reads the crypted file but its nonce-hence-content has changed, then I'll be re-sending that entire file, irrespective of rsync's ability to resume partial transfers. I reckon(tm) that nonce-hence-content stability across reads should be assured, even if that stability can't be guaranteed across different rclone reversecryptmount invocations. Perhaps the putative reversecryptmount operation could accept a nonce-seed argument from the user, and combine that seed with file's paths/names to derive still-secure-but-stable-nonce-hence-content /across/ mount invocations? :thinking:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.