RSA encrypted storage, copy-compatible, copy requires private key

Support
#1

Not sure if I’m doing something wrong here.

  1. I created RSA encrypted storage.
  2. made backup there.
  3. Created copy-compatible storage
  4. Attempt to copy between the two.

The copy command asks for a private key. I’d expect the copy should not require private key. This kills as few interesting replication scenarios; for example – I backup to my storage appliance and replicate the backup to the cloud from it. I don’t want NAS to have my private key at any point of time.

Is this by design?

version 2.6.1.

Question about encryption without RSA
Copy without private RSA key
#2

The current implementation needs to decrypt and re-encrypt the downloaded chunk first before sending it to the destination. It is unnecessary for a bit-identical destination, but I feel this offers an additional level of protection – a corrupted chunk will be detected during the decryption phase.

When copying encrypted local storage to cloud, should it be encrypted again?
How to do offline backup?
#3

so if I create bit-identical storage copy will not require the key?

If user wants to check the storage they can run check -chunks. But if I only want to copy – I don’t want to have to provide private key, because my copy job may be running on an untrusted server. Ideally private key shall only be needed for restore.

It seems very arbitrary to require a key just to bundle check with copy, which the user did not ask for

#4

No, the current implementation will still require you to specify the private key, although this can be removed in the feature.

#5

I see, so this my use case is then not possible. Please do consider removing it in the future, that would be super helpful. (Right now I’m keeping one of the Macs awake for weeks to do another backup to remote storage from scratch (~3 TB of data over 10Mbps upstream…) instead of running copy on a nas that is ON 24/7 anyway)

3 Likes
#6

Bumping this.

I think removing this requirement for copies between bit-identical storages is really a necessary feature, to avoid exposing the private key.

Nowadays I use Rclone for these copies, which is far from adequate for several reasons.

@gchen, maybe it’s one more feature to be included in 2.7.3.

#7

Can you add how to Rclone copies to use case if this won’t be included in the near future? Because this post was created two years ago I think there will be more delay.

#8

Storages must be -bit-identical. Just use rclone sync to sync the chunks and snapshots (or entire bucket) directly.