Document and mitigate proof-of-file-ownership attack

[geek-merlin]

As i get it, the private key used to restore can have a passphrese, but the public key used to backup can not.

If i get it right, this is deterministic encryption. So, given the remote repo contains the config.yml file (which i need to do GC there), and given an attacker has access to my remote repo (and my backup strategy, it's open source), they can prove that i own a specific file, simply by adding it to the repo and seeing no or few new chunks.

If yes,

• this attack should be added to the docs to make data hoarders aware of
• there should be an option that prevents that attack, e.g. an optional pubkey passphrase

[dpc]

The core issue is that chunks of data are named as a hash of plaintext data they contain. I guess it might be possible to name them after the hash of the cyphertext, if the encryption is deterministic, but I'm not sure if it doesn't introduce any other issues.

Note: IIRC symmetric encryption support is available, but it comes with a downside that it requires passphrase to unlock the repo for writing. In case of symmetric encryption determinism should be easy to achieve in all cases.

[geek-merlin]

I guess it might be possible to name them after the hash of the cyphertext

That would not disable the attack. But interesting idea.

[geek-merlin]

How difficult would an optional pubkey passphrase be?

[dpc]

Optional pubkey passphrase defeats the purpose. Might as well use symmetric encryption (probably even faster).

[dpc]

But if there are good reasons for it - it should be fairly straighforward.

(I have little time today, so I can't respond to other threads today, sorry!)