Duplicacy works as follows: all files selected for backup are combined into a long sausage, which is then shredded into chunks; each chunk is encrypted, given a name according to its hash, and uploaded to chunks folder on the storage. This is a foundation for the CAS (file based content addressable storage) duplicacy uses to facilitate cross-machine deduplication.
The data (file manifest) required to restore your original files is also shredded into chunks, encrypted and uploaded to the same storage.
The encryption keys reside in the config file that is generated during storage initialization. The config file itself is encrypted, if you chose to enable encryption during storage initialization with the -e
key.
Duplicacy also supports optional asymmetric encryption with RSA keys for ultimate security – the key that is used for backup cannot be used to restore, you need separate key for restore that does not need to be present on the machines doing the backup.
Answering your question – not only file names but their count, type, sizes, or anything else about your dataset is completely opaque without the knowledge of encryption password.