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

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.

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.

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

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

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