Duplicacy-web: Copy fails when using GPG

[cyrond]

Hey guys,

I installed duplicacy-web yesterday to test it out. I created an SSH storage and a Google Drive storage.

I set two different passwords, the same Erasure Coding setting (10:1) and the same RSA public key for both storages. I also checked the box “make it compatible with” for the Google Drive storage, after the SSH storage was already created.

Now I made a backup job for the Google Drive and created a schedule to move the backup after completion to the ssh storage.

The second step fails.

The error message is, that there’s no private key available.

This seems odd: I don’t want to restore anything and both storages use the same public key. There should be no need to decrypt and encrypt the data between both storages.

Additionally, there was no way to specify a private key - so it’s obviously impossible that it’s not missing.

Running copy command from /home/rubenk/.duplicacy-web/repositories/localhost/all
Options: [-log copy -from GoogleDrive -to xxx]
2022-04-14 14:08:26.430 INFO STORAGE_SET Source storage set to gcd://Backup/Duplicacy
2022-04-14 14:08:35.600 INFO STORAGE_SET Destination storage set to sftp://xxxx/backups/duplicacy
2022-04-14 14:08:36.821 INFO BACKUP_ERASURECODING Erasure coding is enabled for the destination storage with 10 data shards and 1 parity shards
2022-04-14 14:08:36.821 INFO BACKUP_KEY RSA encryption is enabled for the destination
2022-04-14 14:09:40.079 INFO SNAPSHOT_COPY Chunks to copy: 2241, to skip: 894, total: 3135
2022-04-14 14:09:43.431 ERROR CHUNK_DECRYPT An RSA private key is required to decrypt the chunk
An RSA private key is required to decrypt the chunk

[gchen]

The copy job always decrypts chunks from the source storage and re-encrypts them before uploading to the destination storage. You can add the -key option to the copy job to pass the private key file:

   -key <private key>           the RSA private key to decrypt file chunks
   -key-passphrase <passphrase> the passphrase to decrypt the RSA private key

[Droolio]

This really is a weak point of the RSA feature, and why I don’t currently use it.

I can understand and expect chunks to be decrypted and encrypted between storages - using the regular chunk key - because the storages may have their own keys, but the underlying data, which may possibly be encrypted with RSA, shouldn’t need the private key sitting around simply to re-encrypt. That just completely obviates the purpose of having only a public key on sensitive systems.

I guess it matters how, and in what order, the data is encrypted. Is it RSA first and then regular key encryption? Or visa versa? Or are they combined in one operation? ISTM that it should be a two-step process, to allow storages to be copied without access to the private key.

[cyrond]

According to what I’ve read the regular encryption is the first stage, while the GPG encryption is used to just encrypt the data itself, not the metadata.

Since the metadata needs to be read/written, the regular encryption key is definitively needed - as the whole storage is encrypted - which is different to the approach in ZFS which I’m used to, where the metadata and data of the filesystem is encrypted, but stored in a way that the organizing structure is still not encrypted and thus you can transfer snapshots without knowning the encryption secrets from system to system.

While this would be ideal, I understand why duplicacy isn’t going this route - it would result in a different structure of the storage system.

But you really don’t have to decrypt and encrypt the backups which are already stored on one system, if the GPG-Key is the same. There seems to be a check for that missing.

If the GPG-Keys are different for the two systems, there need to be a way to provide the GPG keys the “from” system for this process - which is also not available.

[cyrond]

Okay, but this feels a bit like a waste of CPU resources. I mean, if it’s the same public key, why not just keep the first encryption (and avoid having to need the private key on the device).